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

[Milan Broz <gmazyland@gmail.com>]

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