<div dir="ltr">There is an another pure Rust ECC (and Pairings) library available here<div><br></div><div><a href="https://github.com/MIRACL/amcl">https://github.com/MIRACL/amcl</a><br></div><div><br></div><div>Not sure how the speed compares. But things will definitely improves when the i128 type (128-bit integers) is supported in version 1.17 (due out in March 2017 I believe)</div><div><br></div><div><br></div><div>Mike Scott</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Dec 11, 2016 at 8:23 PM, Tony Arcieri <span dir="ltr"><<a href="mailto:bascule@gmail.com" target="_blank">bascule@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><span class=""><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"></span><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><span class="HOEnZb"><font color="#888888"><div><br></div>-- <br><div class="m_-3879953370662923129gmail_signature" data-smartmail="gmail_signature">Tony Arcieri<br></div>
</font></span></div></div>
<br>______________________________<wbr>_________________<br>
Curves mailing list<br>
<a href="mailto:Curves@moderncrypto.org">Curves@moderncrypto.org</a><br>
<a href="https://moderncrypto.org/mailman/listinfo/curves" rel="noreferrer" target="_blank">https://moderncrypto.org/<wbr>mailman/listinfo/curves</a><br>
<br></blockquote></div><br></div>