[erlang-questions] SSL performance

Ingela Andin ingela.andin@REDACTED
Mon Feb 16 22:40:46 CET 2015


Hi!

We do welcome a pull request to improve crypto internals. If you want to
change the API
remember that backwards-compatibility is important to us.  So please
communicate with us for any API changes,
even additions before putting too much effort into writing test cases,
documentation etc.

Regards Ingela Erlang/OTP team - Ericsson AB


2015-02-11 17:11 GMT+01:00 Andreas Schultz <aschultz@REDACTED>:

>
>
> ----- On 11 Feb, 2015, at 16:59, Loïc Hoguin essen@REDACTED wrote:
>
> > On 02/11/2015 04:29 PM, Andreas Schultz wrote:
> >> The cause for this is not the cryptographic library, but Erlang's
> interface to
> >> it.
> >> Erlang's crypto application uses a non-optimized OpenSSL API to execute
> the AES
> >> encryption, while enacl seems to uses an highly optimized version.
> >>
> >> Normally when doing AES, you first have to schedule the key, creating an
> >> encryption
> >> context and then reuse that context for every block. Since the crypto
> >> application
> >> doesn't have stream_cipher versions of AES, it has to go through the key
> >> scheduling
> >> on every invocation (every block). Also, OpenSSL can use assembler
> optimized AES
> >> functions on modern CPU's, but those are only available when OpenSSL's
> EVP
> >> interfaces
> >> are used. Erlang's crypto does not use those.
> >
> > I have seen some work around EVP in the past few months. Is this not
> > what you are talking about?
> >
> > commit 425a34001fdd5de8396c5c9903f4f38a9d49a15c
> > Author: Alex Wilson <alex@REDACTED>
> > Date:   Thu Oct 9 21:39:29 2014 +1000
> >
> >     crypto: use EVP for AES-CBC
> >
> >     This enables the use of hardware acceleration for AES crypto
> >     on newer Intel CPUs (AES-NI), among other platforms.
>
> That is a good step in the right direction. Still, it has to recreate the
> EVP crypto context for every invocation. There was a discussion about
> keeping the EVP context between invocations and use the crypto
> stream_encrypt/decrypt instead. That would eliminate the overhead of the
> context creation between calls.
>
> Andreas
>
> > Cheers.
> >
> > --
> > Loïc Hoguin
> > http://ninenines.eu
>
> --
> --
> Dipl. Inform.
> Andreas Schultz
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20150216/902d3ff5/attachment.htm>


More information about the erlang-questions mailing list