[Cryptography] Shortening block cipher length...

[Phillip Hallam-Baker]

On Thu, Jul 22, 2021 at 1:02 AM 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.
> >>
> >> Peter.
> >
> > 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.
>
> -- Christian Huitema
>

I would consider the application choosing the nonce for me to be an
anti-pattern because it creates a side channel that allows the crypto
implementation to leak information.

I don't trust any implementation 100% and random number generators are
particularly suspect. So as a general rule I consider the raw output of a
random number generator to be sensitive and never reveal it to any other
party without processing it through a one way function.

My preferred construction is to use an HMAC under a secret key to
post-process the RNG output.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.metzdowd.com/pipermail/cryptography/attachments/20210722/76c5343a/attachment.htm>