<br><br>On Friday, July 18, 2014, Tankred Hase <<a href="mailto:tankred@whiteout.io">tankred@whiteout.io</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div 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" target="_blank">http://emailjs.org</a></div>
</div></blockquote><div><br></div><div>That's really awesome re emailjs. I'll take a look!</div><div><br></div>I thought I'd mention this on-list, actually, for developers of other commercial applications: The Affero GPLv3 was written to be helpful in this case: it extends the GPL to server-side and web apps (users -- and thus the original developers -- have a right to the source). (And there's no particular need to release *all* of your app's source under that, even.) <div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><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 </div>
</div></blockquote><div><br></div><div>I agree completely. Alas, the story of open-source crypto projects (w.r.t. being adequately funded) has not historically been good. So I'm hoping you manage to find a business model that works.</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><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></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="auto"><blockquote type="cite"></blockquote><div>Not sure what attack you're suggesting. Can you provide a more elaborate example.</div></div></blockquote><div><br></div><div>Okay, sure. I'm NSA/FBI/BND/ANSSI. I want a user's private key. So I hack into your servers, and get every encrypted private key you store.</div>
<div><br></div><div>What do I do next? Is just taking a picture[*] of the user transferring the master key via the QR code option sufficient to decrypt what I got from your server. Or do I also have to MitM a connection between their device and your server? (The answer is hopefully the latter.)</div>
<div> </div><div>[*] Note that, for QR codes, it's easy to do this at large scale. E.g., do image processing of security camera footage.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="auto"><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)" target="_blank">http://en.m.wikipedia.org/wiki/Key_server_(cryptographic)</a></div>
</div></blockquote><div><br></div><div>Okay. Now I get what you're doing! That's great.</div><div><br></div><div>(And I'm aware of the many key server issues...)</div><div> </div></div><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="auto"><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" target="_blank">whiteout.io</a> servers in a later version.</div>
</div></blockquote><div><br></div>Well, at the very least, get on the pinlist at some point.<br><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto">
<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/" target="_blank">http://tankredhase.com/2014/04/13/heartbleed-and-javascript-crypto/</a></div>
</div></blockquote><div><br></div><div>(Right, sorry, I was unclear: I thought that your endpoints might be running on Appspot, and therefore that was your pin to the Google CA Appspot uses.) </div></div><div><br></div>(Some more on the signature thing in a while.)