Re: bin/58212: cgdconfig(8): Add zfs verification method

[Taylor R Campbell <riastradh%NetBSD.org@localhost>]

The following reply was made to PR bin/58212; it has been noted by GNATS.

From: Taylor R Campbell <riastradh%NetBSD.org@localhost>
To: Robert Elz <kre%munnari.OZ.AU@localhost>
Cc: Malte Dehling <mdehling%gmail.com@localhost>, gnats-bugs%NetBSD.org@localhost, netbsd-bugs%NetBSD.org@localhost
Subject: Re: bin/58212: cgdconfig(8): Add zfs verification method
Date: Mon, 29 Apr 2024 01:54:21 +0000

 > Date: Mon, 29 Apr 2024 05:19:05 +0700
 > From: Robert Elz <kre%munnari.OZ.AU@localhost>
 >=20
 >   | Would also be nice if we could quantify the false acceptance probabil=
 ity
 >=20
 > It doesn't really matter, this has nothing whatever to do with the
 > security of the cgd, these validity checks are used merely to allow
 > detection of incorrect passwords (etc) - they (even when they appear
 > to be validating some data struct) have nothing whatever to do with
 > use of any of the data.
 
 You're right that it's not relevant to the security of cgd's
 confidentiality against an adversary, but it does matter to users.
 
 Seeing `verification failed, please reenter passphrase' is unalarming.
 
 Seeing a host of fsck failures at boot time because the block device
 is garbage when decrypted with the wrong key is extremely alarming,
 and suggests you have faulty hardware and may have lost data.
 
 And if you do anything to write data back to the block device -- e.g.,
 you decide to give up on data recovery and newfs it -- you'll probably
 never get your _new_ data back because you have to make the same typo
 when you next boot.
 
 > The 1/2^16 probability that the MBR gives (assuming you're correct
 > about that, which I don't doubt)
 
 For those curious, this came by modelling the plaintext under the
 wrong key as independent uniform random bits, under which the
 verify_mbr criterion of checking for a single 16-bit magic number has
 probability 1/2^16 of passing:
 
 https://nxr.netbsd.org/xref/src/sbin/cgdconfig/cgdconfig.c?r=3D1.62#1058
 
    1070 	ret =3D prog_pread(fd, buf, SCANSIZE, 0);
    1071 	if (ret < 0) {
    1072 		warn("can't read mbr area");
    1073 		return -1;
    1074 	}
    1075=20
    1076 	memcpy(&mbr, buf, sizeof(mbr));
    1077 	if (le16toh(mbr.mbr_magic) !=3D MBR_MAGIC)
    1078 		return 1;
    1079=20
    1080 	return 0;
 
 The verify_ffs criterion is a little more involved, and since I wrote
 the previous message (a couple years ago) it has grown a higher false
 acceptance probability now that it allows FS_UFS2EA_MAGIC or
 FS_UFS2EA_MAGIC_SWAPPED too, so it's 1 - (1 - 6/2^32)^4 or a little
 under one in 178 * 10^6.  This arises from allowing any of six
 different 32-bit magic numbers in any of four different superblock
 locations.
 
 https://nxr.netbsd.org/xref/src/sbin/cgdconfig/cgdconfig.c?r=3D1.62#1185
 https://nxr.netbsd.org/xref/src/sys/ufs/ffs/fs.h?r=3D1.71#103
 
 >                                  is really good enough - the much
 > higher probabilities against false positivies of the other methods
 > are nice, I guess, but aren't there because of cgd, they're what
 > happened to exist anyway.
 
 The independent uniform random bits model is substantively different
 from usual hardware errors, where typically we model each bit as
 having an independent small (not fair coin toss) probability of error,
 or a burst of errors in a nearby region.  And human-designed data
 formats tend not to be totally randomized.  So this really is related
 to cgd and not just to the reliability of the MBR magic number in
 non-randomized applications.
 
 For a sense of scale, suppose there are 1000 users, and over the
 course of time, each of them types a wrong password 50 times with the
 verify_mbr method.
 
 In this scenario, there's better than a coin toss's odds in this
 scenario that one of those wrong password entries will be accepted,
 leading to alarming consequences when the resulting disk is full of
 gibberish.
 
 Maybe that's an optimistic estimate of the number of cgd(4) users, or
 a pessimistic estimate of their typing ability, but it's not _that_
 optimistic or pessimistic.  (I'm sure I've typed my password wrong
 more than 50 times.)