crypto ships one KDF today, pbkdf2_hmac/5, but the libcrypto it already links against exposes a whole family through OpenSSL EVP_KDF. Right now, anything else (like Argon2) means a NIF for crypto that’s already sitting in the library.
I’d like to see a few of the rest exposed through crypto:
scrypt (RFC 7914) and Argon2 (RFC 9106) for password hashing without a NIF.
Concat KDF (NIST SP 800-56)
HKDF (RFC 5869), used in a lot of protocol key schedules (Noise, TLS 1.3, HPKE). This is easy to construct yourself with crypto:mac/4 but it would be nice to include it if we’re already exposing other KDFs.
Since they all share a shape (input keying material plus algorithm-specific params), one entry point was my thinking:
crypto:kdf(hkdf, IKM, #{digest => sha256, salt => Salt, info => Info, length => 32}).
crypto:kdf(scrypt, Pass, #{salt => Salt, n => 32768, r => 8, p => 1, length => 32}).
crypto:kdf(argon2id, Pass, #{salt => Salt, t => 3, m => 65536, p => 4, length => 32}).
Argon2 needs OpenSSL 3.2+; older libcrypto would raise notsup like the rest of crypto.
I wanted to start the conversation here to gauge interest from the OTP team before I open a PR.
If it was me, I would properly skip an EEP and just draft a PR if the implementation is straightforward, I’m surprised this doesn’t even exist today.
As a community we should reduce the amount of dependency and if we can get the majority of security focused engineers to put their focus in OTP it would be better for us all then yet another dependency to something as fundamental as crypto, this would also provide a gate to scrutinize new algorithm and implementation and what not in one place.
Not needing a NIF for argon2 would be very nice. If it was available in crypto then many BEAM web applications no longer need to compile C code and could be pure BEAM code, making them portable across operating systems and much easier to build.