[messaging] Secure OpenPGP Key Pair Synchronization via IMAP (RFC)

[Trevor Perrin]

On Wed, Apr 8, 2015 at 5:37 AM, Tankred Hase <tankred at whiteout.io> wrote:
> Hi there,
>
> we've updated our private key synchronization protocol. The new
> version was developed together with Cure53 and it's much simpler than
> the old protocol:
>
> https://blog.whiteout.io/2015/04/08/secure-pgp-key-sync-a-proposal-contd/


Hi Tankred,

Thanks for sharing!  Could you say more about the use case(s) for
this?  Your blog and spec focus on the "multidevice" case (Alice has a
laptop and tablet and phone), but you also call the password a "backup
code" and mention the user losing their device.

For the multidevice case, did you consider device-pairing protocols
like PAKE (SRP etc), Short-Auth Strings (SAS), or other (QR, NFC)?
These could allow the user to deal with much shorter strings, or
dispense with entering / comparing strings altogether.

They also allow the private key to be transfered between devices,
without storing an encrypted version on a server.  While the latter is
secure if encrypted by a high-entropy secret, I'd worry that:

(A) You encourage users to write down the 24-character secret, which
is an additional item someone could steal.

(B) Having to dig out this secret and enter it on phones / tablets is
not a friendly UI.

(C) The spec allows user-supplied passphrases.  I suspect
implementations will find that more user-friendly and ignore your
"please consider the downsides" warning, resulting in crackable
private keys being backed up to servers:
"""
The passphrase SHOULD be a random high-entropy uppercase alphanumeric
string of 24 characters, generated from a cryptographically secure
pseudo-random number generator (CSPRNG). Should you choose to go with
a user-supplied passphrase, please consider the downsides of deriving
the key from a user-supplied passphrase due to a lack of entropy in
user passwords.
"""

Maybe you chose the password instead of device-pairing so it could do
double-duty for the lost-device case?

It's not obvious these cases should be served with the same mechanism.
Per above, I think device-pairing is a better solution for the
multidevice case.  But this isn't obviously the best solution for
lost-device case either, since it depends on the server holding the
encrypted key - if you want reliable access to your data even if the
server deletes your account or locks you out, you'll need something
more.

I also wonder whether multidevice support removes much of the need for
a separate lost-device mechanism, since users are unlikely to lose all
devices simultaneously?


Trevor