icc produces good code from the intrinsics-based translation,
clang produces okay code, but gcc doesn't perform very well ATM.
It's a bummer to have a 3rd implementation, but salsa20 is used quite
a lot in the library, so it deserves a special attention.
If the assembly code cannot be assembled, fall back to the reduced
version of the intrinsics-based translation.
So, in the final library, we always only get two implementations at most.
- 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.
Due to SSL, the IETF version of chacha20poly1305 is going to be the one
that's in libraries places. While the 12-byte nonce thing is a little
weird, it has other benefits, like adding padding to the auth tag, which
might help fend off certain attacks.
But more importantly, since chacha20poly1305 in the IETF construction is
lots of places, it would be useful to be able to build xchacha20poly1305
out of it. Fortunately it's very easy to make hchacha20 (either
stand-alone, or out of the normal chacha20 block function), and then
that can be composed with an existing library's chacha20poly1305. It
looks a bit like this:
xchacha20poly1305(input, key, nonce) {
new_key = hchacha20(key, nonce)
return chacha20poly1305(input, new_key, nonce + 16)
}
This is also an efficient way to do it, since it means hchacha20 must
only be computed once.
Unfortuantely, non-IETF xchacha20poly1305 means that you deprive
virtually all other libraries that only support the more common
IETF construction the ability the ability to interoperate with
libsodium, through the simple construction. Rather, it forces
everyone to reimplement the AEAD part.
So, this commit adds a xchacha20poly1305 that uses the IETF construction
with the padding.
While we're at it, we redefine xchacha20poly1305 in terms of
chacha20poly1305, which gives the same output, but computes one less
hchacha20 and is generally a lot cleaner and simpler to understand.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
* 'master' of https://github.com/jedisct1/libsodium:
Check if atomic operations are supported
Remove a whitespace following trailing backslash in a Makefile
