I think there were two issues identified. 1. Encrypting multiple plain texts with the same key and IV is defiantly a bad thing., and it is relatively easy to see why. 2. Encrypting the same plaintext multiple times with the same IV and CMK but changing the AAD. The problem with this is slightly less clear. There will be multiple tags generated one for each different AAD. To produce the tag you encrypt the final hash value with the block is xored with the IV block encrypted with the CMK.
I don't personally know of an attack that can exploit having multiple tags xored with the same value. My take on it from Mc Grew's comment on the list was it is probably not a good thing. I think Mike and I both took from the conversation that producing multiple tag values that are xord with the same encrypted value is not something that was recommended. If I have that wrong now would be a good time to say that the practice is OK. Regards John B. On 2013-04-25, at 6:40 PM, Russ Housley <[email protected]> wrote: > Mike: > > The same message encrypted with different GCM keys is a problem, but that is > not what ought to be going on here. I tried to explain that in my previous > message. The same GCM key is delivered to multiple recipients, perhaps using > different key management techniques. Since the originator and all of the > recipients use exactly the same key stream, this XOR concern does not arise. > > Russ > > > On Thu, Apr 25, 2013 at 2:48 AM, Mike Jones <[email protected]> > wrote: > Jim - I am surprised that you would say that my co-authors Eric Rescorla or > Joe Hildebrand or the working group would advocate using AES GCM in a way > that would result in severe security vulnerabilities - in particular, > allowing attackers to obtain the XOR of the messages to multiple recipients > encrypted using GCM - a vulnerability identified by the CFRG. > > Not stating this in the document would seem to me to be highly irresponsible, > given the brittleness of GCM in this regard, as identified by the CRFG. As I > said to Richard Barnes over dinner last night, while unpleasant, and possibly > surprising to those who aren't familiar to how GCM actually works, as an > editor, I viewed including the statement that "AES GCM MUST NOT be used when > using the JWE JSON Serialization for multiple recipients, since this would > result in the same Initialization Vector and Plaintext values being used for > multiple GCM encryptions" as necessary, and "truth in advertising". > > -- Mike > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of Jim > Schaad > Sent: Wednesday, April 24, 2013 9:07 PM > To: Mike Jones > Cc: [email protected] > Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.txt > > Mike, > > AES GCM MUST NOT be used when using the JWE JSON Serialization for > multiple recipients, since this would result in the same > Initialization Vector and Plaintext values being used for multiple > GCM encryptions. > > I doubt your co-authors would agree with this. > I doubt the working group with agree with this. > I know that at least one co-chair does not agree with this I can predict that > the AD and IESG along with the security directorate would crucify me if I > allowed this to stand in the document.. > > Jim > > > > > -----Original Message----- > > From: [email protected] [mailto:[email protected]] On Behalf > > Of [email protected] > > Sent: Tuesday, April 23, 2013 5:29 PM > > To: [email protected] > > Cc: [email protected] > > Subject: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.txt > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the Javascript Object Signing and > > Encryption Working Group of the IETF. > > > > Title : JSON Web Encryption (JWE) > > Author(s) : Michael B. Jones > > Eric Rescorla > > Joe Hildebrand > > Filename : draft-ietf-jose-json-web-encryption-09.txt > > Pages : 54 > > Date : 2013-04-23 > > > > Abstract: > > JSON Web Encryption (JWE) is a means of representing encrypted > > content using JavaScript Object Notation (JSON) data structures. > > Cryptographic algorithms and identifiers for use with this > > specification are described in the separate JSON Web Algorithms (JWA) > > specification. Related digital signature and MAC capabilities are > > described in the separate JSON Web Signature (JWS) specification. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-encryption > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-09 > > > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=draft-ietf-jose-json-web-encryption-0 > > 9 > > > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > jose mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/jose > > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose > > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
