[Cryptography] Shortening block cipher length...

[John-Mark Gurney]

Peter Gutmann wrote this message on Tue, Jul 20, 2021 at 05:10 +0000:
> Patrick Chkoreff <pc at fexl.com> writes:
> 
> >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
> 
> Thus my proposed addition to the Immutable Laws of Cryptography:
> 
>   "Any cipher or mode that puts a single operation like XOR or addition
>   between the plaintext and an attacker is fundamentally unsafe, no matter how
>   mathematically elegant or provably something-or-other it is".
> 
> (Feel free to quote that wherever you need to :-).
> 
> GCM is doubly unsafe because it relies on both the XOR and the addition in
> order to be secure.  And if you're thinking "who could get an addition
> wrong?", experienced cryptographers, not just generic non-cryptographer
> programmers, have got this wrong because you can do it with an unnoticeable
> single-character typo.

There's a reason why AES-GCM-SIV was created.

https://en.wikipedia.org/wiki/AES-GCM-SIV

Just a FYI, after I thought hard about it, if you want a cipher that is
has authentication with reasonable side channel protections, you will
always need to do two passes of the data for both encryption and
decryption..

For encryption, to generate a secure nonce (ala SIV above), then encrypt...
This is needed to ensure that the encryption depends upon all the plain text
to make it unique.  Wide block (the side of plaintext) effectively does the
same thing...

And for decryption, authenticate the ciphertext first before doing decryption.

> >I wonder if DJB's philosophy regarding your points there is simply:
> 
> ... "when I use this, I know what I'm doing".
> 
> Unfortunately everyone else isn't DJB, and frequently gets it wrong.  To
> paraphrase an old paper on formal methods "stream ciphers are perfectly safe
> when implemented and applied by geniuses.  Unfortunately, geniuses are in
> short supply".
> 
> When I'm asked to do code audits and need a quick result, either because the
> people who asked for the audit don't really think they need anything done or
> sometimes because I'm lazy, the first rule is "shersher la GCM".  With that to
> guide you to where the mistakes are being made, you just keep looking for
> locations where there's IV/counter reuse or ways in which an attacker can
> encourage IV/counter reuse.  Then once you've got the easy break you can
> justify a more in-depth audit, or preferably use of a less unsafe encryption
> mechanism.

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."