[Cryptography] Shortening block cipher length...

Patrick Chkoreff pc at fexl.com
Mon Jul 19 09:16:09 EDT 2021


Ray Dillinger wrote on 7/17/21 12:23 PM:

>       What's wrong with 'counter mode' is that the ciphertext is the
> plaintext XOR some deterministic stream of bits.  This is categorically
> wrong.  This is old-style XOR stream cipher construction and should
> never ever be used anywhere.

Do you consider NaCl to be vulnerable in that regard?

   https://nacl.cr.yp.to/

The reason I ask is that when I decided to build cryptographic functions 
into my functional programming language Fexl, I settled on NaCl because 
I thought Daniel J. Bernstein had done the most thorough job of thinking 
through all the relevant issues.  So I took the TweetNaCl code and 
refactored it to eliminate its plethora of macros (some of which even 
involve forward references!) to arrive at plain C code, which I assert 
is both functionally and operationally equivalent to the original.

Now, in light of the case you make here against XOR stream ciphers, I am 
concerned about this function which appears in DJB's code:

   stream_xor


> It suffers from three categories of attack that proper ciphers do
> not.  First, known or guessed  plaintext exposes the deterministic
> stream of bits, which can then be inspected or attacked more easily.
> Second, known or guessed deterministic stream of bits (as happens when
> someone fails to initialize their PRNG properly) exposes plaintext.
> Third, an attacker can modify the plaintext arbitrarily at known bit
> positions and offsets regardless of the deterministic stream of bits.
> Controlling for, detecting, and preventing this sort of shenanigans
> makes XOR stream ciphers fragile - far too easy to get wrong and far too
> easy to make with usage limitations and requirements that users and
> implementors will inadvertently violate.

I wonder if DJB's philosophy regarding your points there is simply:

0. Do not reuse a nonce.

1. Do not reuse a nonce.

2. Because you did not reuse a nonce, it does not matter if someone can 
use a known plaintext to reveal cipher stream bits.

3. Because you did not reuse a nonce, no one will ever be able to guess 
your stream cipher bits.


>       XOR stream ciphers, including counter mode, should be regarded as
> insecure.  Not because they are based on flawed theory. But in practical
> terms making sure of all the steps and requirements to get what theory
> says you should, can go wrong too easily.
> 
>       Counter mode, classically, is P XOR E(Ctr) = C.  Using the same set
> of operations the same number of times each you can implement a clearly
> superior counter mode E(P XOR Ctr) = C.  This second mode suffers none
> of the above indignities and makes no sacrifice in efficiency.  It
> dominates the original XOR counter mode in security vs. efficiency,
> requiring no new operations.  Therefore there is no excuse for using the
> original XOR counter mode ever again.

I would be willing to implement different primitives for authenticated 
encryption, other than DJB's.  I find your "superior counter mode" quite 
appealing.  However, I would need a very solid and stable algorithm with 
plenty of known test cases.

In the meantime I have deferred to the authority of Daniel J. Bernstein, 
but that is not cast in stone.


-- Patrick


More information about the cryptography mailing list