Talk about AES-GCM documented and largely unknown limitations. We won’t get into the cryptographic details of the algorithm, so no need to worry about that. I’ll propose some workarounds to the limitations too. There is some basic math involved :)

1. AES-GCM common pitfalls
and how to work around them
Santiago Kantorowicz - 2022
medium.com/@skantos

2. Who am I
● Working in CyberSecurity since 2008
● Working at Twilio since 2015
○ 6 years as Authy / Account Security Security Officer
○ Now Staff Product Security Engineer
● Not a cryptographer, an enthusiast!

3. Why this talk?
● Organizations need to implement encryption.
● “someone” creates a library for specific use* when needed and
many years later everyone still uses the same.
● * usually when the use case is very simple and undemanding.
● Most companies can’t afford cryptography experts.
● Security professionals are not always into cryptography either.
● So many/most small to large companies wing it.

4. ● You need to store some sensitive data in a database.
○ API Keys, PII, Credit card, etc.
● Someone says: let’s encrypt!
● AES-GCM is mentioned a lot on google searches!
● stackoverflow.com → copy/paste
Introduction

6. Key Management

7. With great power
comes great responsibility

8. With great power
comes great responsibility
managing keys

9. Key management: Key Life
Key Rotation
● Why?
○ Key compromised
○ Standards
○ Compliance (PCI)
● When?
○ Based on time
○ Amount of encryption
○ Total number of Bytes encrypted

10. CryptoPeriod

11. CryptoPeriod
“NIST Special Publication 800-57 Part 1 - Revision 5”, named: “Recommendation
for Key Management: Part 1 – General”
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf
“The time span during which a specific key is
authorized for use or in which the keys for a given
system or application may remain in effect.”

12. CryptoPeriod
“NIST Special Publication 800-57 Part 1 - Revision 5”, named: “Recommendation
for Key Management: Part 1 – General”
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf

13. Extending Key Life
● We will focus on extending Key life!
○ “7. Limitations for algorithm usage (e.g.,
the maximum number of invocations to
avoid nonce reuse)”
● Extending key life may or may not affect the
cryptoperiod.

14. CryptoPeriod vs Key life
● Cryptoperiod != maximum amount of encryptions you can perform
with one the key.
● Cryptoperiod: suggested/enforced through standards like NIST and
regulations like PCI.

15. IV / nonce
(Initialization Vector)

16. ● Used interchangeable
● IV = initialization vector
● nonce = number used once
● 1 plain-texts → encrypted twice → 2 different ciphertexts
IV / Nonce

17. AES-GCM Wins popularity contest
● AES-GCM is recommended by many experts.
● It’s AEAD (authenticated + integrity built-in)
● Efficient and Performant
● Specially compared to CBC the mode it
replaced as most popular

18. AES-GCM: what’s wrong with it?

19. AES-GCM: what’s wrong with it?
GCM is CTR with GMAC for integrity/authentication
https://datatracker.ietf.org/doc/html/rfc3686

20. AES-GCM: what’s wrong with it?
https://datatracker.ietf.org/doc/html/rfc3686

21. AES-GCM: what’s wrong with it?
Encrypt
Nonce
1
E(N1) ⊕ PlainA = CipherA
Encrypt
Nonce
1
E(N1) ⊕ PlainB = CipherB
E(N1) ⊕ PlainA ⊕ E(N1) ⊕ PlainB
(PlainA ⊕ PlainB) ⊕ PlainA
● PlainA is known
● PlainB is unknown, CipherB is known.
⊕

22. AES-GCM: what’s wrong with it?
Encrypt
Nonce
1
E(N1) ⊕ PlainA = CipherA
Encrypt
Nonce
1
E(N1) ⊕ PlainB = CipherB
E(N1) ⊕ PlainA ⊕ E(N1) ⊕ PlainB
(PlainA ⊕ PlainB) ⊕ PlainA
● PlainA is known
● PlainB is unknown, CipherB is known.
⊕

23. AES-GCM: what’s wrong with it?
● It doesn’t end here!
● Different cipher texts, same nonce and key → auth key is
leaked
● Forge and tamper ciphertexts

24. AES-GCM: what’s wrong with it?
“Nonce-Disrespecting Adversaries: Practical Forgery Attacks on GCM in TLS”
https://eprint.iacr.org/2016/475.pdf
“…This results in catastrophic failure of authenticity, even if a nonce is only re-used a
single time and enables us to carry out a practical forgery attack against HTTPS…”
… A single repeated nonce is usually enough to fully recover the connection’s
authentication key…”
https://csrc.nist.gov/csrc/media/projects/block-cipher-
techniques/documents/bcm/comments/800-38-series-drafts/gcm/joux_comments.pdf
…an adversary can recover the secret key of the keyed hash function underlying the
authentication, using a chosen IV attack. Once this secret key is known, the encryption
mode is no longer authenticated. As a consequence, all chosen ciphertext attacks
against the confidentiality become feasible. Moreover, since the encryption mode is a
counter mode, i.e. a stream cipher, the XOR malleability of the encrypted plaintext
becomes a major security issue.

25. GCM nonces
● OK, so I just won’t repeat nonces and I’m done.
Right?
● Distributed infrastructure makes counters almost
impossible.
● Random nonces
● GCM nonces are standardized to 96 bit long.

26. GCM nonces
● NIST SP 800-38D (Recommendation for Block Cipher Modes of
Operation: Galois/Counter Mode (GCM) and GMAC) specifies:
“...The IVs in GCM must fulfill the following “uniqueness” requirement:
The probability that the authenticated encryption function ever will be
invoked with the same IV and the same key on two (or more) distinct sets
of input data shall be no greater than 2-32...”
“...The total number of invocations of the authenticated encryption function
shall not exceed 232, including all IV lengths and all instances of the
authenticated encryption function with the given key...”

27. GCM nonces
● P(collision) = 2-32 ≃ 10-10
● We can’t encrypt more than 232 times (with same key)
● Risk of random nonce repetition.
If you encrypt 500 records/second you will hit 232 after 100 days!
Days! Not years!

28. ● Why 96 bits? Why not 256 bits?
https://csrc.nist.rip/groups/ST/toolkit/BCM/documents/proposedmodes/
gcm/gcm-spec.pdf
“96-bit IV values can be processed more efficiently, so that length is
recommended for situations in which efficiency is critical.”
● Could be longer! but it’s not standardized.
GCM nonce length

29. ● Libraries expects the implementer to keep the number of encryptions
under 232.
● I checked LibSodium and Google Tink.
● Golang std library: “Never use more than 232 random nonces with a
given key because of the risk of a repeat.”
Cryptographic libraries solve this, right?

30. Why random numbers repeat?

31. Birthday Paradox

32. Why random numbers repeat?
● Birthday paradox!
● In cryptographic layman terms
○ If you don’t want any 2 random numbers to repeat, you must limit the amount
of random numbers you generate.
● If your numbers go from 1 to 10, it’s extremely likely that if you
generate 5 random numbers, 2 will repeat (~70%).

33. Birthday paradox

34. Birthday paradox
NIST GCM recommended max encryptions: 232 ~ 109
https://en.wikipedia.org/wiki/Birthday_problem#Probability_table

35. GCM nonce collision acceptance
● NIST: Acceptable probability of collision of around 2-32 ~ 10-10
● We will use the table from now on
○ So safe is <= 10-12

36. Workarounds

37. ● Use AES-GCM, with NO changes
● Keep it NIST compliance → FIPS 140-2* / FedRAMP
● Probability of collision <= 10-10
● At least 264 encryptions.
● No requirements for performance.
● No requirements for efficiency
Workaround requirements
* or FIPS 140-3

38. Workaround: Random Salt

39. Workaround: Random Salt
● Derive Keys from a Master Key
○ “Synthetically emulate larger nonces”
● NO changes to how nonces are created
● NIST/FIPS 140-2 compliant
○ NOT changing the algorithm at all
● If a nonce were to repeat, it should happen with a different Key.

40. Workaround: Random Salt
● For AES with 256 bit keys:
○ Derived Key = HMAC-SHA256(Master Key, Salt)
● Salts are random → Figure out the required size.
● Master Key is never used to encrypt.

41. Workaround: Random Salt
● Let’s calculate Salt size!
● Salts are random too → Birthday paradox is applicable!

42. Workaround: Random Salt
● 264 is ~1019

