Hi Christian, Yes, sending to the quic list is a good idea. I think QUIC is likely to be used in a huge number of future use cases. Secure short tags might be interesting for more use cases than Media over QUIC.
Christian Huitema wrote: >If the "short tags" can save per packet overhead while maintaining security >properties The short tags do increase the forgery probability. The security is only ideal with respect to the tag length. For general applications like HTTP/3 I think you would like to keep the forgery probability per packet close to the current level. In QUIC my understanding is that the maximum plaintext is 2^12 128-bit blocks and the length of the associated data is negligible. The security level of the 128-bit AES-GCM tags is therefore t – log2(n + m + 1) ≈ 128 - 12 = 116 bits. With AES-GCM-SST in QUIC you would get ideal forgery probability ≈ 2^-t for tags of length t <= 14 bytes. Cheers, John From: CFRG <[email protected]> on behalf of Christian Huitema <[email protected]> Date: Sunday, 7 May 2023 at 20:07 To: John Mattsson <[email protected]>, IRTF CFRG <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]> Subject: Re: [CFRG] [Moq] FW: New Version Notification for draft-mattsson-cfrg-aes-gcm-sst-00.txt John, You should probably send this to the QUIC list as well. Media over QUIC is just one application of QUIC. If the "short tags" can save per packet overhead while maintaining security properties, then they are interesting for many QUIC applications. -- Christian Huitema On 5/5/2023 7:45 AM, John Mattsson wrote: > Hi, > > We just submitted draft-mattsson-cfrg-aes-gcm-sst-00. Advanced Encryption > Standard (AES) with Galois Counter Mode with Secure Short Tags (AES-GCM-SST) > is very similar to AES-GCM but have short tags with forgery probabilities > close to ideal. The changes to AES-GCM were suggested by Nyberg et al. in > 2005 as a comment to NIST and are based on proven theoretical constructions. > > AES-GCM performance with secure short tags have many applications, one of > them is media encryption. Audio packets are small, numerous, and ephemeral, > so on the one hand, they are very sensitive in percentage terms to crypto > overhead, and on the other hand, forgery of individual packets is not a big > concern. > > Cheers, > John > > From: [email protected] <[email protected]> > Date: Friday, 5 May 2023 at 16:33 > To: John Mattsson <[email protected]>, Alexander Maximov > <[email protected]>, John Mattsson <[email protected]>, > Matt Campagna <[email protected]>, Matthew Campagna <[email protected]> > Subject: New Version Notification for draft-mattsson-cfrg-aes-gcm-sst-00.txt > > A new version of I-D, draft-mattsson-cfrg-aes-gcm-sst-00.txt > has been successfully submitted by John Preuß Mattsson and posted to the > IETF repository. > > Name: draft-mattsson-cfrg-aes-gcm-sst > Revision: 00 > Title: Galois Counter Mode with Secure Short Tags (GCM-SST) > Document date: 2023-05-05 > Group: Individual Submission > Pages: 16 > URL: > https://www.ietf.org/archive/id/draft-mattsson-cfrg-aes-gcm-sst-00.txt > Status: > https://datatracker.ietf.org/doc/draft-mattsson-cfrg-aes-gcm-sst/ > Html: > https://www.ietf.org/archive/id/draft-mattsson-cfrg-aes-gcm-sst-00.html > Htmlized: > https://datatracker.ietf.org/doc/html/draft-mattsson-cfrg-aes-gcm-sst > > > Abstract: > This document defines the Galois Counter Mode with Secure Short Tags > (GCM-SST) Authenticated Encryption with Associated Data (AEAD) > algorithm. GCM-SST can be used with any keystream generator, not > just a block cipher. The main differences compared to GCM [GCM] is > that GCM-SST uses an additional subkey Q, that fresh subkeys H and Q > are derived for each nonce, and that the POLYVAL function from AES- > GCM-SIV is used instead of GHASH. This enables short tags with > forgery probabilities close to ideal. This document also registers > several instances of Advanced Encryption Standard (AES) with Galois > Counter Mode with Secure Short Tags (AES-GCM-SST). > > This document is the product of the Crypto Forum Research Group. > > > > > The IETF Secretariat > > _______________________________________________ CFRG mailing list [email protected] https://protect2.fireeye.com/v1/url?k=31323334-501cfaf3-313273af-454445554331-9034b67a44f3143f&q=1&e=59d3bb57-6543-430e-8ba2-f3a9248d7619&u=https%3A%2F%2Fwww.irtf.org%2Fmailman%2Flistinfo%2Fcfrg
