Subject: [CFRG] SRTP: Any work on more cryptoalgorithms?

From: Harald Alvestrand <[email-masked]>
Date: Tue, 1 Feb 2022 15:39:04 +0100

In a review of SRTP cryptoalgorithms done recently, we figured out that 
if we want to deploy a ciphersuite that:

- does not depend on SHA-1

- uses AES

- supports AEAD

there are only two possibilities: AEAD_AES_128_GCM and AEAD_AES_256_GCM

Both of these add 16 bytes of overhead per packet, which is a lot for an 
audio stream.

Is there anyone performing work to develop, evaluate or register a 
cryptosuite with reasonable properties and a lower per-packet overhead?

Harald

---

From: Tushar Patel <[email-masked]>
Date: Tue, 1 Feb 2022 07:01:38 -0800

Hi Harold,

I am working on ATNA, it is a new cipher-mode that addresses several issues
in AEAD/GCM. It is in the internal review process.

Thx.,
Tushar

On Tue, Feb 1, 2022 at 6:39 AM Harald Alvestrand <[email-masked]>
wrote:

> _______________________________________________
> CFRG mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/cfrg
>

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 1 Feb 2022 17:01:00 +0100

On 2/1/22 16:01, Tushar Patel wrote:
> Hi Harold,
>
> I am working on ATNA, it is a new cipher-mode that addresses several 
> issues in AEAD/GCM. It is in the internal review process.

Internal CFRG review, or internal company review? I'm not sure how these 
things work... just joined the list today.

>
> Thx.,
> Tushar
>
> On Tue, Feb 1, 2022 at 6:39 AM Harald Alvestrand 
> <[email-masked]> wrote:
>

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Tue, 1 Feb 2022 20:00:07 +0000

Indeed, there are some issues with GCM mode.

However, given that we have AES-GCM-SIV, and several winners of the CAESAR contest – do we really need yet another mode?

I personally like SIV. Other options are fine too.

-- 

V/R,

Uri

From: CFRG <[email-masked]> on behalf of Tushar Patel <[email-masked]>
Date: Tuesday, February 1, 2022 at 10:02
To: Harald Alvestrand <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [CFRG] SRTP: Any work on more cryptoalgorithms?

Hi Harold,

I am working on ATNA, it is a new cipher-mode that addresses several issues in AEAD/GCM. It is in the internal review process.

Thx.,

Tushar

On Tue, Feb 1, 2022 at 6:39 AM Harald Alvestrand <[email-masked]> wrote:

- uses AES

- supports AEAD

Harald

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 1 Feb 2022 21:06:23 +0100

On 2/1/22 21:00, Blumenthal, Uri - 0553 - MITLL wrote:
> However, given that we have AES-GCM-SIV, and several winners of the 
> CAESAR contest – do we really need yet another mode?
>

But are any of these options fully specified and registered for use with 
SRTP (Secure Real Time Protocol)?

I am worried that we may be in the all-too-common situation where some 
cryptographers decide that a problem is solved, but the 
non-cryptographers who need to use these cryptosuites don't have enough 
information to actually implement them in practice - someone needs to 
bridge the gap, with something like RFC 7714 (the registry document for 
the AEAD-AES-*-GCM modes).

If someone needs to do the work to fill that gap - who should we ask to 
be that someone?

> -- 
>
> V/R,
>
> Uri
>
> *From: *CFRG <[email-masked]> on behalf of Tushar Patel 
> <[email-masked]>
> *Date: *Tuesday, February 1, 2022 at 10:02
> *To: *Harald Alvestrand <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>
> *Subject: *Re: [CFRG] SRTP: Any work on more cryptoalgorithms?
>
> Hi Harold,
>

---

From: Michael StJohns <[email-masked]>
Date: Tue, 1 Feb 2022 15:23:49 -0500

On 2/1/2022 9:39 AM, Harald Alvestrand wrote:
> Both of these add 16 bytes of overhead per packet, which is a lot for 
> an audio stream.

The overhead for these is entirely in the length of the authentication tag.

RFC7144 has:

