The Key From Before Enabling FileVault

To be fair, Apple does mostly document this process:

https://www.apple.com/mac/docs/Apple_T2_Security_Chip_Overview.pdf

Maybe there is some per-chip specificity that forestalls a general security weakness.

Yes, the UID:

The Mac unique ID (UID) and a device group ID (GID) are AES 256-bit keys fused (UID) or compiled (GID) into the Secure Enclave during manufacturing. No software or firmware can read the keys directly. []..] Software running on the Secure Enclave takes advantage of the UID to protect device-specific secrets such as Touch ID data, FileVault class keys, and the Keychain.

The UID allows data to be cryptographically tied to a particular device. For example, the key hierarchy protecting the file system includes the UID

if the data is already encrypted, the decryption key and/or salt value either must remain the same, or all the data must be decrypted and re-encrypted.

Yes:

Internal volume encryption on a Mac with the T2 chip is implemented by constructing and managing a hierarchy of keys

[..] This hierarchy of keys is designed to simultaneously achieve four goals: [.]

Enable users to change their password (and in turn the cryptographic keys used to protect their files) without requiring re-encryption of the entire volume.

And:

All APFS volumes are created with a volume key by default. Volume and metadata contents are encrypted with this volume key, which is wrapped with the class key. The class key is protected by a combination of the user’s password and the hardware UID when FileVault is enabled. This protection is the default on Mac computers with the T2 chip.

If FileVault isn’t enabled on a Mac with the T2 chip during the initial Setup Assistant process, the volume is still encrypted, but the volume key is protected only by the hardware UID in the Secure Enclave. If FileVault is enabled later—a process that is immediate since the data was already encrypted—an anti-replay mechanism prevents the old key (based on hardware UID only) from being used to decrypt the volume. The volume is then protected by a combination of the user password with the hardware UID as previously described.

(That page also features a figure of the key hierarchy.)

It’s not entirely clear to me how this works (I assume the password never actually becomes part of the key-derivation function?), but people who know more about cryptography than I do (which ain’t hard) will probably be able to glean some more information from Apple’s document.

I just got a new 2018 Mac mini and have encountered a critical bug after enabling FileVault.

Last night, I enabled FileVault on my 2018 Mac mini from within System Preferences. This morning, when I booted my Mac after shutting it down (the first boot after turning on FileVault), I was prompted to enter my password to sign in, and it didn’t work! After a few incorrect tries, I was prompted to enter my FileVault Recovery Key, so I entered my carefully recorded Recovery Key, and that didn’t work either.

So basically I am now completely locked out of my Mac, with no way to recover my data.

Here’s the crazy thing: if I boot into Recovery Mode (holding cmd-R at boot time) and then try to launch Terminal from within Recovery Mode, I am prompted for my administrator password to open Terminal. If I enter my password there, it works!

So somehow the system installed in Recovery Mode has my correct password, but BridgeOS or EFI or whatever controls the early boot process for volumes with FileVault enabled is borked and won't accept my password, so now I am permanently locked out and I’m going to have to restore my entire Mac. :-(

Be very careful when turning on FileVault on T2 Macs. When you reboot your machine, you may be in for a nasty surprise, like me.

@Jeff Hunter,
You seem to be pretty knowledgeable here, can you update us on your findings? Do you have only a single user account on this Mac? Did you find any mention of this problem elsewhere?