Skip to content

Keys.dat should only contain private keys #256

Open

Description

@Jord-JD

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.

Activity

  1. Atheros1 commented on Jun 25, 2013

    @Atheros1
    Contributor

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

  2. fiatflux commented on Jun 25, 2013

    @fiatflux
    Contributor

    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.

  3. r14c commented on Jun 25, 2013

    @r14c
    Contributor

    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.

  4. Dokument commented on Jul 1, 2013

    @Dokument

    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).

  5. self-assigned this
    on Oct 18, 2015
  6. added this to the milestone on Oct 18, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions