It seems like this relies entirely on the strength of the secondary passphrase, and in turn of the storage by which that passphrase is moved from client to client. And if the encrypted private key is ever readable, it is forever vulnerable to attacks. They can spend as long as they like brute-forcing the secondary passphrase, or looking for the Post-It note where you inevitably wrote down the generated passphrase.
It also seems like there's no key-stretching involved, right? The cost of each brute-force attempt is very cheap? So the option of permitting a user-generated passphrase (with much lower entropy) seems like a pretty bad idea.
Have you looked into password-authenticated key exchange (PAKE) mechanisms? https://en.wikipedia.org/wiki/Password-authenticated_key_agr... My understanding is they let you use a relatively weak passphrase to authenticate a short-term session using a new 128-bit key, and once that session is established, attacks need to be against the session key, not the passphrase. This involves a bit more active communication than simply leaving an encrypted key in an IMAP folder, but you could do something where a new client requests a key by dropping a message in the folder, then you have to physically go to the old client to confirm it, which leaves a new message in the folder that (only) the new client can use.
I believe Firefox Sync uses a similar approach, except that the low-entropy passphrase is a PIN automatically generated by one of the devices, so the UX feels sort of like Bluetooth pairing.
Looks interesting. But I think I must be missing something.
Are the symmetric keys that are used to encrypt the private keys derived from a password, or not?
> This protocol overcomes this weakness by wrapping all key packets, encrypted with a key derived from a second high-entropy alphanumeric passphrase.
>
> The passphrase SHOULD be a random high-entropy uppercase alphanumeric string of 24 characters, generated from a cryptographically secure pseudo-random number generator (CSPRNG).
So do you seed the CSPRNG starting from something derived from a password? And if not, then how do you decrypt your private keys when you want to use them on a new device?
From my understanding, there are two passphrases. One to encrypt the private key in the usual way. And another one that's used for storage on the IMAP server.
The RNG is, as far as I can make out, only recommend to ensure that users don't use a weak passphrase.
It also seems like there's no key-stretching involved, right? The cost of each brute-force attempt is very cheap? So the option of permitting a user-generated passphrase (with much lower entropy) seems like a pretty bad idea.
Have you looked into password-authenticated key exchange (PAKE) mechanisms? https://en.wikipedia.org/wiki/Password-authenticated_key_agr... My understanding is they let you use a relatively weak passphrase to authenticate a short-term session using a new 128-bit key, and once that session is established, attacks need to be against the session key, not the passphrase. This involves a bit more active communication than simply leaving an encrypted key in an IMAP folder, but you could do something where a new client requests a key by dropping a message in the folder, then you have to physically go to the old client to confirm it, which leaves a new message in the folder that (only) the new client can use.
I believe Firefox Sync uses a similar approach, except that the low-entropy passphrase is a PIN automatically generated by one of the devices, so the UX feels sort of like Bluetooth pairing.