15 ms·

It's worth mentioning AES-GCM-SIV[1], which is the fix for this issue. [1] https://www.rfc-editor.org/rfc/rfc8452.html https://www.rfc-editor.org/rfc/rfc8452.h

by e____g 2y ago

It's worth mentioning AES-GCM-SIV[1], which is the fix for this issue. [1] https://www.rfc-editor.org/rfc/rfc8452.html https://www.rfc-editor.org/rfc/rfc8452.html

tptacek 2y ago
The alternative, which I prefer, is an XGCM-like construction that just gives you a large enough nonce to comfortably use random nonces.
- dontdoxxme 2y ago
  +1, soatok has a write-up of how that works: https://soatok.blog/2022/12/21/extending-the-aes-gcm-nonce-without-nightmare-fuel/ https://soatok.blog/2022/12/21/extending-the-aes-gcm-nonce-w... ...a variant on that is DNDK-GCM in draft at https://datatracker.ietf.org/doc/draft-gueron-cfrg-dndkgcm/ https://datatracker.ietf.org/doc/draft-gueron-cfrg-dndkgcm/ and a recent presentation: https://youtu.be/GsFO4ZQlYS8 https://youtu.be/GsFO4ZQlYS8 (this is Shay Gueron who worked on AES-GCM-SIV too).
- bjoli 2y ago
  Could this be extended to give us XOCB? I am not sure it would make much sense with the OCB size recommendations.
- vlovich123 2y ago
  AES-GCM has a 12 byte nonce if I recall correctly. Is 96 bits of entropy insufficient to guarantee uniqueness every time it’s generated?
  - tptacek 2y ago
    No. Extended-nonce constructions solve that problem by using the "large" nonce along with the original key to derive a new key. You then have the "small" nonce space plus the key space worth of random bits.
  - aidenn0 2y ago
    Only if you're not encrypting many billions of small messages with the same key, which is a possibility. It's just barely large enough for many uses, and "just barely" makes cryptographers nervous.
notfed 2y ago
The "fix" is to use a nonce misuse resistant cipher, of which AES-GCM-SIV is one. But, AES-GCM-SIV requires two passes over the data, which isn't always ideal. The goal of the CAESAR competition [1] was essentially to find alternatives. Whether that goal has been met is a bit unclear at the moment. [1] https://competitions.cr.yp.to/caesar-submissions.html https://competitions.cr.yp.to/caesar-submissions.html
- throw0101d 2y ago
  > The goal of the CAESAR competition [1] https://en.wikipedia.org/wiki/CAESAR_Competition https://en.wikipedia.org/wiki/CAESAR_Competition
throw0101d 2y ago
At this point OCB has an expired patent, and only needs one pass over the data: * https://en.wikipedia.org/wiki/OCB_mode https://en.wikipedia.org/wiki/OCB_mode
- upofadown 2y ago
  From the OCB FAQ[1]: >What happens if you repeat the nonce? You’re going to mess up authenticity for all future messages, and you’re going to mess up privacy for the messages that use the repeated nonce. The loss of privacy on OCB nonce reuse is not as severe. It would be more or less the same as with ECB mode. [1] https://www.cs.ucdavis.edu/~rogaway/ocb/ocb-faq.htm https://www.cs.ucdavis.edu/~rogaway/ocb/ocb-faq.htm
  - throw0101d 2y ago
    The next few lines are: > It is the user’s obligation to ensure that nonces don’t repeat within a session. In settings where this is infeasible, OCB should not be used. But earlier in that section we have: > […] The nonce doesn’t have to be random or secret or unpredictable. It does have to be something new with each message you encrypt. A counter value will work for a nonce, and that is what is recommended. […] * https://www.cs.ucdavis.edu/~rogaway/ocb/ocb-faq.htm#nonce https://www.cs.ucdavis.edu/~rogaway/ocb/ocb-faq.htm#nonce So given that GCM uses a counter ("C"), and a counter is recommended for OCB, wouldn't it be simple enough to get the equivalent (?) security more efficiently?
    - tptacek 2y ago
      The notion of a nonce here is the same as that in GCM. GCM nonces aren't secret and don't need to be unpredictable; in fact, because the nonce space is so small, a common engineering recommendation is to use a durable counter.
      - throw0101d 2y ago
        Given that OCB (appears to be?) is more computationally efficient than GCM, is there any reason why OCB shouldn't be favoured nowadays given there are no IP issues?