> Size of the Authentication Tag
>
>     We require that the AEAD authentication tag be 16 octets, in order to
>     effectively eliminate the risk of an adversary successfully
>     introducing fraudulent data.  Though other protocols may allow the
>     use of truncated authentication tags, the consensus of the authors
>     and the working group is that risks associated with using truncated
>     AES-GCM tags are deemed too high to allow the use of truncated
>     authentication tags in SRTP/SRTCP.

Which suggests the authors specifying for a worst case scenario and 
assuming a lack of any other verification on the underlying plain text 
stream AND national level adversaries.

Given that the NIST SP800-38D publication actually permits tag lengths 
shorter (e.g. 15, 14, 13, 12), or even in special cases 8 or 4 (section 
5.2.1 and appendix C), it's unclear to me why this was made a hard and 
fast rule in RFC7144 especially since that document doesn't include any 
reference to document with this guidance with related analysis.

Later, Mike

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Tue, 1 Feb 2022 20:36:25 +0000

Authentication Tag can be truncated, for both -GCM and -SIV modes. We did some work studying the security impacts of that.

For saving bits on the wire, IV/Nonce can and should be implicit.

TNX

-- 

V/R,

Uri

From: CFRG <[email-masked]> on behalf of Michael StJohns <[email-masked]>
Date: Tuesday, February 1, 2022 at 15:24
To: CFRG <[email-masked]>
Subject: Re: [CFRG] SRTP: Any work on more cryptoalgorithms?

Both of these add 16 bytes of overhead per packet, which is a lot for an audio stream. 

RFC7144 has:
 
Which suggests the authors specifying for a worst case scenario and assuming a lack of any other verification on the underlying plain text stream AND national level adversaries. 

Given that the NIST SP800-38D publication actually permits tag lengths shorter (e.g. 15, 14, 13, 12), or even in special cases 8 or 4 (section 5.2.1 and appendix C), it's unclear to me why this was made a hard and fast rule in RFC7144 especially since that document doesn't include any reference to document with this guidance with related analysis.

Later, Mike

---

From: Michael StJohns <[email-masked]>
Date: Tue, 1 Feb 2022 16:48:24 -0500

On 2/1/2022 3:36 PM, Blumenthal, Uri - 0553 - MITLL wrote:
>
> Authentication Tag can be truncated, for both -GCM and -SIV modes. We 
> did some work studying the security impacts of that.
>
So the "We require that the AEAD authentication tag be 16 octets" of RFC 
7144 can be ignored?

Is there a follow on document that waives the requirement?

Mike

> *From: *CFRG <[email-masked]> on behalf of Michael StJohns 
> <[email-masked]>
> *Date: *Tuesday, February 1, 2022 at 15:24
> *To: *CFRG <[email-masked]>
> shorter (e.g. 15, 14, 13, 12), or even in special cases 8 or 4 
> (section 5.2.1 and appendix C), it's unclear to me why this was made a 
> hard and fast rule in RFC7144 especially since that document doesn't 
> include any reference to document with this guidance with related 
> analysis.
>
> Later, Mike
>

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Tue, 1 Feb 2022 22:29:56 +0000

>> Authentication Tag can be truncated, for both -GCM and -SIV modes.
>> We did some work studying the security impacts of that.
>
> So the "We require that the AEAD authentication tag be
> 16 octets" of RFC 7144 can be ignored?

It should be obvious that we did our work outside the scope of RFC 7144. 

Though it's worth noting that NIST specifies auth tag shorter than 128 bits (NIST SP 800-38D).

> Is there a follow-on document that waives the requirement?

Unfortunately, no - or not yet.

Decision whether to waive this requirement depends heavily on the use case. 

If one's protocol can afford the extra (96) bits of explicit nonce and 128-bit auth tag - by all means, that would be the most secure design.

Ours - couldn't, so we went for a trade-off, getting "sufficient" security (considering frequency of key change, etc.) while satisfying the protocol/environment constraints.

