[Cryptography] Shortening block cipher length...

[Natanael]

Den tis 20 juli 2021 20:21Peter Gutmann <pgut001 at cs.auckland.ac.nz> skrev:

> Patrick Chkoreff <pc at fexl.com> writes:
>
> >I believe in the case of NaCl, "knowing what you're doing" is simply this:
> >
> >0. Do not reuse a nonce.
>
> And that, along with telling people "don't write code that's vulnerable to
> buffer overflows", "dont write code that facilitates SQLI and XSS", and
> "don't
> write code that gets access control wrong" is all we need to do to ensure
> things are completely secure.  QED.
>
> >Does one have to be a genius to read 24 bytes from /dev/urandom?
>
> To do that, you first have to know what a nonce is.  Then you have to know
> why
> it's important.  Then you have to know how to use it and how not to use it.
> Then you have to be able to design and implement something where an
> attacker
> can't force nonce reuse in some way.  And finally you have to design and
> implement everything 100% flawlessly and perfectly (see my previous comment
> about the expert cryptographer and the 1-character typo).
>
> Overall, it's about the same level of difficulty as avoiding buffer
> overflows
> or SQLI.  Meaning that in real life people get it wrong over and over and
> over, just look at the history of (mis)use of RC4 to see this.
>

Even if a given program does try to do exactly the right thing with
randomness handling, it will still be dependent on its environment. And
even the OS RNG might not be trustworthy in many environments.

For example when old Android versions used to have an insecure RNG exposed
by default in its Java environment, which led to loss of funds via Bitcoin
wallets (ECDSA k value reuse). Or embedded devices with no hardware RNG
which generates keys on first boot, where most of them end up generating
identical device keys.

In these circumstances it doesn't even matter that the programmer knew what
they were doing.

Or for a more modern variant of this problem, why not consider virtualized
code running in containers or VM:s. These frequently don't have a real RNG
exposed from the host (the option may exist but isn't always enabled), or
where a running application's state may be snapshotted and replicated into
multiple instances, including the creation of multiple instances of "single
use" secrets.

If you insist on using a stream cipher for anything but an actual stream of
data (like a TLS connection) for which you can make a plausible argument
for why a key/IV is unlikely to be reused, then the only robust option is a
SIV construction or equivalent MRAE modes (for example AES-GCM-SIV). SIV
like modes uses the message and key as inputs to derive the IV (so it's
two-pass), so different messages encrypted under the same key are highly
unlikely to get the same IV even if you have a bad RNG. But at this point
you start to lose some of the simplicity and performance advantages of
stream ciphers anyway.

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.metzdowd.com/pipermail/cryptography/attachments/20210720/dd54eb03/attachment.htm>