<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On Apr 17, 2015, at 12:32 PM, <a href="mailto:zaki@manian.org">zaki@manian.org</a> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div><div class="gmail_signature"><div dir="ltr">I don't think this really solves any actual crypto problems.</div></div></div></div></div></blockquote><div><br></div><div>Just to be clear, I’m not claiming to solve any actual crypto problems.  I’m claiming (or maybe “aiming” is a better word) to solve a UI/UX problem.</div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div><div class="gmail_signature"><div dir="ltr"> I also suspect it's pretty hard to solve any of the big problems while retaining this level of simplicity. But I'm sure you'll learn stuff along the way.</div></div></div></div></div></blockquote><div><br></div><div>Yep, that’s also one of my goals.  :-)</div><div><br></div><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>You should take a look at reop as well which is an even older nacl PGP clone.</div><div><br><a href="https://github.com/tedu/reop">https://github.com/tedu/reop</a><br></div></div></div></div></blockquote><div><br></div><div>Thanks.  Just FYI, this was my first attempt at a PGP clone:</div><div><br></div><div><a href="https://github.com/rongarret/clmm">https://github.com/rongarret/clmm</a></div><div><br></div><div>That code implemented passphrase protection on the keys.  But someone here (Robert Ransom) pointed out to me that if you really care about file security then you should be using a secure file system instead of trying to implement a “half-assed” password protection scheme.  That led me to thinking deeply about attack models and the conclusion that a browser based solution could be reasonably secure, where “reasonably secure” means “as secure as the current state of the art in the hands of a non-technical user”.</div><div><br></div><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; position: static; z-index: auto;"><span class="">
> Minilock uses a compressed curve25519 point without any metadata as public key. This is more compact than your format. It'sBase58 encoded it is tweetable which is very nice.<br>
<br>
</span>SC4 and Minilock use the same underlying crypto.  The reason SC4 keys look longer is that it gives you separate keys for signing and encryption.  But SC4 keys could be easily made tweetable if people cared about that.<br></blockquote><div><br></div><div>NACL encryption is authenticated. The shared secret is used in the MAC as well encryption steps. If all you want is an encryption app, you don't need a ed25519 signing key as well.<br></div></div></div></div></blockquote><div><br></div><div>Yes, I know.  Signing is a separate feature.  (SC4 lets you sign without encrypting and vice versa.)  The main reason for separate keys is that I didn’t know if it was possible to securely convert back and forth between them (but I know now!  Thanks for the pointer.)</div><div><br></div><div>Another reason to keep the keys separate is so that you can revoke them independently.  But I’m not sure that’s a good enough reason.</div><div><br></div><div>rg</div><div><br></div></div></body></html>