[messaging] Whiteout Secure PGP Key Sync

[David Leon Gil]

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?

----

Some comments:

. . . . 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
a PEM for the Google CA; but the code is JavaScript, so you aren't running
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.

-dlg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20140714/b5fd1465/attachment.html>