<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Den tis 3 aug. 2021 08:02Peter Gutmann <<a href="mailto:pgut001@cs.auckland.ac.nz">pgut001@cs.auckland.ac.nz</a>> skrev:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Michael Kjörling <<a href="mailto:michael@kjorling.se" target="_blank" rel="noreferrer">michael@kjorling.se</a>> writes:</blockquote></div></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
>you might want to very strongly consider using, or at the very least<br>
>supporting, multiple hashes formatted in some standardized manner, instead of<br>
>mandating any one hash algorithm in particular.<br>
<br>
No, please don't.  This leads to the XML mess where there's a million<br>
different algorithms and modes and all of them provide the freedom to get them<br>
completely wrong in dozens of ways.  Apply Grigg's Law, "There is only one<br>
mode and that is secure".  Embedded key -> HKDF -> AES+HMAC should do what you<br>
need and leave little ambiguity for flaws.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">My only disagreement here is that in the hypothetical case that the current algorithm is found to be insecure in the future, we need a way to deprecate the old algorithm and transition to the new one. A lot of problems with old cryptography comes from the inability to deprecate the old algorithm, which once was assumed to never need to be replaced. </div><div dir="auto"><br></div><div dir="auto">If that might mean you go up one protocol version number and break compatibility then do be it, but at least ensure there's an agreed upon way to do it. (Also, don't forget downgrade resistance.) </div><div dir="auto"><br></div><div dir="auto">I agree with the "one algorithm" approach in one sense - the entire value from cipher agility is all from the ability to deprecate old algorithms which we found to be insecure, so if all you do is allowing new algorithms to be added while doing nothing to remove old ones, then you haven't added any security. </div><div dir="auto"><br></div><div dir="auto">---</div><div dir="auto"><br></div><div dir="auto">Separate note, for arbitrarily seekable encryption in very large files there's existing constructions like STREAM (chained chunks of AEAD encryption) and the Tahoe-LAFS construction of a signed Merkle tree hash over the ciphertext (a variant of this was already mentioned in this thread).</div><div dir="auto"><br></div><div dir="auto">I very strongly support using modes with arbitrarily seekable authenticated encryption using constructions like these. I would especially like to point out that in cases like key/IV reuse when encrypting, typical algorithms which don't use full-ciphertext authentication will allow an adversary to cut-and-paste sections of ciphertext with valid "local" authentication tags from different sections of different encrypted messages. But full-ciphertext authentication is a close approximation to all-or-nothing transforms, which is the ideal for encryption. </div><div dir="auto"><br></div><div dir="auto">For a protocol which is both encryption at rest and message encryption, which email encryption is, there's a double threat model which makes this part extra important. </div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote></div></div></div>