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
