[RFC] `aes-gcm-random`: per-key invocation limit

[RFC] `aes-gcm-random`: per-key invocation limit

[Shukai Ni]

Dear device-mapper maintainers,

Thank you for maintaining `dm-crypt` and `dm-integrity`. As part of a
broader analysis of full-disk encryption in Linux, we identified a
low-severity, defense-in-depth concern involving `aes-gcm-random` that
we would like to understand better.

The `aes-gcm-random` implementation generates a random 96-bit IV for
each sector encryption, but the device-mapper path does not count
invocations or rekey automatically. The original paper [2] recommends
IVs longer than 128 bits for this construction. Was 96 bits chosen for
a particular compatibility, performance, or implementation reason?

Section 8.3 of NIST SP 800-38D limits the RBG-based IV construction to
2^32 invocations across all instances using a given key. This bound is
conservative: as shown below, the expected first collision for uniformly
random 96-bit IVs occurs after approximately 2^48.3 invocations.
Nevertheless, IV reuse violates GCM's security assumptions and can
enable tag forgery, undermining both its confidentiality and integrity
guarantees.

In our 16-core test environment, we measured the rate of pure IV
generation and projected an expected first collision after approximately
30 days. We would be happy to share further details about our setup and
methodology. We also recognize that this is an idealized projection and
assumes a strong attacker who can continuously monitor the disk, as may
be possible in a CVM deployment. Nevertheless, this is one of the
deployment scenarios in which `dm-crypt` is used.

Ideally, the random IV would be made longer, following the recommendation
in [2]. If that is not feasible, could the `dm-crypt` documentation state
the 2^32 per-key limit and require userspace to rekey before reaching it?
The kernel could also warn or refuse further writes when an in-memory
per-mapping counter reaches the limit, while userspace remains responsible
for accounting for key reuse across mapping reloads.

Kind regards,
Shukai Ni and Jo Van Bulck
DistriNet, KU Leuven

## Collision estimate

For independent uniform `b`-bit IVs, the expected number of invocations
before the first collision is approximately:

```text
E[N] ≈ sqrt(pi / 2) * 2^(b / 2)
```

For `b = 96`, this is approximately `2^48.326`, or `3.53 × 10^14`
invocations.

## References

1. NIST, *Recommendation for Block Cipher Modes of Operation:
   Galois/Counter Mode (GCM) and GMAC*, SP 800-38D,
   https://doi.org/10.6028/NIST.SP.800-38D
2. Milan Brož, Mikuláš Patočka, and Vashek Matyáš, *Practical
   Cryptographic Data Integrity Protection with Full Disk Encryption*,
   IFIP SEC 2018,
   https://doi.org/10.1007/978-3-319-99828-2_6

Re: [RFC] `aes-gcm-random`: per-key invocation limit

[Milan Broz]

On 8/27/26 9:18 PM, Shukai Ni wrote:
> Dear device-mapper maintainers,
> 
> Thank you for maintaining `dm-crypt` and `dm-integrity`. As part of a
> broader analysis of full-disk encryption in Linux, we identified a
> low-severity, defense-in-depth concern involving `aes-gcm-random` that
> we would like to understand better.
> 
> The `aes-gcm-random` implementation generates a random 96-bit IV for
> each sector encryption, but the device-mapper path does not count
> invocations or rekey automatically. The original paper [2] recommends
> IVs longer than 128 bits for this construction. Was 96 bits chosen for
> a particular compatibility, performance, or implementation reason?

IIRC due to the limitation of kernel GCM implementation.
Using 96-bit nonces is a known weak property of GCM mode for years.
  
> Section 8.3 of NIST SP 800-38D limits the RBG-based IV construction to
> 2^32 invocations across all instances using a given key. This bound is
> conservative: as shown below, the expected first collision for uniformly
> random 96-bit IVs occurs after approximately 2^48.3 invocations.
> Nevertheless, IV reuse violates GCM's security assumptions and can
> enable tag forgery, undermining both its confidentiality and integrity
> guarantees.
> 
> In our 16-core test environment, we measured the rate of pure IV
> generation and projected an expected first collision after approximately
> 30 days. We would be happy to share further details about our setup and
> methodology. We also recognize that this is an idealized projection and
> assumes a strong attacker who can continuously monitor the disk, as may
> be possible in a CVM deployment. Nevertheless, this is one of the
> deployment scenarios in which `dm-crypt` is used.

If anyone using it in this scenario, then it is insecure anyway.

An attacker model that can record all writes can easily replays individual sectors,
including auth tags. It is just not secure in this scenario.

And it is intentionally designed this way to avoid complexity.

> Ideally, the random IV would be made longer, following the recommendation
> in [2]. If that is not feasible, could the `dm-crypt` documentation state
> the 2^32 per-key limit and require userspace to rekey before reaching it?
> The kernel could also warn or refuse further writes when an in-memory
> per-mapping counter reaches the limit, while userspace remains responsible
> for accounting for key reuse across mapping reloads.

Please no.

If you want to help, then please focus on promoting better AEAD modes
(we have AEGIS in kernel, for example).

Using AEAD in dm-crypt was meant mainly to show that AEAD can be used in this
context and increase security, despite it is not ideal and cannot achieve
ideal conditions here. The whole FDE concept is designed to protect offline devices.

It can be probably used in different scenarios, but you just have to
understand its limits.

When writing [2] I expected we will have better encrypted filesystems with
properly used authenticated encryption these days....

Milan

> Kind regards,
> Shukai Ni and Jo Van Bulck
> DistriNet, KU Leuven
> 
> ## Collision estimate
> 
> For independent uniform `b`-bit IVs, the expected number of invocations
> before the first collision is approximately:
> 
> ```text
> E[N] ≈ sqrt(pi / 2) * 2^(b / 2)
> ```
> 
> For `b = 96`, this is approximately `2^48.326`, or `3.53 × 10^14`
> invocations.
> 
> ## References
> 
> 1. NIST, *Recommendation for Block Cipher Modes of Operation:
>     Galois/Counter Mode (GCM) and GMAC*, SP 800-38D,
>     https://doi.org/10.6028/NIST.SP.800-38D
> 2. Milan Brož, Mikuláš Patočka, and Vashek Matyáš, *Practical
>     Cryptographic Data Integrity Protection with Full Disk Encryption*,
>     IFIP SEC 2018,
>     https://doi.org/10.1007/978-3-319-99828-2_6

Re: [RFC] `aes-gcm-random`: per-key invocation limit

[Shukai Ni]

Hi Milan,

Thank you for taking the time to provide these detailed clarifications.

> An attacker model that can record all writes can easily replays individual sectors,
> including auth tags. It is just not secure in this scenario.

Understood. Our review also found that the current setup does not provide
sufficient protection against an attacker under this threat model.

> If you want to help, then please focus on promoting better AEAD modes
> (we have AEGIS in kernel, for example).

That is a fair point. We appreciate the suggestion and will look more
closely at AEGIS and its existing kernel support.

Thank you again for your feedback and guidance.

Kind regards,
Shukai Ni and Jo Van Bulck
DistriNet, KU Leuven