>Well, I can't find any reference to 'PCBC' mode in applied cryptography,
>so I can't agree or disagree :)
>
>Ok - here my crypto-knowledge (or, rather, the lack thereof) is going to
>show:
>
>Surely CBC mode can't work across the whole loopback device anyway? It
>only applies across the whole device it would mean we couldn't
>random-seek,
>right?
Well we could, but every read/write would require every block to be
read/written. A major performance problem for a block device.
>> There're problems with IDEA, too (ECB mode), but I'm not even going to
There are major problems with ECB mode, especially on a disk where there
are superblock magic numbers and predictable headers and patterns. CBC
mode is much better, but if it can only be applied on a per-block basis,
you still have major problems with security (more same-key cyphertexts).
If the key was somehow dependent on the block number on disk, this would
be a much less significant problem.
>> If we made the CBC mode work for the filesystem as a whole, not just
>the
>> blocks, then with my current patch it would be possible to
>encrypt/decrypt
>
>Ok - so you have confirmed that it works on a block basis.
>
>Doesn't this mean that we can't transfer an FS made on one platform to a
>different architecture? (eg i386 to Alpha - I believe that Alpha have
>4k blocks - if my memory serves me)
This is memory block size, not FS block size. Ext2 has a variable block
size, but all ext2 implementations can handle any valid block size.
However, would a big-endian machine be able to read an ext2 filesystem
written by a little-endian machine? I am not thinking clearly right now
due to lack of caffeine. I guess it would, as data must have to be put
into bus endianness upon leaving the processor.
Zachary Amsden
amsden@andrew.cmu.edu
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html