Re: How to salvage a degraded mdadm RAID1 with as little data loss as possible?

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

-----BEGIN PGP SIGNATURE-----

iF0EABECAB0WIQRp53liolZD6iXhAoIFyCz1etHaRgUCajttqAAKCRAFyCz1etHa
RsNuAJ9TyyYjZf1mtwXpKpO6iB+Tp45ZJACfVFmj4uIThTqqTXU/Yds8ojSDSGU=
=TJTy
-----END PGP SIGNATURE-----