On Tue, Jun 23, 2026 at 03:04:38PM -0700, David Christensen wrote: > On 6/23/26 11:10, [email protected] wrote: > > On Tue, Jun 23, 2026 at 10:33:01AM -0700, David Christensen wrote: > > > > [...] > > > > > Both configurations work, but have different performance and security > > > considerations: > > > > > > * partitions > RAID > encryption > filesystem > > > > > > Will encrypt the RAID virtual block device, saving CPU cycles and > > > requiring one passphrase and/or key. > > > > > > * partitions > encryption > RAID > filesystem > > > > > > Will encrypt each partition, arguably improving security but > > > requiring > > > more CPU cycles and passphrases/ keys. > > > > Actually it would reduce security, IMO, because the opponent would have > > to find just one of both keys (the content is mirrored), thus potentially > > reducing the key strength by one bit. Not a big deal, granted :) > > > > Cheers > > > I agree that successfully cracking two or more disks from an encrypted RAID > will give an attacker greater confidence in the resulting data and metadata.
No, no: I meant the attacker has to crack *just one of two*, thus potentially halving the search time (assuming enough parallelism, which seems a semsible to assume in these crazy days we live in). > But I would expect a cracking algorithm for an encryption layer with on-disk > cryptographic details (e.g. LUKS header) would primarily attack those > on-disk cryptographic details: > > * Assuming a brute-force cracking algorithm, each crack attempt (e.g. > passphrase and/or key generated by an iterator) is an independent trial and > the work is readily partitioned across multiple computers working in > parallel. So, cracking 1 LUKS header with N computers will take the same > average time as cracking any one of 2 to N different LUKS headers with N > computers. Now that makes sense to me: space × time is constant, you double the one and halve the other. You're right. > * What an attacker wants is a cracking algorithm where each new cracking > attempt leverages the results from previous failed attempts. AIUI LUKS, > dm-crypt, and other professional cryptographic systems are specifically > designed to thwart such. But if you design such an algorithm, you could > become famous, make money, become an enemy of the state, go to prison, flee > into exile, etc.. I'd expect that, yes. Current attacks seem to concentrate on the PBKDF, that's why argon2, specifically argon2id [1] [2] is currently recommended (it makes highly parallel attacks by SIMD GPUs difficult) > I was thinking of what happens if a disk fails, the sysadmin disposes of the > disk, an attacker obtains the disk, and the attacker successfully cracks the > encryption. The attacker now has all or part of the plaintext data, the > plaintext metadata, and the plaintext cryptographic details at the time the > disk failed: Never do that. If the electronics still work to dd to the first sectors of the disk, by all means, do. > * If encryption was applied on top of RAID and the attacker obtains a second > encrypted disk, the attacker can use the plaintext cryptographic details > from the first disk to crack the second disk. This could be as simple as > entering the passphrase and/or key from the first disk. > > * If encryption was applied under RAID and the sysadmin used different > strong passphrases and/or keys on every disk, the plaintext cryptographic > details from any one cracked disk will not help to crack additional > encrypted disks. Which you don't need to, since we are talking RAID1, and they should have (roughly ;) equal content. Other RAID schemata are different, granted. Cheers -- t
signature.asc
Description: PGP signature
