[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Cryptography] Shortening block cipher length...
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?
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:
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.
The cryptography mailing list
cryptography AT metzdowd.com