From: CFRG mailto:[email-masked] on behalf of Michael StJohns mailto:[email-masked]
Date: Tuesday, February 1, 2022 at 15:24
To: CFRG mailto:[email-masked]
Subject: Re: [CFRG] SRTP: Any work on more cryptoalgorithms?

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 02 Feb 2022 10:05:42 +1100

I am of the view that 16 bytes isn't that many and it's not really worth trying to shave things down that aggressively.  I understand that it is hard to tell that to someone who just spent an entire career saving bytes on the payload though.

I see that other commenters are talking about the shorter tag length recommendations in NIST publications.

There is also this: https://csrc.nist.gov/CSRC/media/Projects/Block-Cipher-Techniques/documents/BCM/Comments/CWC-GCM/Ferguson2.pdf and the response: https://csrc.nist.gov/csrc/media/projects/block-cipher-techniques/documents/bcm/comments/cwc-gcm/gcm-update.pdf

My understanding from that is that truncating the tag in GCM leads to more security loss than the saving in bytes might otherwise imply.  That might be a good trade for SRTP, but I'm not convinced.

I'm surprised that no mention has been made of OCB yet, for which I've read claims of good performance with truncated tags.

---

From: Mike Ounsworth <[email-masked]>
Date: Tue, 1 Feb 2022 23:38:48 +0000

> So the "We require that the AEAD authentication tag be 16 octets" of RFC 7144 can be ignored?
I wouldn’t use the word “ignored”, I would say instead “reduced as part of a security-bandwidth tradeoff”.

Summary: if you use a tag length less than 16, then it’s no longer AES_GCM_128, but some weaker version of it. That may be acceptable in some cases, but you need to know what you’re doing and be confident that your protocol contains other controls that compensate for partial loss of integrity protection in the encryption primitive. (or be confident that your protocol doesn’t care about integrity protection, but then why would you be using GCM mode in the first place?)

I think NIST SP 800-38D Appendix C (referenced by Mike below) is actually exactly what you’re looking for!

Appendix C: Requirements and Guidelines for Using Short Tags
For some voice or video applications, short authentication tags can be appropriate. The forgery
of some fraction of the individual authenticated “packets” may be tolerable, because each packet
of data in a large stream may carry very little of the overall meaning.
However, even for voice and video applications, short tags can be problematic for GCM, due to …
…
The following guidelines implicitly describe the special circumstances that may be appropriate
for short tags

---
Mike Ounsworth

From: CFRG <[email-masked]> On Behalf Of Michael StJohns
Sent: February 1, 2022 3:48 PM
To: Blumenthal, Uri - 0553 - MITLL <[email-masked]>; [email-masked]
Subject: [EXTERNAL] Re: [CFRG] SRTP: Any work on more cryptoalgorithms?

WARNING: This email originated outside of Entrust.
DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.
________________________________
On 2/1/2022 3:36 PM, Blumenthal, Uri - 0553 - MITLL wrote:
Authentication Tag can be truncated, for both -GCM and -SIV modes. We did some work studying the security impacts of that.

So the "We require that the AEAD authentication tag be 16 octets" of RFC 7144 can be ignored?

Mike

TNX
--
V/R,
Uri

From: CFRG <[email-masked]><mailto:[email-masked]> on behalf of Michael StJohns <[email-masked]><mailto:[email-masked]>
Date: Tuesday, February 1, 2022 at 15:24
To: CFRG <[email-masked]><mailto:[email-masked]>
Subject: Re: [CFRG] SRTP: Any work on more cryptoalgorithms?

RFC7144 has:

Later, Mike

Any email and files/attachments transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system.

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Wed, 2 Feb 2022 00:47:25 +0000

On 2/1/22, 18:07, "CFRG on behalf of Martin Thomson" <[email-masked] on behalf of [email-masked]> wrote:

> I am of the view that 16 bytes isn't that many and
> it's not really worth trying to shave things down
> that aggressively. 

It depends heavily on your medium. 

