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 <i>forever</i> 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.<p>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.<p>Have you looked into password-authenticated key exchange (PAKE) mechanisms? <a href="https://en.wikipedia.org/wiki/Password-authenticated_key_agreement" rel="nofollow">https://en.wikipedia.org/wiki/Password-authenticated_key_agr...</a> 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.<p>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.