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.)<br><div><br><div><div>A pseudocode spec would really help: I would commend to you Trevor's protocol specs as a model of clarity.</div>


<div><br></div><div>---</div><div><br></div><div>First, a security model question:</div><div><br></div><div>Suppose the following:</div><div><br></div><div>(1)  I have access to the server's permanently stored material, but not the various ephemeral keys.</div>


<div>(2)  I take a picture of a user while they're using the QR code option to transfer their master secret.</div><div><br></div><div>What can I do next?</div><div><br></div><div>----</div><div><br></div><div>
Some comments:</div><div><br></div><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">. . . . Since the user has uploaded and<br>
authenticated a public PGP key to the whiteout key server before<br>
private PGP key sync, there is already a trust relationship between<br>
the PGP keypair and the server. This is used as an additional factor<br>
for authentication.</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"></blockquote><div><br></div>What is the threat this is supposed to guard against?<br><div>


 </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The device secret is known to the server and stored as a hash pretty<br>
much like a password. This is why it should not be trusted to protect<br>
the user from a threat model point of view.</blockquote><div><br></div><div>Since keysync is infrequent(?), why not just give the server a public key and <span></span>sign a challenge?</div><div><br></div><div></div></div>

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.</div><div><br><div><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Yes. The server is a standard REST service secured via TLS.</blockquote>
<div><br></div>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...)<br><div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">. . . . Given that all Whiteout Endpoints<br>
use TLS 1.2 with forward secrecy, could you elaborate on how adding a<br>
DH-style key exchange for the session keys would add security?</blockquote><div><br></div>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......)</div>

</div></div><div><br></div>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.<br><div><br></div><div>-dlg</div>
</div>