Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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?


> "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


> 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


>mansplaining

Thank you for injecting sexism into a technical discussion.


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




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: