[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Cryptography] Shortening block cipher length...

On 7/22/2021 6:17 AM, Richard Outerbridge wrote:
n 2021-07-21 (202), at 23:43:20, Christian Huitema <huitema AT huitema.net> wrote:

On 7/20/2021 6:48 PM, Ray Dillinger wrote:
On 7/20/21 6:11 PM, Peter Gutmann wrote:
Ray Dillinger <bear AT sonic.net> writes:

I don't think NaCl as it is today is vulnerable
Unless it's changed recently, the NaCL API assumes the nonce is user-supplied,
which means it's completely vulnerable.  It's RC4 as used in the 1990s all
over again.

Aw crap.  I'm so sorry to hear that, I thought it was better.
For AEAD, both ends of a communication channel have to agree on what the nonce is, and communication protocols have to specify that. For example, the nonce used in QUIC is a 64 bit packet number, guaranteed to occur at most once for the duration of the connection. But only the least significant bits of the packet number are sent in the packet, the rest is inferred. Which means the nonce is only known by the protocol logic. There has to be an API to pass it to the implementation of AES-GCM or ChaCha-poly. Which means the crypto library API needs to assume that the nonce is user supplied.
In this case it sounds like the nonce has become (more or less) a PSK.

Except it is not really "Private". Observers can count packets and make a pretty good guess of the value of the sequence number. There is definitely no claim that the nonce is not predictable in QUIC, and no particular engineering effort to make it so. No point replicating for the nonce the work made to protect the encryption keys.

-- Christian Huitema

The cryptography mailing list
cryptography AT metzdowd.com