A weak cryptoloop implementation in Linux? [LWN.net]

A weak cryptoloop implementation in Linux?

Posted Jan 23, 2004 16:21 UTC (Fri) by spudbeach (guest, #5837)
Parent article: A weak cryptoloop implementation in Linux?

One other way around the problem is Cipher Block Chaining (CBC), where the output of each block is dependent on all prior blocks, as well as a randomly chosen initial vector (IV). That basically makes known plaintext / dictionary attacks such as this one useless, unless they are on the first block encrypted. All at very little cost to decrypt, too.

Oh, and should anybody not trust Juri, note that he has been the big guy in the loop-AES project for a couple of years, doing loop mounted crypto outside of the kernel. Yes, he does know what he's doing. And yes, I'm sticking with loop-AES, for at least a couple of years. [And BTW: loop-AES is by design free from this attack: rather than using a passphrase directly, a true random key is used, which is then encrypted with a passphrase -- hence, one more step between the passphrase and known plaintext.]

Steve Beach
GPG key ID 7675D05E

to post comments

A weak cryptoloop implementation in Linux?

Posted Jan 23, 2004 20:52 UTC (Fri) by Ross (guest, #4065) [Link] (1 responses)

Wouldn't that cause severe problem for a random-access read/write block
device? A change to a block would require reading, decrypting,
reencrypting, and finally re-writing every block that came after it!

A weak cryptoloop implementation in Linux?

Posted Oct 5, 2005 18:05 UTC (Wed) by kokopelli (guest, #11341) [Link]

You always have to read and write a complete disk page. Each page should be handled independently for various reasons. The only information that should "leak" into the encryption process is the absolute or relative block offset - as others mentioned it's used to set up a different 'initialization vector' for each page. (Global or per-page salt would also end up in the IV.)

Block ciphers will typically encrypt 8 to 32 bytes as a unit. If they're run independently you get a 'codebook' cipher - vulnerable to known-text attack anywhere within the disk page. If they're chained you're only vulnerable for the first cipher block of each page. There's no real cost to chaining as long as it doesn't extend beyond the disk page.