Key commitment approach could be simplified?

[jedisct1]

@jackloomen wrote:

https://github.com/jedisct1/libsodium-doc/blob/master/secret-key_cryptography/aead.md#robustness

Prepend H(key, nonce || ciphertext_tag) to the ciphertext

By including ciphertext_tag in the equation it may give a false sense of security in the approach, H(key, nonce) is sufficient to > commit to the key. ciphertext_tag adds nothing. Bypassing it would require changing the prepended segment regardless.

It is also wasteful compared to:

Prepend 128 or 256 zero-bits to payload prior to encryption, verify their presence on decryption.
Which achieves the same objective.

[jedisct1]

@jackloomen wrote:

you can replace H(key,nonce,ad,ciphertext_tag) with H(key2,nonce,ad,ciphertext_tag) too
the best you can do with H() if you don't replace tag with hmac is to include proof of key,nonce. that would be sufficient to > prove to receiver that the payload is intended to be decrypted with key.

"wouldn't bind the key to the message nor the AD" is not achievable without a collision resistant aead tag.

https://hybridkey.me/2023/02/07/aead-key-commitment.html

CTX is very easy to implement and you get full commitment.

C, T ← nAEAD(K, N, A, M)
T* ← H(K, N, A, T)
C || T*

[jedisct1]

There are better alternatives than CTX:

https://csrc.nist.gov/csrc/media/Presentations/2023/landscape-of-committing-authenticated-encryption/images-media/sess-2-hoang-bcm-workshop-2023.pdf

[ghost]

CTX+ is a good minor optimization.

Committing Concealer is clever but unfortunately AES is not an ideal cipher.
AES is known to have a weak key schedule.

I expect that construction to remain academic.

[jedisct1]

These recommendations in the documentation predate the papers on key commitment. They offer 64 bit security, which is enough to prevent online attacks. Most importantly, they are very simple to implement given the existing APIs.

CTX+ and Committing Concealer are nice, there's another paper to be published soon that doesn't require a hash function, but these can't be implemented using libsodium. So, this is not very useful in this context.

This is a hot topic right now, new generic or specific constructions are going to come out of this, and once the dust settles, dedicated APIs can be added.

In the meantime, status quo looks fine. It can easily be implemented using the library the documentation is about, and there's a faster option that offers 128 bit commitment.