Private encryption and signing keys should be encrypted

[DivineOmega]

If we consider issue https://github.com/Bitmessage/PyBitmessage/issues/256 to be a prerequisite to this, we could encrypt the entire keys.dat file.

I see this working similar to the following:

Any save operations would save out encrypted using an (AES) encryption key generated from a user provided password combined with a random salt. The random salt would prefix the encrypted data. This would allow it be retrieved and used with the password for decryption.

• When PyBitmessage starts up for the first time and the keys.dat does not exist, the user would be prompted for a password. After a password is entered, an encrypted keys.dat file would be created.
• When PyBitmessage starts up and the keys.dat does exist, the user would be prompted for the password and the keys.dat would be decrypted in memory. This decrypted data would then fed and equivalent of the current shared.config object and be accessed as usual by the rest of the program.

Unfortunately, due to the fact decrypted must be attempted against every message received, we have to store the private keys decrypted in memory while the program remain running. I can't think of any way around this without the inconvenience of the user being prompted for the password every time a new message comes in.

I'd really like to hear everyone's thoughts, feedback and ideas. This is a reasonably big/complex change so it really needs to be got right.

[ghost]

Maybe it would be a better idea to use a standard container format for the keys? Like the one used to store ssh and ssl private keys.

Or maybe borrow the encrypted wallet implementation from the bitcoin armory client, I think its in python,

[fiatflux]

AES is really fast. That's sometimes a good thing, but not necessarily so here. Since we only need to decrypt a fairly small amount of data, slow is acceptable and helps prevent bruteforce attacks. One way to mitigate is to make key derivation slow. Suppose we generate the key through something like bcrypt?

I'd also consider doing a cipher cascade along the lines of Schneier's: concatenate(cipher1(OTP), cipher2(OTP^plaintext))

[jdguffey]

What about PKCS#8? It's supported by OpenSSL and the key(s) could be encrypted with PBKDF2 (From PKCS#5) without having to do anything except modifying OpenSSL lib calls (I believe).

[linkerlin]

PKCS#8 is a good choice.

[Dokument]

I think as soon as they keys are encrypted by bitmessage, users will neglect safe practices. Even using encrypted containers is risky but at least it makes you think about it.

[acejam]

This sounds like a great idea.