Messages in this thread | | | Date | Thu, 4 Mar 2004 08:24:30 -0500 | From | Jean-Luc Cooke <> | Subject | Re: dm-crypt, new IV and standards |
| |
On Wed, Mar 03, 2004 at 05:48:46PM -0800, dean gaudet wrote: > On Wed, 3 Mar 2004, Jean-Luc Cooke wrote: > > > The difference between "$1,000,000" and "$8,000,000" is 1 bit. If an > > attacker knew enough about the layout of the filesystem (modify times on blocks, > > etc) they could flip a single bit and change your $1Mil purchase order > > approved by your boss to a $8Mil order. > > ah ok i was completely ignoring the desire to prevent data tampering. > > you have to admit it's still a bit more effort than flipping 1 bit like > you suggest since you need to tweak the encrypted data enough so that the > decrypted data has only 1 bit flipped. (especially if you use CBC like > you mention.) > > something else which i've been wondering about -- would there be any extra > protection provided by permuting block addresses so that the location of > wellknown blocks such as the superblock and inode maps aren't so > immediately obvious? given the lack of known plaintext attacks on AES i'm > thinking there's no point to permuting, but i'm not a cryptographer, i > only know enough to be dangerous. (you'd want to choose a permutation > which makes some effort to group blocks into large enough chunks so that > *some* seek locality can be maintained.)
I think there is not value in "security though obscurity" when you're developing an open source application. :)
Like you said, CBC is not trivial to temper with - though it is do able. CTR is trivial on the other hand. Which is why NIST and every cryptographer will recommend using a MAC with CTR. (Why still have CTR? Unlike CBC, you can compute the N+1-th block without needing to know the output from the N-th block, so there is the possibility for very high parallelizum).
JLC
-- http://www.certainkey.com Suite 4560 CTTC 1125 Colonel By Dr. Ottawa ON, K1S 5B6 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |