<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><br></div><blockquote type="cite"><div>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></blockquote><div><br></div><div>Yes. We're still figuring out our businessmodel, which is why we haven't finalized our licensing terms. Our IMAP/SMTP code is already MIT though: <a href="http://emailjs.org">http://emailjs.org</a></div>
<div><br></div><div>There is no easy answer here. I myself am a big fan of open source, but most FLOSS tools like GPG tools cannot provide what many non-technical users need, like professional support, hosting and other services. We're explicitely building a commercial product that people will want to pay for, since we're (hopefully) providing value to our users e.g. in the form of easy to use key management and multidevice PGP. That said, we're open to discussions about putting the client in open source if it makes sense. But I guess a crypto mailing list might not be the correct format to discuss businessmodels ;)</div>
<br><blockquote type="cite"><div><div><div><div>A pseudocode spec would really help: I would commend to you Trevor's protocol specs as a model of clarity.</div></div></div></div></blockquote><div><br></div><div>Thanks I'll take a look.</div>
<div><br></div><blockquote type="cite"><div><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></div></blockquote><div><br></div><div>Not sure what attack you're suggesting. Can you provide a more elaborate example.</div>
<div><br></div><blockquote type="cite"><div><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></div></blockquote><div><br></div><div>Existing PGP key servers don't authenticate keys. The problem are listed here: <a href="http://en.m.wikipedia.org/wiki/Key_server_(cryptographic)">http://en.m.wikipedia.org/wiki/Key_server_(cryptographic)</a></div>
<div><br></div><div>When a whiteout user uploads a public key, he gets a verification email to prove ownership of the email account to the server. This knowledge can then be used by the server for authentication later using the user's PGP key instead of e.g. a password.</div>
<br><blockquote type="cite"><div><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></div></div></blockquote>
<div><br></div><div>This sounds interesting. Can you elaborate?</div><br><blockquote type="cite"><div><div><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></div></div></blockquote>
<div><br></div><div>Currently only certs used for our IMAP/SMTP stack are pinned, which is why you see a google ca for gmail. Since chrome support ssl pinning for the https stack, we might add pinning for requests to our *<a href="http://whiteout.io">whiteout.io</a> servers in a later version.</div>
<div><br></div><div>The code and certs are deployed/installed via a packaged app (not webserver). More on this here: <a href="http://tankredhase.com/2014/04/13/heartbleed-and-javascript-crypto/">http://tankredhase.com/2014/04/13/heartbleed-and-javascript-crypto/</a></div>
<div><br></div><br><blockquote type="cite"><div><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></blockquote><blockquote type="cite"><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></blockquote><div><br></div><div>The transport layer offers some security. The application layer adds mechanisms on top (like wrapping the PGP key). Can you name an example where the compromise of the transport layer could compromise the user's PGP key?</div>
<div><br></div><div>thanks,</div><div>Tankred</div></body></html>
<br>
<span style="color:rgb(34,34,34);font-family:arial,sans-serif;background-color:rgb(255,255,255)">Whiteout Networks GmbH c/o Werk1</span><div style="color:rgb(34,34,34);font-family:arial,sans-serif;background-color:rgb(255,255,255)">Grafinger Str. 6</div><div style="color:rgb(34,34,34);font-family:arial,sans-serif;background-color:rgb(255,255,255)">D-81671 München<br><div>Geschäftsführer: Oliver Gajek</div><div>RG München HRB 204479</div></div>