[erlang-questions] crypto EVP transition

[Maas-Maarten Zeeman]

I’ve been working on this and am in contact with the OTP team. In the past I have done quite some work with openssl’s evp api.

The main problem is that it is not possible to implement a drop in replacement for the current ciphers. The api need to change slightly. I’ve implemented a proof of concept nif to test it. For cpu’s supporting AES-NI I get a 5x speedup, so it is definitely worth it.

This is the current proof-of-concept api, minus meta-data functions for retrieving block size, iv,- and key length, and a bytes to key function:

-spec cipher_init(binary(), binary(), binary(), encrypt | decrypt, boolean()) -> {ok, cipher_ctx()}.
cipher_init(_Alg, _Key, _Iv, _Mode, _Padding) ->
    exit(nif_library_not_loaded).

-spec cipher_update(cipher_ctx(), iolist()) -> binary().
cipher_update(_Ctx, _Data) ->
    exit(nif_library_not_loaded).

-spec cipher_final(cipher_ctx()) -> binary().
cipher_final(_Ctx) ->
    exit(nif_library_not_loaded).

Last word from the otp-team was that they think this api is bit too un-erlang because of the rather ugly mutating cipher context. There is not much I can do about that. Openssl does not have a context copy function in its api. Copying the context from call to call could also be impossible when the cipher is implemented in hardware.

I’ve suggested that it would be possible to hide the cipher state in a more generic data-transform process. The protocol could be similar to the io-protocol (without seeks), and more erlang like. This would make it possible to also support other types of data-transformations. Think about hex, base64 en/decoders, character set conversions (iconv), and hashing (no transform, process needs extra call to get digest). Such a protocol could be useful for a lot of things.

I’m not sure if all this is on track for 18.0 though.

Regards,

Maas