Over, e.g., "normal" Ethernet - sure. Over fiber channel - no sweat. Wireless, like 4-5G - easy.
Now please try to imagine (I know, it may be hard) a radio link - and not in multi-GHz range. You just might notice that bits start mattering, especially if your physical layer puts a (small!) hard cap on the packet size, and extra air time required for fragmentation handling can kill the link establishment. And then there is a whole class of issues, like transmitting power... In other words, "never ass-ume".

> I understand that it is hard to tell that to someone
> who just spent an entire career saving bytes on the
> payload though.

As I see, it's even harder to explain to somebody that his view of communications and use cases is rather limited.
They say: "never ass-ume".

> I see that other commenters are talking about the shorter
> tag length recommendations in NIST publications.

Yes.

It is called, as Mike pointed out, "security-bandwidth tradeoff". If your bandwidth is effectively unlimited - you don't need to trade anything. And, unfortunately, vs. versa.

> There is also this:
> https://csrc.nist.gov/CSRC/media/Projects/Block-Cipher-Techniques/documents/BCM/Comments/CWC-GCM/Ferguson2.pdf 
> and the response: https://csrc.nist.gov/csrc/media/projects/block-cipher-techniques/documents/bcm/comments/cwc-gcm/gcm-update.pdf

Old news, but thanks for bringing it up. 

"gcm-update.pdf" says:

  Certainly, in typical desktop environments, there is no clear
  motive for any sort of tag truncation. In the high-speed
  environments that drove the design of CWC and GCM,
  there is absolutely no need, due to the large available
  bandwidth and comparitively (sic) large message sizes.

By now you should've realized that my environment is not "typical desktop".

> My understanding from that is that truncating the tag in GCM leads
> to more security loss than the saving in bytes might otherwise 
> imply. 

With all due respect, your understanding is flawed.

It is a matter of careful calculations and analysis of the use case. Which, if done carelessly, can easily lead to loss of security - in some cases catastrophic.

But in some cases, it's not about "saving bytes" - it's about squeezing the message with its crypto into the available bits going over the air.

> That might be a good trade for SRTP, but I'm not convinced.

SRTP default auth tag is 80 bits, which does indicate the need or desire of a trade-off. Probably why SRTP sets the default at 80, but allows individual apps to pick a different value.
NIST defines the range between 32 and 128 bits. The less concerned you are about the bandwidth, the closer you should be to 128. And vs. versa - taking other considerations into account, like - how often you change the key, how much data is secured under one key, what kind of attacks your use case wants to defend against, etc. etc. etc.

> I'm surprised that no mention has been made of OCB yet,
> for which I've read claims of good performance with
> truncated tags.

OCB is great, and not as vulnerable as GCM. But, in general, it doesn't like truncated tags either. Picking AES-256-OCB with truncated auth tag, you still have to go through a careful analysis.

---

From: Taylor R Campbell <[email-masked]>
Date: Wed, 2 Feb 2022 00:48:43 +0000

> Date: Tue, 1 Feb 2022 20:36:25 +0000
> From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
> 

The impact of truncation is much worse on GCM than on SIV, by a factor
of the maximum message length in a protocol.  This applies essentially
anywhere you use a polynomial-evaluation MAC instead of a PRF for the
tag.

If the forger makes q attempts on a system with t-bit tags, n-bit
blocks, up to b blocks processed by the legitimate users, and a
maximum message length of L blocks, then:

- For GCM, the forgery advantage is bounded by q*L/2^t + O(b^2/2^n).
  [0, Theorem 2, p. 12]

- For SIV, the forgery advantage is bounded by q/2^t + O(b^2/2^n).
  [1, Theorem 2, p. 8]

So, for example, if in your protocol you allow messages of up to a
megabyte (2^30 bytes = 2^26 blocks), and you truncate tags to 32 bits,
then the forgery advantage with GCM is bounded only by q/2^6 when it
could be millions of times smaller with another system, q/2^32, at the
same tag size.

For 128-bit tags this isn't an issue in real protocols with plausible
maximum message lengths: the adversary will essentially never succeed
at forgery.  But if you play games with small tags and just hoping to
keep the number of forgeries small -- in an application which can
tolerate the occasional forgery -- it might make a real difference.

