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
_______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
