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
FreeBSD have madvise() behaviors equivalent to MADV_DONTDUMP and MADV_DODUMP but with its own names.
Add definitions for these behaviors used in sodium_mlock() and sodium_munlock() if FreeBSD names are found and Linux ones don't.
Frank Denis