(Of course, saving those 8 or 12 bytes per message had better be worth
a lot to take on the burden of coping with occasional forgeries in the
application!  For many, or perhaps most, applications on the internet,
that's a terrible tradeoff.)

[0] Tetsu Iwata, Keisuke Ohashi, and Kazuhiko Minematsu, `Breaking and
    Repairing GCM Security Proofs', full version of paper in Reihaneh
    Safavi-Naini and Ran Canetti (eds.), CRYPTO 2012, Springer LNCS
    7417, pp. 39--49.  https://eprint.iacr.org/2012/438

    (Slightly better result can be had from the slightly better
    PRF/PRP switching lemma in Appendix C, Eq. (22), but only for the
    already irrelevant O(b^2/2^n); the same improvement applies to
    AES-SIV too.)

[1] Phillip Rogaway and Thomas Shrimpton, `A Provable-Security
    Treatment of the Key-Wrap Problem', full version of paper in Serge
    Vaudenay (ed.), EUROCRYPT 2006, Springer LNCS 4004, pp. 373--390.
    https://web.cs.ucdavis.edu/~rogaway/papers/keywrap.html

---

From: Michael StJohns <[email-masked]>
Date: Tue, 1 Feb 2022 19:55:34 -0500

TL;DR - Ferguson put it simpler:

> ann-bittagprovidesonlyn−kbitsofauthenticationsecuritywhen
> messagesare2kblockslong.

So in SRTP with a maximum message size of 2^16 you get a loss of 16 bits 
of authentication with maximum size messages.

Mike

On 2/1/2022 7:48 PM, Taylor R Campbell wrote:
>> From: "Blumenthal, Uri - 0553 - MITLL"<[email-masked]>
>>
>      7417, pp. 39--49.https://eprint.iacr.org/2012/438
>

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Wed, 2 Feb 2022 01:59:30 +0000

> an n-bit tag provides only n − k bits of authentication
> security when messages are 2k blocks long. 

True. But Taylor gave the actual bounds, considering not only message size, but the number of attempts and total number of blocks. 

> So, in SRTP with a maximum message size of 2^16 you get a loss
> of 16 bits of authentication with maximum size messages.  

Of course, we considered truncated tag for messages of size << 2^16 (or should I say, <<< 2^16?). __

> (Taylor:) For many, or perhaps most, applications
> on the internet, that's a terrible tradeoff.

No argument here. Except for two points: "most" is too strong a word here (how much do we know about *all* the apps on the internet?), and "on the internet" is probably thought with meaning that's too narrow. But for "normal" apps and "normal" comms - yes, sure.

On 2/1/2022 7:48 PM, Taylor R Campbell wrote:
Date: Tue, 1 Feb 2022 20:36:25 +0000
From: "Blumenthal, Uri - 0553 - MITLL" mailto:[email-masked]

---

From: Björn Haase <[email-masked]>
Date: Wed, 2 Feb 2022 07:38:52 +0000

Hello To all, 

I would like to establish the link with the recent IETF 112 contribution of Robert Moskowitz

https://datatracker.ietf.org/meeting/112/materials/slides-112-cfrg-short-hash-and-kmac-as-a-kdf-00

where he also raised the topic of the need for reducing the size of MAC fields for time-critical applications.

In my perception it would be worthwhile to prepare the guidance document Robert has been suggesting as I agree with him (in line with this discussion) that there *is* a use-case and need.

One thing also to consider is the performance aspect that you have when generating the MAC. In my perception it would be acceptable for many applications (where a forgery would have to be created by an attacker within some seconds or less) to use a light-weight MAC with a lower security target such as siphash-2-4. For universal hashing for short messages (e.g. say 8 bytes payload) you might need far more key bytes (generated by AES-CTR or the like) for the universal hashing algorithm than for encrypting the message itself.

BTW:

It is my current knowledge that any universal hashing such as poly1305 or GMAC comes with the requirement of having an unshortened full MAC-TAG. So far If I saw the need to shorten a MAC-TAG I always only considered HMAC or CBC-style MACs (in line e.g. with the paper for CHASKEY) where there is no structure that could be exposed as might occur for the universal hashing. 
@Uri could you give a pointer to your paper (and possibly other work) showing that shortened TAGs for GMAC and/or poly1305 are actually OK?

Yours,

Björn.

Mit freundlichen Grüßen I Best Regards 

Dr. Björn Haase 

Senior Expert Electronics | TGREH Electronics Hardware

Endress+Hauser Liquid Analysis

Endress+Hauser Conducta GmbH+Co.KG | Dieselstrasse 24 | 70839 Gerlingen | Germany
Phone: +49 7156 209 10377
[email-masked] |  www.ehla.endress.com 

Endress+Hauser Conducta GmbH+Co.KG
Amtsgericht Stuttgart HRA 201908
Sitz der Gesellschaft: Gerlingen
Persönlich haftende Gesellschafterin:
Endress+Hauser Conducta Verwaltungsgesellschaft mbH
Sitz der Gesellschaft: Gerlingen
Amtsgericht Stuttgart HRA 201929
Geschäftsführer: Dr. Manfred Jagiella

Gemäss Datenschutzgrundverordnung sind wir verpflichtet, Sie zu informieren, wenn wir personenbezogene Daten von Ihnen erheben.
Dieser Informationspflicht kommen wir mit folgendem Datenschutzhinweis (https://www.endress.com/de/cookies-endress+hauser-website) nach.

Disclaimer: 

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you receive this in error, please contact the sender and delete the material from any computer. This e-mail does not constitute a contract offer, a contract amendment, or an acceptance of a contract offer unless explicitly and conspicuously designated or stated as such.

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 2 Feb 2022 08:58:46 +0100

> I am of the view that 16 bytes isn't that many and it's not really worth trying to shave things down that aggressively.  I understand that it is hard to tell that to someone who just spent an entir…

My typical average audio packet (random sampled call) is around 100 
bytes; 6 bytes extra overhead is 6%.

We do have stats showing that increasing bandwidth used for audio 
decreases customer satisfaction; the effect varies by region - regions 
that still use 3G extensively are the most impacted.

In an environment where we use one-character MIDs to keep the size of 
the MID extension down, it's serious effort to argue for those 6 extra 
bytes when switching to the better crypto.

>> ann-bittagprovidesonlyn−kbitsofauthenticationsecuritywhen

If I understand this equation correctly, my messages are 2 blocks long, 
so an n-bit tag gives me n-1 bits of authentication security.

Terribly naive question: Is there a way of evaluating how much 
authentication security is effective against a given attacker?

---

From: John Mattsson <[email-masked]>
Date: Wed, 2 Feb 2022 10:15:27 +0000

Hi,

As I presented some years ago, ETSI SAGE has been working for many year on new encryption and integrity algorithms for later 5G releases and 6G.

https://datatracker.ietf.org/meeting/104/materials/slides-104-saag-snow-v-stream-cipher-00

The 3GPP requirements are that authenticated encryption running on commidity CPUs should achieve not only 20 Gbps but preferably also the peak data rates of future generations of mobile networks. The 3GPP requirements includes both 32 and 64 bit tags.

It is expected that ETSI SAGE publish specifications relatively soon. Seems clear that AES and SNOW 5G will be included. The new authenticated encryption modes publish by ETSI SAGE will likley be useful also for real-time communications.

Regarding truncating GCM. NIST heavily resticts the use of GCM with 32- and 64-bit tags based on Fergusson’s attack. As stated in [1], several of the statements in SP 800-38D Appendix C are not correct. SRTP does in general not meet the guidelines. The idea that an attacker does not get side-channel information about successful forgeries is almost always wrong and very dangerous.

[1] https://eprint.iacr.org/2015/477.pdf

Cheers,
John

---

From: Taylor R Campbell <[email-masked]>
Date: Wed, 2 Feb 2022 11:41:05 +0000

> Date: Wed, 2 Feb 2022 01:59:30 +0000
> Of course, we considered truncated tag for messages of size << 2^16
> (or should I say, <<< 2^16?).

Note: The forgery probability bound of q*L/2^t + ... for t-bit GCM
tags is in terms of the _maximum_ message length L (in blocks) that
the protocol allows, _not_ the actual message lengths used in practice
by legitimate users.

If you want to take advantage of a lower L, you have to ensure that
legitimate users _refuse to accept_ larger messages -- it's not enough
for the legitimate users to normally send smaller ones.

(In contrast, the b^2/2^n term or similar in the ellipsis is the
number b of n-bit (128-bit) blocks actually fed through AES by
legitimate users, both for sending legitimate packets and receiving
possibly-forged packets.)

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Wed, 2 Feb 2022 12:17:06 +0000

Yes.

>    for the legitimate users to normally send smaller ones.

No need to - physical layer puts hard limit on L. There's nothing a user can do to increase it.

>   possibly-forged packets.)

Yes, understood.

Thank you for a detailed and careful analysis!

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 03 Feb 2022 08:46:52 +1100

> authentication security is effective against a given attacker?

Not really.  We've a way of estimating the (upper bound on) the advantage an attacker gains in https://cfrg.github.io/draft-irtf-cfrg-aead-limits/draft-irtf-cfrg-aead-limits.html (revision coming real soon) but you have to decide how much advantage is tolerable in your circumstances.  Bounding the probability of success to 2^-32 was suggested as a reasonable target upthread, but TLS and QUIC chose ~2^-57 as its target.

--
If you have 100 byte messages, that's 7 blocks of 16 bytes or 3 bits.  Based on Taylor's advice, that means n - 3.5, which isn't appreciably worse as you suggest.  Given John's advice though, I might be more cautious.

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 3 Feb 2022 09:14:24 +0000

Blumenthal, Uri - 0553 - MITLL <[email-masked]> writes:

>there are some issues with GCM mode

The biggest of which is that people talk about it as if it was an ATM machine
or PIN number.

Peter.

---

From: Thomas Peyrin <[email-masked]>
Date: Thu, 3 Feb 2022 18:42:38 +0800

Hi all,

For information, we will very soon submit Deoxys AEAD modes (one of the
CAESAR competition winners) for consideration, with various
implementations. With Deoxys-I (one-pass, based on AES round function), you
can truncate the tag and retain 2^\tau security for authentication (in
addition, the proven security of Deoxys-I is beyond-birthday bound, so
actually better than AES-GCM from the start). Besides, performance
overhead is minimal with Deoxys (there is no precomputation and you start
handling message blocks directly), so it is quite efficient for small
inputs.

You can find the Journal of Cryptology paper here:
https://drive.google.com/file/d/1GDCl3KNKgrzTpEQtmbICEg9XX7G0p9lQ/view

Cheers,

Thomas.

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Thu, 3 Feb 2022 12:49:06 +0000

> For information, we will very soon submit Deoxys AEAD modes
> (one of the CAESAR competition winners) for consideration,
> with various implementations. With Deoxys-I (one-pass,
> based on AES round function), you can truncate the tag
> and retain 2^\tau security for authentication (in addition,
> the proven security of Deoxys-I is beyond-birthday bound,
> so actually better than AES-GCM from the start). 
> Besides, performance overhead is minimal with Deoxys (there is
> no precomputation and you start handling message blocks directly),
> so it is quite efficient for small inputs. 
>
> You can find the Journal of Cryptology paper 
> here: https://drive.google.com/file/d/1GDCl3KNKgrzTpEQtmbICEg9XX7G0p9lQ/view 

Yes, that would be an interesting and useful alternative to consider. Though I personally lean towards Deoxys-II because of its nonce re-use resistance.

Thanks for a pointer to detailed description.

Le mer. 2 févr. 2022 à 20:17, Blumenthal, Uri - 0553 - MITLL <mailto:[email-masked]> a écrit :
>    > Of course, we considered truncated tag for messages of size << 2^16
>    > (or should I say, <<< 2^16?).
>

Yes.

Yes, understood.

mailto:[email-masked]