search

jedisct1 / libsodium

A modern, portable, easy to use crypto library.
https://libsodium.org
Other
12.25k stars 1.74k forks source link

Why crypto_secretstream_chacha20poly1305 is not available? #870

Closed sylvain101010 closed 5 years ago

sylvain101010 commented 5 years ago

Hi,

First of all thank you for this great library!

Why crypto_secretstream_chacha20poly1305 or crypto_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.

jedisct1 commented 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

sylvain101010 commented 5 years ago

Thank you for the quick response!

Just to be sure to understand your point correctly:

  1. You today recommend XChaCha20Poly1305 for both AEAD and secret streams, even if not in the CAESAR winners? (https://github.com/jedisct1/libsodium/issues/554)
  2. XChaCha20Poly130 should be preferred over ChaCha20Poly1305 because it's larger nonce reduces nonce reuse probability (96bits is used in ChaCha20Poly1305_ietfbecause of TLS sessions, but it's too short for a random nonce)?

and a last one:

  1. I know we can't predict the future, but the current 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?
jedisct1 commented 5 years ago

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.

sylvain101010 commented 5 years ago

Merci !

sylvain101010 commented 5 years ago

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.

jedisct1 commented 5 years ago

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.

sylvain101010 commented 5 years ago

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:

  1. to make it crystal clear that XChaCha20Poly1305 is today recommended AEAD cipher

  2. 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.

jedisct1 commented 5 years ago

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.

didactic-drunk commented 5 years ago

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.

jedisct1 commented 5 years ago

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.