AES-256 GCM crypto_stream - are there any plans to support it? about libsodium

[tomekit]

After some initial investigation and given cross-platform availability we will be exploring potential migration towards XChaCha20-Poly1305 which seem to tick all of the boxes. Whilst it would be useful to hear if libsodium plans to support AES-256 GCM streams and if https://github.com/jedisct1/swift-sodium will support AES-256 GCM at all, I am going to close this issue, as I don't feel this deserve to be the TOP1 open issue :)

Thanks for the great work.

[jedisct1]

AES-GCM is authenticated by design. In order to decrypt a ciphertext, even partially, the entire ciphertext has to be seen in order to check the authentication tag, before releasing the decrypted message. It also has a hard limit of 64 GB.

In order to encrypt arbitrary large content, and even support seeking, what you can do is split the content into fixed-size chunks, and encrypt them individually, using the chunk number as a nonce.

Also see https://doc.libsodium.org/secret-key_cryptography/encrypted-messages

[tomekit]

Thank you for your comment.

I am still not sure about splitting content into fixed-size chunk for a video stream, because plaintext content position gets out of sync with ciphertext (due to additional authentication for each fixed-sized chunk).
That means that if a video client (which operates on a decrypted data) requests certain byte position using e.g. HTTP RANGE, server would normally return something which isn't in line with what was requested.
You would then have to make either client or server aware of the cipher construction, which isn't feasible for us (we can't change the S3 protocol and would have to implement video client separately on each platform given our cross-platform support).

That's why I was looking more into unauthenticated territory (think of AES-128 used in HLS streams).
Given that AES-GCM is nothing else than AES-CTR + incremented nonce/IV by 1 + GHASH, I was really thinking of treating the same ciphertext differently depending on the use case / security expectations.

I wouldn't be far away, trying to adjust things with AES and not afraid of Pull Requests, but given we still have an option to switch ciphers, it sounds like sticking to XChaCha20 might be better long-term move in general.