Request: AEAD_AES_256_GCM_SIV

[aantron]

Looking at libsodium docs,

Unlike other variants directly using the ChaCha20 cipher, generating a random nonce for each message is acceptable with this XChaCha20-based construction, provided that the output of the PRNG is indistinguishable from random data.

I am seeing similar claims elsewhere.

This seems like a desirable property, as I am concerned about key wearout in an application that is using AEAD. So, I'd like to request XChaCha20 support.

I don't know if XChaCha20 brings any new pitfalls of its own, and is studied well enough.

[aantron]

AES-256-GCM-SIV from RFC 8452 may be a good alternative.

[hannesm]

I'm not sure what you're asking for. Is there a specification and test vectors for "XChaCha20-Poly1305" available? Could it be implemented on top of the existing API?

With your second comment, does this mean you're asking instead (or in addition) for AES-256-GCM-SIV support in this library? (Again, could it be implemented on top of the existing API?)

[aantron]

@hannesm, after a lot more reading, I have the impression that AES-256-GCM-SIV is the better option, compared to XChaCha20-Poly1305. I changed the title accordingly.

Yes, I am (weakly) requesting this library support it. I'm not familiar enough with all the AES modes to say that it definitely can't be implemented on top of the existing API. However, I am almost certain that it can't be implemented on top of AES-GCM. It uses a different function for the authentication tag. I understood also (I hope correctly) that AES-GCM-SIV has to compute the authentication tag before beginning encryption, while AES-GCM doesn't. If that's correct, I imagine AES-GCM-SIV and AES-GCM implementations are somewhat different, unless AES-GCM is implemented in a "weird" way to also (needlessly in its case) compute the authentication tag separately first.