Hacker News new | past | comments | ask | show | jobs | submit login

Did you just propose a disk encryption scheme whereby PBKDF2 is called on a sector by sector basis?

Later: FWIW, it looks like the parent comment was edited after I wrote this.




Absolutely not, that would NOT SCALE.

Again, you're making accusations, shifting the conversation without providing evidence. Talking with you is pointless.


So when I "derive a new key" for a sector when it gets "rewritten", that key comes from...


Presumably the sector key is derived from the master key using one of the numerous fast KDFs, with PBKDF used only to derive the master key from the password. That's the obvious way to do it and midas007 explicitly mentions PBKDF as a way to generate a master key from a password with sector keys derived from that master key using some unspecified technique. You appear to have come up with your own obviously daft way of implementing the suggestion and then criticized that rather than the original proposal. Please don't do that.


Did you just propose running a KDF for every sector of the disk? Which of these numerous "fast KDFs" that derive related keys from master keys are you referring to?


Dunno, probably a generic HMAC-based one if for some weird reason I felt the urge to implement a crypto system that worked this way. Could probably use KDF1 or another KDF in that family too. (Honestly, there's probably no good reason to do things this way, it's just not obviously broken or infeasable.)


First, running an HMAC for every sector would be extremely slow.

Second, KDF1 would be even slower.

Third, you still haven't explained how KDF1 or HMAC takes you from the master key, derived from the user's password, to several million per-sector keys. What's the relationship between the keys?

Fourth, deriving keys from other keys is potentially dangerous; it's something you avoid doing if you can.

Fifth, as the article mentions, one of the reasons nothing in the universe does this is that running the key schedule millions of times is itself pointlessly time-consuming.

Sixth, you're running CTR mode deterministically. As the article points out, you can't do that: every time you alter a sector, you'll be encrypting data under the same keystream. Higher-level code gets to use CTR because it can arrange to randomize it, but in sector-level crypto you don't get to store a nonce.

What's frustrating to me here is that you basically just made a bunch of stuff up, and then feigned offense that I wouldn't have taken this nonsensical scheme seriously. But that's what it is: nonsensical. Nobody generates individual keys per sector. The article covers this: you'd like to do that, but it's too difficult.

Hence tweakable ciphers.

Lodge objections with Liskov, Rivest, Wagner, and Rogaway, not me.


> every time you alter a sector, you'll be encrypting data under the same keystream

I'm not sure that everybody has developed the intuition that this is horrifically dangerous. Maybe point them to something like

http://www.cs.jhu.edu/~jason/papers/mason+al.ccs06.pdf




Join us for AI Startup School this June 16-17 in San Francisco!

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

Search: