[messaging] Whiteout Secure PGP Key Sync
David Leon Gil
coruus at gmail.com
Mon Jul 14 05:30:16 PDT 2014
Thanks much for the link to the source! (But the license is too scary for
me to actually read it; it appears to attempt to grant a license to people
'auditing' the code, but no-one else.)
A pseudocode spec would really help: I would commend to you
Trevor's protocol specs as a model of clarity.
First, a security model question:
Suppose the following:
(1) I have access to the server's permanently stored material, but not the
various ephemeral keys.
(2) I take a picture of a user while they're using the QR code option to
transfer their master secret.
What can I do next?
. . . . Since the user has uploaded and
> authenticated a public PGP key to the whiteout key server before
> private PGP key sync, there is already a trust relationship between
> the PGP keypair and the server. This is used as an additional factor
> for authentication.
What is the threat this is supposed to guard against?
> The device secret is known to the server and stored as a hash pretty
> much like a password. This is why it should not be trusted to protect
> the user from a threat model point of view.
Since keysync is infrequent(?), why not just give the server a public key
and sign a challenge?
Or perhaps better: sign the challenge and a commitment to a next device
secret. Then device compromise and secret use always leads to an error.
Yes. The server is a standard REST service secured via TLS.
Is this explicitly pinned? (Scanning through the directories, only saw
it on Appspot...)
> . . . . Given that all Whiteout Endpoints
> use TLS 1.2 with forward secrecy, could you elaborate on how adding a
> DH-style key exchange for the session keys would add security?
Does the client enforce this (can it)? (I wonder if would be feasible to
add a field to require TLS 1.2 [AEAD]-ECDHE for all connections to a
domain on Chrome's pinlist......)
I think dkg's point is that you are relying on the transport layer for
application security; it's just harder to control exactly what happens.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Messaging