Sorry, I had the wrong email address for Scott. I’m trying to understand some of the concerns that have been raised. I understand that AES-GCM is not exposed to the concerns that Sophie and has raised?
If we used AES-GCM with out of order reception and on-the-fly decryption, would that mitigate the risks? Best Regards, Brendan On Mon, 7 Nov 2022 at 11:03, Brendan Moran <[email protected]> wrote: > I talked with Scott Fluhrer today about this use case and he’s pointed out > that GCM can be processed out of order. > > Scott, would you be able to elaborate on this? > > Best Regards, > Brendan > > On Wed, 26 Oct 2022 at 22:51, Russ Housley <[email protected]> wrote: > >> Scott: >> >> Introducing AES-CTR and/or AES-CBC into COSE tokens that already support >> AES-GCM will open the GCM implementations to new security issues. Namely, >> potential padding oracle vulnerabilities. >> >> >> I think that adding a reference to the existing paragraph in the Security >> Considerations will address this concern: >> >> With AES-CBC mode, implementers SHOULD perform integrity checks prior >> to decryption to avoid padding oracle vulnerabilities [Vaudenay]. >> >> At minimum, the Security Considerations section of >> draft-ietf-cose-aes-ctr-and-cbc-01 needs to call this risk out: >> Applications that encrypt or decrypt with AES-GCM *MUST NOT* support >> AES-GCM or AES-CTR with the same cryptographic materials, due to the >> existence of cross-protocol issues. One way to safeguard users from >> potential misuse is to use a separate "type" for keys used with >> unauthenticated encryption modes; similar to how COSE distinguishes MACs >> from Signatures. >> >> >> I suggest an addition paragraph in the Security Considerations: >> >> To avoid cross-protocol concerns, implementations MUST NOT use the >> same keying material with AES-CTR and AES-GCM. Likewise, >> implementations MUST NOT use the same keying material with AES-CTR >> and AES-CCM. >> >> Additionally, I'd like to recommend sharing this draft with the CFRG >> mailing list to ensure it has the appropriate level of oversight from the >> IETF's cryptography experts. >> >> >> AES-CTR and AES-CBC are not new cryptographic modes. New techniques >> deserve CFRG review, but AES-CTR and AES-CBC have been included in RFCs for >> many years. >> >> Russ >> >> _______________________________________________ >> COSE mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/cose >> >
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
