Closed sylvain101010 closed 5 years ago
Chacha20poly1305 was designed for TLS, not as a general purpose construction.
The concept of sessions (with unique keys) doesn’t necessarily existing when encrypting independent files or data streams. A longer nonce size is a way better fit for this. Or we would need to derive a subkey from a random nonce, which is exactly what xchacha is doing.
Xchacha20poly1305 is on the standard track: https://tools.ietf.org/html/draft-irtf-cfrg-xchacha-01
Thank you for the quick response!
Just to be sure to understand your point correctly:
XChaCha20Poly1305
for both AEAD and secret streams, even if not in the CAESAR winners? (https://github.com/jedisct1/libsodium/issues/554)XChaCha20Poly130
should be preferred over ChaCha20Poly1305
because it's larger nonce reduces nonce reuse probability (96bits is used in ChaCha20Poly1305_ietf
because of TLS sessions, but it's too short for a random nonce)?and a last one:
XChaCha20Poly1305_ietf
in libsodium
will be compatible with the IETF version once no longer a draft?
i.e. we can expect more implementations when no longer a draft outside of libsodium
, so the current libsodium
's version should be compatible with these other implementations?1) Yes. xchacha
is chacha
with a different initialization procedure that has been proven to be as secure as chacha
itself.
2) Yes.
3) The draft is based on the libsodium version. Other implementations have been written since, and they are compatible with each other.
Merci !
Maybe we can reopen #554 (or open a new issue as discussion has gone a little bit off topic) now XChaCha20Poly1305
have more implementations outside of libsodium
and is the standard recommended authenticated cipher.
For new users of the library, it's really confusing all these different (X)(Salsa|ChaCha)20Poly1305(_ietf)
.
Or maybe just update the documentation with XChaCha20Poly1305
here: https://libsodium.gitbook.io/doc/secret-key_cryptography/authenticated_encryption
and XSalsa20Poly1305
in a dedicated section.
crypto_box
and crypto_secretbox
are old compatibility APIs that will eventually be removed (see libhydrogen).
AEADs are described here: https://libsodium.gitbook.io/doc/secret-key_cryptography/aead
And there will be one more soon.
Ack, but my point is a new user will first see https://libsodium.gitbook.io/doc/secret-key_cryptography/authenticated_encryption which is the deprecated method instead of https://libsodium.gitbook.io/doc/secret-key_cryptography/aead which require to dig a little bit.
And even when we found https://libsodium.gitbook.io/doc/secret-key_cryptography/aead/chacha20-poly1305 it's not clear (rather the opposite) that XChaCha20-Poly1305
is the recommended cipher.
The first two variants are fully interoperable with other crypto libaries. The XChaCha20 variant is currently only implemented in libsodium, but is the recommended option if interoperability is not a concern.
For this reason, and if interoperability with other libraries is not a concern, this is the recommended AEAD construction.
Availability: libsodium >= 1.0.12. On the standard track.
So we should update the documentation:
to make it crystal clear that XChaCha20Poly1305
is today recommended AEAD cipher
in a second time, to make it clear that crypto_secretbox
is not recommended and XChaCha20Poly1305
is preferred.
If you are ok I can make a PR for 1.
2 will require to reorder documentation's sections, like putting crypto_secretbox
under https://libsodium.gitbook.io/doc/secret-key_cryptography/aead, and XChaCha20Poly1305
under https://libsodium.gitbook.io/doc/secret-key_cryptography/authenticated_encryption.
secretbox
is not an AEAD, so it shouldn't be in the AEAD section.
The high-level crypto_aead
API will eventually be crypto_aead_xchacha20poly1305
, which should lift confusion.
I read the libsodium documentation repeatedly and had no idea cryptobox and secretbox are scheduled for removal. Where does it say that?
Should I not feature cryptbox and secretbox in my crystal bindings?
What will replace cryptobox? I don't see any secret/public key API mentioned.
Don't worry, like all high-level APIs, they are here to stay. They won't be removed and will remain the recommended choice for most applications.
The default AEAD API will be equivalent to crypto_aead_xchacha20poly1305
. The _xchacha20poly1305
suffix can be dropped. So, people who need to attach additional data can use crypto_aead
instead of crypto_secretstream
.
Other algorithms are low-level functions, and are only useful to users specifically looking for them.
Hi,
First of all thank you for this great library!
Why
crypto_secretstream_chacha20poly1305
orcrypto_secretstream_chacha20poly1305_ietf
are not available?It could be useful if someone want to use an IETF standard for stream authenticated encryption ? Or am I missing something?
Also, the purpose of XChaCha20 is to encrypt very large chunks of data. And the purpose of
secretstream
is to split a large piece of data into smaller chunks. So I may be missing something but I find it weird to use XChaCha20 instead of ChaCha20.