by e____g 2y ago

It's worth mentioning AES-GCM-SIV[1], which is the fix for this issue. [1] https://www.rfc-editor.org/rfc/rfc8452.html https://www.rfc-editor.org/rfc/rfc8452.html

tptacek 2y ago

The alternative, which I prefer, is an XGCM-like construction that just gives you a large enough nonce to comfortably use random nonces.

dontdoxxme 2y ago
+1, soatok has a write-up of how that works: https://soatok.blog/2022/12/21/extending-the-aes-gcm-nonce-without-nightmare-fuel/ https://soatok.blog/2022/12/21/extending-the-aes-gcm-nonce-w... ...a variant on that is DNDK-GCM in draft at https://datatracker.ietf.org/doc/draft-gueron-cfrg-dndkgcm/ https://datatracker.ietf.org/doc/draft-gueron-cfrg-dndkgcm/ and a recent presentation: https://youtu.be/GsFO4ZQlYS8 https://youtu.be/GsFO4ZQlYS8 (this is Shay Gueron who worked on AES-GCM-SIV too).
bjoli 2y ago
Could this be extended to give us XOCB? I am not sure it would make much sense with the OCB size recommendations.
vlovich123 2y ago
AES-GCM has a 12 byte nonce if I recall correctly. Is 96 bits of entropy insufficient to guarantee uniqueness every time it’s generated?
- tptacek 2y ago
  No. Extended-nonce constructions solve that problem by using the "large" nonce along with the original key to derive a new key. You then have the "small" nonce space plus the key space worth of random bits.
- aidenn0 2y ago
  Only if you're not encrypting many billions of small messages with the same key, which is a possibility. It's just barely large enough for many uses, and "just barely" makes cryptographers nervous.

notfed 2y ago

The "fix" is to use a nonce misuse resistant cipher, of which AES-GCM-SIV is one. But, AES-GCM-SIV requires two passes over the data, which isn't always ideal. The goal of the CAESAR competition [1] was essentially to find alternatives. Whether that goal has been met is a bit unclear at the moment. [1] https://competitions.cr.yp.to/caesar-submissions.html https://competitions.cr.yp.to/caesar-submissions.html

throw0101d 2y ago
> The goal of the CAESAR competition [1] https://en.wikipedia.org/wiki/CAESAR_Competition https://en.wikipedia.org/wiki/CAESAR_Competition

throw0101d 2y ago

At this point OCB has an expired patent, and only needs one pass over the data: * https://en.wikipedia.org/wiki/OCB_mode https://en.wikipedia.org/wiki/OCB_mode

upofadown 2y ago
From the OCB FAQ[1]: >What happens if you repeat the nonce? You’re going to mess up authenticity for all future messages, and you’re going to mess up privacy for the messages that use the repeated nonce. The loss of privacy on OCB nonce reuse is not as severe. It would be more or less the same as with ECB mode. [1] https://www.cs.ucdavis.edu/~rogaway/ocb/ocb-faq.htm https://www.cs.ucdavis.edu/~rogaway/ocb/ocb-faq.htm
- throw0101d 2y ago
  The next few lines are: > It is the user’s obligation to ensure that nonces don’t repeat within a session. In settings where this is infeasible, OCB should not be used. But earlier in that section we have: > […] The nonce doesn’t have to be random or secret or unpredictable. It does have to be something new with each message you encrypt. A counter value will work for a nonce, and that is what is recommended. […] * https://www.cs.ucdavis.edu/~rogaway/ocb/ocb-faq.htm#nonce https://www.cs.ucdavis.edu/~rogaway/ocb/ocb-faq.htm#nonce So given that GCM uses a counter ("C"), and a counter is recommended for OCB, wouldn't it be simple enough to get the equivalent (?) security more efficiently?
  - tptacek 2y ago
    The notion of a nonce here is the same as that in GCM. GCM nonces aren't secret and don't need to be unpredictable; in fact, because the nonce space is so small, a common engineering recommendation is to use a durable counter.
    - throw0101d 2y ago
      Given that OCB (appears to be?) is more computationally efficient than GCM, is there any reason why OCB shouldn't be favoured nowadays given there are no IP issues?