<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sun, Dec 11, 2016 at 11:14 AM, Dirkjan Ochtman <span dir="ltr"><<a href="mailto:dirkjan@ochtman.nl" target="_blank">dirkjan@ochtman.nl</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Did you look at Brian Smith's *ring*, and if so, why did you decide<br>
not to go with it?</blockquote></div><br clear="all"><div>As a Rust crypto consumer, I view these libraries differently.</div><div><br></div><div>*ring* is a fantastic library and one I've been using in my Rust crypto projects for awhile. However, it's a "safe" library in the same sort of lineage as NaCl and libsodium: it tries to expose a high-level, minimalistic API. Types like curve points/group elements are not directly exposed for safety reasons and remain part of the private API.</div><div><br></div><div>curve25519-dalek seems much better suited for people implementing more exotic constructions using types *ring* does not (for good reasons) expose as part of its public API. These would include things like SPAKE2, hierarchical key derivation, semiprivate keys, blinded signatures, ring signatures, threshold multisignatures.</div><div><br></div><div>Building any of the things I listed above above on top of *ring* would require forking *ring* and building atop its private API. Maybe some of those things should eventually wind up in *ring*, but I appreciate Brian being conservative about what he includes.</div><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Tony Arcieri<br></div>
</div></div>