[Cryptography] Shortening block cipher length...

[Patrick Chkoreff]

Peter Gutmann wrote on 7/20/21 2:11 PM:
> 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.

I think it overstates the case to say that because the nonce is 
user-supplied, that implies that using the NaCl API is "completely 
vulnerable."  It is only vulnerable if you reuse a nonce.  If you pass 
in 192 bits collected from an unpredictable source, you are highly 
unlikely to reuse a nonce.

In DJB's code, he calls an undefined function called "random" to collect 
random data for both (1) secret keys and (2) nonces.  He assumes you'll 
link to some suitable definition of "random".

Instead of doing it that way, I refactored the code so it has no call to 
an undefined "random", but rather works deterministically from random 
data that the user produces independently and passes in.  For example, 
there is no call to generate a "random key pair".  Instead there is a 
deterministic function which maps a secret key to its corresponding 
public key.

Then on the outside of those functions, I make calls to grab random data 
to generate secret keys on nonces.


Ray Dillinger wrote:

> Aw crap.  I'm so sorry to hear that, I thought it was better.

What would make it better?  If DJB's code produced the 24 random bytes 
for you, so you didn't have to pass it in?  The outside surface of my 
code does exactly that, so at THAT level of my API, the user doesn't 
have to pass it in.


-- Patrick