[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