43. Workaround: Random Salt
● 264 is ~1019 (< 1.1 x 1023). We are actually getting better than P=10-18

44. Workaround: Random Salt
● We need 192 bits random in TOTAL.
● We have 96 bits already from nonce
● So Salt → 96 bits (12 bytes)

45. Workaround: Random Salt
● Use SecureRandom
● Seeding should use fresh entropy when having many instances, to
avoid different instances having the same seed.

46. Workaround: Random Salt
Extra cost compared to plain AES-GCM:
● 96 bits SecureRandom
● 1 HMAC
● 12 extra bytes
It’s not that bad :)
● You can adapt salt size based on need.
https://github.com/kantos/go_encryption_library

47. Workaround: Time-based salts

48. Workaround: Time-based salts
● Derived Key = HMAC-SHA256(Master Key, Salt)
● Counters are good nonces!
● Hard to sync among instances.
● Let’s uses salts based on time!
● Time doesn’t repeat itself
○ It does repeat among different instances though.
○ Or on local time adjustments

49. Workaround: Time-based salts
● 32-bit Unix time → 4 bytes
● Birthday paradox doesn’t apply → 232 by 232 = 264 encryptions.
● As long as you don’t perform more than 232 encryptions in 1
second, you should be fine.

50. Workaround: Time-based salts
● No need to worry about time shifts between instances, they end
up cancelling each other.
● If clocks are not working at all, i.e. stuck, then you have to
worry.

51. Workaround: Time-based salts
Side effects:
● You are storing the time of
record encryption.
○ If you are for example encrypting
Bank account creation date, then
“salt” = “account creation date”
○ Useful for scheduling re-
encryptions (for key rotations)

52. Workaround: Time-based salts
Side effects:
● Unix 32 bits timestamps are “signed int”. Overflows in the year 2038.
○ Overflow won’t break the scheme → Useful until year 2106.
○ Prepare your Operating System for overflows.
○ You could end up finding every record to be old, even immediately after
encrypting.

53. AES-GCM-SIV

54. AES-GCM-SIV
● SIV = Synthetic Initialization Vector
● “Nonce Misuse-Resistant Authenticated Encryption”
● 2017: Shay Gueron, Adam Langley, Yehuda Lindell.
https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-gcmsiv-05
https://eprint.iacr.org/2017/168.pdf

55. AES-GCM-SIV
Pros
● Resistant to nonce repetition
● Less performant than plain AES-GCM, but still pretty good.
● Available in multiple programming languages.
● Encrypt 264 messages of length 4KiB

56. AES-GCM-SIV
Cons
● Still not available in every programming language [1]
● Support is up to individual projects
● Not FIPS 140-2 (nor NIST approved. Submitted in 2019 [2])
[1] It’s getting better every year though.
[2] https://csrc.nist.gov/projects/block-cipher-techniques/bcm/modes-development

57. AES-GCM-SIV
● Repeating nonces still leaks that the plain text is the same.
● You can mix AES-GCM-SIV with the proposed solutions.
● AES-GCM-SIV is likely secure, but it’s too new.

58. Should we really worry about AES-GCM collisions?

59. Should we really worry about AES-GCM collisions?
● 248 encryptions → chance of a nonce collision is around 50%.
● An attacker needs to capture/retrieve and store, 15 petabytes* of
records to have 50% chance of success of collision.
○ If your plain-text records are 32 bytes, when encrypted (with tag and
nonce) they are 60 bytes long.
● This will only allow decrypting 1 record.
● And forging any new record.
* in average, you never know when a repetition will happen.

60. Should we really worry about this?
● You decide!
● Implementing these solutions it’s pretty easy, so why not do them.
● You never know how your system will be abused.
● You never know how your encryption library will be used by
engineers.
● Encryption libraries live for a long time in organizations.

61. Why use AES-GCM then?
● AES-GCM is FIPS 140-2* compliant
● Less error prone to AES-CBC
● FedRAMP requires FIPS 140-2*
● If you don’t need any of those (beware your org may change
their mind)
a. NaCl/libsodium
b. XChaCha20-Poly1305-IETF
c. AES-GCM-SIV
* / FIPS 140-3

62. Thank you
https://xkcd.com/538/
medium.com/@skantos