<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 11, 2015 at 4:29 PM, Andreas Schultz <span dir="ltr"><<a href="mailto:aschultz@tpip.net" target="_blank">aschultz@tpip.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">So, don't blame the speed on the cryptographic library, but on the interface to it.</blockquote></div><br>This should perhaps have been in a highlighted position. Yes, indeed, the interface is the problem. Since `ssl`, the Erlang application is using this interface however, it becomes a bound on the speed, which was kind of the primary point.</div><div class="gmail_extra"><br></div><div class="gmail_extra">The secondary point about enacl is that we can do better, much better. The salsa20 suite of ciphers (salsa20, xsalsa20 and chacha20) are all considerably faster than AES, even with optimizations, for the same or better security margin. Combined with a bad interface, the speed difference becomes noticable to the point where it begins to matter. Enacl could be optimized further and currently includes a tradeoff where it copies the 200 megabytes for a nicer interface. Exposing a worse interface could avoid that copy altogether for really speed-sensitive programs.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Of couse I'm biased :P<br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">J.</div>
</div></div>