On Sat, 21 Feb 2004, Jean-Luc Cooke wrote:
> Well, CTR mode is not recommended for encrypted file systems because it is very
> easy to corrupt single bits, bytes, blocks, etc without an integrity check.
> If we add a MAC, then any mode of operation except ECB can be used for
> encrypted file systems.
what does "easy to corrupt" mean? i haven't really seen disks generate
bit errors ever. this MAC means you'll need to write integrity data for
every real write. that really doesn't seem worth it...
it seems like a block is either right, or it isn't -- the only thing the
MAC is telling you is that the block isn't right... it doesn't tell you
how to fix it. that's a total waste of write bandwidth -- you might as
well return the bogus decrypted block.
> [3] Why not use IV == block number or IV == firstIV + block number?
> Certain modes of operation (like CTR) begin to leak information about the
> plaintext if you ever use the same Key-IV pair for your data.
> The IV will need to be updated every time you update the block.
> The IV generation does need not be from a cryptographicly strong PRNG,
> it need only be different from the previous IV.
> So incrementing the IV by 1 mod 2^128 every time you write to the block will
> suffice.
is CTR the only mode which is weak with simple IV / block number
relationships?
if you absolutely need this IV update for every write then you should
consider a disk layout which mixes IV (or IV+MAC) blocks so that they are
grouped near their data blocks, to reduce seek overhead.
i.e. 1 block containing 15 IV+MAC, followed by 15 data blocks, followed by
IV+MAC, followed by 15 data...
-dean
On Wed, Mar 03, 2004 at 12:35:07AM -0800, dean gaudet wrote:
> On Sat, 21 Feb 2004, Jean-Luc Cooke wrote:
>
> > Well, CTR mode is not recommended for encrypted file systems because it is very
> > easy to corrupt single bits, bytes, blocks, etc without an integrity check.
> > If we add a MAC, then any mode of operation except ECB can be used for
> > encrypted file systems.
>
> what does "easy to corrupt" mean? i haven't really seen disks generate
> bit errors ever. this MAC means you'll need to write integrity data for
> every real write. that really doesn't seem worth it...
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.
Extraneous example to be sure. But this is why you want MACs. CBC mode is
more difficult to tamper with, but not immune.
> it seems like a block is either right, or it isn't -- the only thing the
> MAC is telling you is that the block isn't right... it doesn't tell you
> how to fix it. that's a total waste of write bandwidth -- you might as
> well return the bogus decrypted block.
A block cipher can be viewed as a huge lookup table. Converting a 128 bit
block of data (in the case of AES) into another using a single key as the
rule-set for this transformation. This alone is not secure (think of the
attacks on ECB which does exactly this for all your data). That's why we
have 6 modes of operation in common use in the industry.
ECB, CBC : block-mode
CFB, OFB : stream-moe
CTR : block- and/mode stream-mode
OMAC : 128bit keyed Message Authentication Code
CCM : CTR + CBC-MAC defined by IEEE 802.11i
> > [3] Why not use IV == block number or IV == firstIV + block number?
> > Certain modes of operation (like CTR) begin to leak information about the
> > plaintext if you ever use the same Key-IV pair for your data.
> > The IV will need to be updated every time you update the block.
> > The IV generation does need not be from a cryptographicly strong PRNG,
> > it need only be different from the previous IV.
> > So incrementing the IV by 1 mod 2^128 every time you write to the block will
> > suffice.
>
> is CTR the only mode which is weak with simple IV / block number
> relationships?
CTR, ECB, and CFB are vulnerable.
> if you absolutely need this IV update for every write then you should
> consider a disk layout which mixes IV (or IV+MAC) blocks so that they are
> grouped near their data blocks, to reduce seek overhead.
>
> i.e. 1 block containing 15 IV+MAC, followed by 15 data blocks, followed by
> IV+MAC, followed by 15 data...
CBC mode doesn't absolutely need macs. But the IV changes *are* required for
all modes of operation. Christophe and I's scheme of IV = firstIV + blockNum
for initial setup and IV = IV + 2^64 for IV updates will work fine as long as
there are less then 2^(128-64) block in the file system and less then 2^64
updates to any one block. This scheme will keep CBC, OFB, CTR, and CCM modes
secure from eavesdropping but not Necessarily[1~[1~ from tampering.
JLC
--
http://www.certainkey.com
Suite 4560 CTTC
1125 Colonel By Dr.
Ottawa ON, K1S 5B6
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.)
-dean
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
On Thu, 4 Mar 2004, Jean-Luc Cooke wrote:
> 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).
for disk crypto there are other opportunities for parallelism using
bitslicing to encrypt/decrypt multiple blocks in parallel (for example see
<http://www.cs.utexas.edu/users/atri/papers/spaa.ps>). there's a
latency/throughput tradeoff though...
-dean
On Thu, Mar 04, 2004 at 05:19:26PM -0800, dean gaudet wrote:
> On Thu, 4 Mar 2004, Jean-Luc Cooke wrote:
>
> > 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).
>
> for disk crypto there are other opportunities for parallelism using
> bitslicing to encrypt/decrypt multiple blocks in parallel (for example see
> <http://www.cs.utexas.edu/users/atri/papers/spaa.ps>). there's a
> latency/throughput tradeoff though...
Humm. Though AES uses GF's a lot, I think on 32bit processors bit slicing
AES just isn't worth it.
Though 512 byte fs blocks would only take 16 "transforms". It's really hard
to implement ShiftRow() in bitwise SIMD...and x86 cpus simply don't have
enough registers (aliased or otherwise) to do this I think. Fun read though!
JLC - bit-slicing MD5() will not improve things either, tried that for MD5CRK
--
http://www.certainkey.com
Suite 4560 CTTC
1125 Colonel By Dr.
Ottawa ON, K1S 5B6
Hi!
> > > Well, CTR mode is not recommended for encrypted file systems because it is very
> > > easy to corrupt single bits, bytes, blocks, etc without an integrity check.
> > > If we add a MAC, then any mode of operation except ECB can be used for
> > > encrypted file systems.
> >
> > what does "easy to corrupt" mean? i haven't really seen disks generate
> > bit errors ever. this MAC means you'll need to write integrity data for
> > every real write. that really doesn't seem worth it...
>
> 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.
Hmm... long time ago I created crc loop device to catch
faulty disks. If cryptoloop can do that for me... very good!
--
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms
Pavel Machek wrote:
> Hi!
>
>
>>>>Well, CTR mode is not recommended for encrypted file systems because it is very
>>>>easy to corrupt single bits, bytes, blocks, etc without an integrity check.
>>>>If we add a MAC, then any mode of operation except ECB can be used for
>>>>encrypted file systems.
>>>
>>>what does "easy to corrupt" mean? i haven't really seen disks generate
>>>bit errors ever. this MAC means you'll need to write integrity data for
>>>every real write. that really doesn't seem worth it...
>>
>>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.
>
>
> Hmm... long time ago I created crc loop device to catch
> faulty disks. If cryptoloop can do that for me... very good!
Yes, a crc, or some other very low overhead DM target would be great for
this. I haven't looked at DM too much. :( Does it already have
something like this already?