Hacker News Reader

Comment by ysleepy | Hacker News Reader

Uh interesting thought:

With Space sharing and multiple logical volumes there will probably be a shift to encrypting users home directories separately.

Probably even an unencrypted System Base, which is read-only and protected by rootless anyway, so the system can boot without user interaction.

This also finally allows the most user friendly implementation of file encryption: Encrypted Folders, supported by the OS.

Sounds cool, Id be willing to help with a rust port once the source is available :) (case sensitive only - naturally)

View on HN

The point of encrypting the base system image is mostly to make it part of the Secure Boot chain. rootless is a policy control to stop processes from modifying the OS from inside. An encrypted system image stops things with hardware access (but not the unlock key) from modifying the OS from the outside. You can trust any disk whose blocks you can decrypt with key X, to have been only written to by someone with key X.

Why would you need encryption for the Secure Boot chain? Would you not rather sign the base system image for that purpose?

You'd have to sit there and read the entire base system image before booting to verify that signature. But only have to decrypt a block when it comes time to read that block—with the ability to kernel-abort right then during the boot process if the block doesn't decrypt. (Or were you suggesting individually signing every block?)

You don't sign the whole image as a stream, and you don't sign every block. Recursion is your friend! You sign the Merkle tree root, check it once, and then check O(log n) hashes per block access. You can, of course, amortize the checking of the first several of those hashes as a further optimization that ties in easily with your caching layer.

There's no such thing as "the block doesn't decrypt" absent MACs/MICs or AEAD schemes -- encryption and decryption are just maps from N bytes to N bytes.

thanks for mansplaining rootless and encryption (/s).

Encryption is not authentication, so it does not prevent unnoticed modification.

And secure boot only really depends on authentication and not on encryption, so you are conflating two different concepts.

No you cant just trust the data, replay attacks over time and space are still an issue.

I'm not the one conflating them; it's the Secure Boot people who think this is a good idea. Full-Disk Encryption is the defined "OS" stage of the Secure Boot chain-of-trust today, acting as an "optimization" (heh) over signing disk blocks.

It's certainly more secure (indeed, it prevents replay attacks) to just keep a big block-hash table, update it when blocks change, and then hash that table and sign it on fsync—but it's costly in a few ways over just trusting unauthenticated encryption, and was even moreso five-to-eight years ago when Secure Boot was being formulated.

These days, you see a lot of wholly-signed read only OS images—the OSX recovery partition is signed; CoreOS signs its OS images; most firmware is signed; etc. But I don't expect the unauthenticated-encryption on most computers' read-write rootfs will be replaced by a signed-but-unencrypted filesystem any time soon—if just for the fact that consumers really seem to hate the idea of separate OS and data partitions, especially when the OS partition is "stealing space" they could be using for data. (The only thing I can think of that might finally kill this making the default install on some consumer-OS create a thin pool, such that an OS partition that only contains 5G of data only "steals" 5G of their "space.")

Or, y'know, authenticated encryption. Do any block-device cryptosystems support an AEAD mode yet? LUKS maybe?

> Do any block-device cryptosystems support an AEAD mode yet?

FreeBSD's geli supports authenticating data with HMACs.

https://www.freebsd.org/cgi/man.cgi?geli(8)#end

> "You can trust any disk whose blocks you can decrypt with key X, to have been only written to by someone with key X."

No you can not. That is your sentence not from Secure Boot People.

Also I assume that APFS will support encrypted and unencrypted logical FS in the same space sharing FS instance. So the separate OS partition is just a logical FS which is unencrypted. - Which I meant in my original post.

GELI and the AES-GCM are authenticated. Not sure if GCM has equivalent properties to the GELI HMAC feature but probably good enough.

https://en.wikipedia.org/wiki/Galois/Counter_Mode

>mansplaining

Thank you for injecting sexism into a technical discussion.

white male 20-something here, I find it funny.

Reply on news.ycombinator.com