Keys.dat should only contain private keys #256

New Issue

2013-06-25T19:16:00+02:00

DivineOmega commented

2013-06-25 19:16:00 +02:00

(Migrated from github.com)

The existing keys.dat also contain application settings/preferences.

I suggest the following:

keys.dat - only contains primary keys
settings.dat - contains all settings/preferences for the application

This will allow users to backup the most important data, their private keys, independent of the application settings.

The existing keys.dat also contain application settings/preferences. I suggest the following: - keys.dat - only contains primary keys - settings.dat - contains all settings/preferences for the application This will allow users to backup the most important data, their private keys, independent of the application settings.

Atheros1 commented

2013-06-25 19:43:12 +02:00

(Migrated from github.com)

I see no reason to separate them. This would just give people an additional file to worry about backing up.

fiatflux commented

2013-06-25 22:51:15 +02:00

(Migrated from github.com)

I strongly agree with the separation, as the two types of data serve very
different purposes and have very different sensitivity requirements. If I
wanted to share my settings with someone, as I did recently, I need to take
special care to not accidentally send my private keys.

I strongly agree with the separation, as the two types of data serve very different purposes and have very different sensitivity requirements. If I wanted to share my settings with someone, as I did recently, I need to take special care to not accidentally send my private keys.

r14c commented

2013-06-26 01:25:56 +02:00

(Migrated from github.com)

I see no reason to separate them. This would just give people an additional file to worry about backing up.

I don't think that is the most important concern when it comes to privacy software. The most important concern is security. Key files should only be user readable (an AppArmor profile on Ubuntu could be used to limit application access), it really doesn't matter who reads your config because it can't be used to decrypt your messages or impersonate you.

> I see no reason to separate them. This would just give people an additional file to worry about backing up. I don't think that is the most important concern when it comes to privacy software. The most important concern is security. Key files should only be user readable (an AppArmor profile on Ubuntu could be used to limit application access), it really doesn't matter who reads your config because it can't be used to decrypt your messages or impersonate you.

Dokument commented

2013-07-01 19:15:50 +02:00

(Migrated from github.com)

Honestly the config settings, key data, sent message data (such as plain text messages), addressbook, and subscriptions (, and chans in the future) could be used against a user if access is gained. I would agree more with making messages.dat ONLY encrypted messages and putting the other data in (a) different file(s).

This repo is archived. You cannot comment on issues.

1 Participants

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: Bitmessage/PyBitmessage-2025-02-18#256