Here is the approach I use for encryption which guards against the IV attack. It might seem a little over the top but the objective here is to minimize the number of code paths rather than the length of the code path.
The reason I started on this approach was I was looking for a secure way to encrypt chat room logs etc. without having to do a key exchange per message. In the process, I realized that the same approach works remarkably well in S/MIME like applications where we may have multiple multiparts that we want to encrypt under one key exchange, we may want to encrypt subject lines and we may want to encrypt signatures over the plaintext.
1) Generate fresh session key of at least 256 bits which has the property of being infeasible to guess (note that unguessability is a stronger requirement than merely being random).
2) Perform a key exchange for each recipient.
2a) If it is a DH or EDH key exchange, use the key exchange result as the IKM for a KeyDerivation function with info tag "master". Then use the resulting key to perform an AES Key Wrap of the session key.
3) Create the Enhanced Data Sequences.
For each EDC we create a salt value which needs to be unique within the context of this particular exchange.
We then use HKDF to derive the encryption (+MAC if needed) and IV.
This approach ensures that the IV is chosen in a rigid fashion and thus eliminates a possible area of manipulation as any change to the salt will prevent decryption and authentication of the message as well.
On Mon, May 14, 2018 at 12:39 PM, Richard Barnes <rlb@xxxxxx> wrote:
Russ: Is there some more work to be done here to address the CBC/CFB issues? Even if the encapsulation has AEAD support, maybe there's some negotiation thingy?On Mon, May 14, 2018, 12:37 Russ Housley <housley@xxxxxxxxxxxx> wrote:______________________________On May 14, 2018, at 12:35 PM, Paul Wouters <paul@xxxxxxxxx> wrote:On May 14, 2018, at 12:29, Russ Housley <housley@xxxxxxxxxxxx> wrote:
We are working on text for S/MIME that says that each portion of a MIME multi-part needs to be handled in its own sandbox. The direct exfiltration that is described happens because the mail user agent glues the various portions together for display to the user, which in the example on the web page causes an image to be fetched from the attacker's website with the message plaintext as part of the URL.
So that’s the bandaid. What and where will work be done on a solution?LAMPS just sent an update to the S/MIME message document to the IESG. My guess is that there will be discussion on the spasm@xxxxxxxx mail list.Russ_________________
Spasm mailing list
Spasm@xxxxxxxx
https://www.ietf.org/mailman/listinfo/spasm
