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
