Support for "raw" key slots

The iterated hashing process used in LUKS' key slots is useful for (potentially weak) passphrases. However, it is useless if the key slot is locked with a cryptographically strong key file (like a file created from /dev/random).

Therefore I propose the addition of a "raw key slot" feature to LUKS, where a key that has the exact length of the master key is simply XOR'ed to the master key and saved in the key slot (after the usual striping of course).

I don't see any obvious security implications with this feature. If there are any, I'd be interested. Please consider this for a future LUKS specification.

It may be useless but it doesn't cause any harm. And it may even be useful in the case of a compromised RNG.

The main advantage I see is saving on the expensive iterated hashing, but then you could accomplish almost the same by just specifying a low iteration count/time.

-- Roscoe

At Fri, 14 Aug 2009 09:36:09 +0200,

There's an option "--iter-time" where you can specify/reduce the iteration count. It's main purpose is well to slow down bruteforce attacks. Don't know if it's that what you're after.