<div dir="auto"><div data-smartmail="gmail_signature" dir="auto"><br></div><div class="gmail_extra" dir="auto"><div class="gmail_quote">Den 21 mars 2017 10:36 skrev "Kristian Gjøsteen" <<a href="mailto:kristian.gjosteen@ntnu.no" target="_blank">kristian.gjosteen@ntnu.no</a>>:<br type="attribution"><blockquote class="m_-7700093703363167719quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="m_-7700093703363167719quoted-text">20. mar. 2017 kl. 19.54 skrev Natanael <<a href="mailto:natanael.l@gmail.com" target="_blank">natanael.l@gmail.com</a>>:<br>
><br>
> Den 19 mar 2017 23:50 skrev "Kristian Gjøsteen" <<a href="mailto:kristian.gjosteen@ntnu.no" target="_blank">kristian.gjosteen@ntnu.no</a>>:<br>
><br>
>> 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.<br>
><br>
</div><div class="m_-7700093703363167719quoted-text">> 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:<br>
<br>
</div>Note that misuse-resistant means that in the event of IV reuse, all you reveal is whether two plaintexts are equal.<br>
<br>
Your proposals reveal whether two plaintexts have an identical prefix, which is too much. So in the context of my claim, they are irrelevant.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">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.) </div><div dir="auto"><br></div><div dir="auto">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.) </div><div dir="auto"><br></div><div dir="auto"><span style="font-family:sans-serif">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. </span><span style="font-family:sans-serif">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). </span></div><div dir="auto"><span style="font-family:sans-serif"><br></span></div><div dir="auto"><span style="font-family:sans-serif">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. T</span>his 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).</div><div dir="auto">And if your FDE software can't securely handle IV:s, then you probably have bigger problems.</div><div dir="auto"><br></div><div dir="auto"><span style="font-family:sans-serif">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. </span></div></div>