add PBKDF2 as described in BIP39

[ryanxcharles]

It is actually not necessary to "encrypt" the private key - using a seed and a password to derive the private key with a KDF, such as PBKDF2 as described in BIP 39, has equivalent security properties. e.g., the only way to get the private key is to brute-force the password.

The TREZOR uses BIP 39, and does not "encrypt" the private keys with AES or any other symmetric or asymmetric cipher, and the TREZOR is secure, so a sentence like this should be included to make sure the TREZOR passes the test.

[Abstrct]

This alternative key storage mechanism looks like it makes sense to add. As is pointed out above, it is equivalent to a password being used to encrypt/decrypt the key, just used when accessing the asset instead.

Before we commit though, is there anything that this weakens or clashes with? Is there anywhere else in the standard we need to consider relating to this change (maybe in 101-KeySeedGeneration or 102-WalletCreation)?

[mperklin]

I agree with Ryan.

This section was written to ensure private keys were secured against unintended disclosure. While encryption is one way to do it, a password-based key derivation function accomplishes the exact same result.

I don't think this weakens anything as long as the section is both specific enough to require something to secure the key, but generic enough to allow either encryption, a KDF, or other equivalent method.