- Factorize core_salsa20{20,12,8}
- Add support for multiple salsa20 implementations
- Replace the assembly SSE2 implementation with its equivalent using intrisics
It doesn't make any difference except by limiting the maximum
length to 256 Gb. But the code for the IETF version has a higher
probability to already be used by something else than the original
version.
Enforcing a 256 Gb limit can also prevent surprises from happening
in other implementations.
This is a common need, and people end up reimplementing HKDF.
So, add a crypto_kdf() API similiar to libhydrogen's. The later has a
higher limit for the output length using BLAKE2X if required.
We can implement the same strategy later in libsodium if needed.
* Test exposed constraint constants on crypto_pwhash
This includes the following constants for crypto_pwhash, crypto_pwhash_argon2i,
and crypto_pwhash_scryptsalsa208sha256:
- crypto_pwhash_BYTES_MIN
- crypto_pwhash_BYTES_MAX
- crypto_pwhash_PASSWD_MIN
- crypto_pwhash_PASSWD_MAX
- crypto_pwhash_OPSLIMIT_MIN
- crypto_pwhash_OPSLIMIT_MAX
- crypto_pwhash_MEMLIMIT_MIN
- crypto_pwhash_MEMLIMIT_MAX
* Expose constraint constants for crypto_pwhash
* Expose constant methods for crypto_pwhash
These are unlikely to have multiple implementations ever, unlike their
underlying primitives, so move them one folder up instead and take it
as an opportunity to merge small files.
These APIs were useful with the salsa20 constructions for compatibility
with NaCl, but they are tricky to use and don't provide any benefits over
the _easy APIs.
Having them around was good for consistency with the salsa20-based ones,
but this is code that is unlikely to be used in actual projects.
So, don't include them, unless people actually ask for them.
Frank Denis