[erlang-questions] Erlang/OTP and OpenSSL 1.1

[Andreas Schultz]

Hi Sergei,

----- Original Message -----
> From: "Sergei Golovan" <sgolovan@REDACTED>
> To: "erlang-questions" <erlang-questions@REDACTED>
> Sent: Sunday, September 18, 2016 6:00:13 PM
> Subject: [erlang-questions] Erlang/OTP and OpenSSL 1.1

> Hi!
> 
> Recently, new major OpenSSL version 1.1 has been released, with many
> API incompatibilities, and I guess sooner or later one should port
> Erlang crypto module to it. My first attempt of the porting can be
> found at https://github.com/sgolovan/otp/tree/openssl11
> 
> There are a few things that have to be changed:
> 
> 1. Basically every complex type in libssl became opaque, so one can't
> put a variable on a stack (you can't have 'EVP_MD_CTX ctx' anymore)
> and can't use the struct fields directly. So, I had to add code which
> allocates these variables on a heap, and code which frees the
> resources after use.
> 
> 2. Quite a few constructors and destructors were renamed to maintain
> names consistency (e.g. EVP_MD_CTX_new() instead of
> EVP_MD_CTX_create(), EVP_MD_CTX_free() instead of
> EVP_MD_CTX_destroy()), so I had to add quite a few #if's for old and
> new calls.
> 
> 3. OpenSSL documentation now says that there's no need in specifying
> locking callbacks (actually it just doesn't say that one has to
> specify them and doesn't provide the way to). Old functions like
> CRYPTO_set_locking_callback(), CRYPTO_set_id_callback() became macros
> which expand to nothing. So, I've added a preprocessor guards to
> switch them off for 1.1.
> 
> 4. New libssl implements chacha20-poly1305 cipher (there's no need in
> patching anymore), so I've reimplemented the encryption/decryption
> with this cipher using the libssl uniform interface. The problem with
> it is that it implements RFC 7539
> (https://tools.ietf.org/html/rfc7539) which differs to the current
> implementation (a draft from
> https://tools.ietf.org/html/draft-agl-tls-chacha20poly1305-04 ) in two
> ways: first, the nonce size is changed from 8 to 12 bytes (8 bytes is
> still acceptable, it shifts left by 32 bits), which isn't too bad
> because the discrepancies can be found only after 32-bit block counter
> overflows (which isn't very plausible). Second, the tag calculation
> algorithm has been changed (see
> https://tools.ietf.org/html/draft-agl-tls-chacha20poly1305-04#page-8
> vs https://tools.ietf.org/html/rfc7539#page-19 ). This means that the
> implementations aren't compatible. As for now I've added two test
> cases for the new implementation (and haven't removed the old case, so
> the test fails at the moment). I'd say that the old implementation
> should be dropped some time.

At least for SSL, that shouldn't be a problem. Currently SSL uses a
cipher id for the ChaCha20 cipher that indicates to old version. The
final RFC for ChaCha in TLS did define different cipher ids. So, the
SSL module should be adjusted at the time to the new version.

Andreas

> 
> Okay then. I hope this porting attempt will be helpful.
> 
> Cheers!
> --
> Sergei Golovan
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions