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

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

> Date: Mon, 29 Apr 2024 05:19:05 +0700
> From: Robert Elz <kre%munnari.OZ.AU@localhost>
> 
>   | Would also be nice if we could quantify the false acceptance probability
> 
> 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=1.62#1058

   1070 	ret = prog_pread(fd, buf, SCANSIZE, 0);
   1071 	if (ret < 0) {
   1072 		warn("can't read mbr area");
   1073 		return -1;
   1074 	}
   1075 
   1076 	memcpy(&mbr, buf, sizeof(mbr));
   1077 	if (le16toh(mbr.mbr_magic) != MBR_MAGIC)
   1078 		return 1;
   1079 
   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=1.62#1185
https://nxr.netbsd.org/xref/src/sys/ufs/ffs/fs.h?r=1.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.)