[Cryptography] Crypto best practices

[Natanael]

Den 21 mars 2017 10:36 skrev "Kristian Gjøsteen" <kristian.gjosteen at ntnu.no
>:

20. mar. 2017 kl. 19.54 skrev Natanael <natanael.l at gmail.com>:
>
> Den 19 mar 2017 23:50 skrev "Kristian Gjøsteen" <kristian.gjosteen at ntnu.no
>:
>
>> What practical people appear to worry about is that you need to process
the entire message before you can begin producing ciphertext. This seems to
be a requirement for misuse-resistant modes, and it is probably possible to
prove a theorem to that effect.
>
> As for a quick demonstration of that you can have secure "streaming
behavior" without needing to start off with a full pass on the plaintext /
ciphertext before final encryption / decryption:

Note that misuse-resistant means that in the event of IV reuse, all you
reveal is whether two plaintexts are equal.

Your proposals reveal whether two plaintexts have an identical prefix,
which is too much. So in the context of my claim, they are irrelevant.


Going by such a strict requirement, then of course - in order to completely
prevent any leakage of which ranges of plaintext blocks that are identical
across different encryptions under the same key+IV, then the change of any
plaintext bit must also change the full ciphertext. (I believe that's also
called an "all-or-nothing transform", where any change anywhere must modify
all ciphertext bits, not just make a local change.)

This means you do need to process the entire plaintext before encryption,
and making the encryption dependent on the full plaintext. For example it
could mean that you first would need to hash (HMAC?) the full plaintext
file and use that hash as an input to the encryption, such as using it as
the IV. (Another sidenote, Tahoe-LAFS already does something like this too
with its "convergent encryption" mode - and streaming decryption is still
possible.)

I'm however not convinced that such a strict misuse resistance requirement
is *always* necessary, there's definitely a lot of different levels to the
degree of protection necessary. Hopefully in most cases where this level of
metadata protection matters you wouldn't actually need the cipher mode to
be the (only) component to achieve this (I'm assuming there normally would
be multiple layers of security in the way).

Full misuse resistance creates a lot of overhead in both bandwidth/disk
access and CPU load, so there's good reasons to not always use it. This
level of protection would definitely be impractical for most interactive
network protocols, to start with, where you would have to hope that the key
exchange provides unique keys for every session (a predictable
all-or-nothing encryption key protects exactly nothing).
And if your FDE software can't securely handle IV:s, then you probably have
bigger problems.

There is simply limits to how far you can idiot-proof something, and if
your higher layers are broken then the crypto can't save you. Garbage in -
garbage out. Crypto can only package it better.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20170321/9a1a61c6/attachment.html>