[Cryptography] How should we encrypt external mail attachments

[Natanael]

Den tis 3 aug. 2021 08:02Peter Gutmann <pgut001 at cs.auckland.ac.nz> skrev:

> Michael Kjörling <michael at kjorling.se> writes:


> >you might want to very strongly consider using, or at the very least
> >supporting, multiple hashes formatted in some standardized manner,
> instead of
> >mandating any one hash algorithm in particular.
>
> No, please don't.  This leads to the XML mess where there's a million
> different algorithms and modes and all of them provide the freedom to get
> them
> completely wrong in dozens of ways.  Apply Grigg's Law, "There is only one
> mode and that is secure".  Embedded key -> HKDF -> AES+HMAC should do what
> you
> need and leave little ambiguity for flaws.
>

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.

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.)

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.

---

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).

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.

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.

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