Re: dm-crypt, new IV and standards

[Jean-Luc Cooke]

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/