| |||||||||||
A weak cryptoloop implementation in Linux?A weak cryptoloop implementation in Linux?Posted Jan 22, 2004 13:45 UTC (Thu) by gyles (subscriber, #1600)In reply to: A weak cryptoloop implementation in Linux? by macc Parent article: A weak cryptoloop implementation in Linux?
(Log in to post comments)
A weak cryptoloop implementation in Linux? Posted Jan 22, 2004 15:28 UTC (Thu) by IkeTo (subscriber, #2122) [Link] But the alternative to just XOR every disk block with a 4096-byte random string (and store that string somewhere, in plaintext) before passing it to the loopback device will work to stop the attack described here.
A weak cryptoloop implementation in Linux? Posted Jan 23, 2004 20:50 UTC (Fri) by Ross (subscriber, #4065) [Link] Better would be to generate that random string through a pseudorandomnumber generator given a seed like the position of that block. I thought this was already done? I mean this is basically the initialization vector and without it identical blocks on disk would be identical after they were encypted... leaking all kinds of information. If this is not done it is a very serious bug. If it is done, why is this other attack a problem? Is the seeds for the generator the same for every filesystem? If so, a simple fix would be to store a single value to XOR with the offset before calculating the IV.
A weak cryptoloop implementation in Linux? Posted Jan 23, 2004 13:47 UTC (Fri) by bockman (subscriber, #3650) [Link] I wonder if it is would be possible to store such 'known plaintext' as real plaintext, thus making it useless for an attacker. But maybe this would make the cryptoloop not transparent to the above file system code.The conclusion seems to be that it is more secure to encrypt each single file that the whole filesystem.
|
|||||||||||