Warning: DOMDocument::loadXML() [function.DOMDocument-loadXML]: PCDATA invalid Char value 27 in Entity, line: 118 in /srv/lkml.org/scripts/getmail.php on line 208
Warning: DOMDocument::loadXML() [function.DOMDocument-loadXML]: PCDATA invalid Char value 27 in Entity, line: 118 in /srv/lkml.org/scripts/getmail.php on line 208
Warning: XSLTProcessor::transformToXml() expects parameter 1 to be object, boolean given in /srv/lkml.org/scripts/getmail.php on line 211
This message generated a parse failure. Raw output follows here. Please use 'back' to navigate.
From devnull@lkml.org Tue Dec 2 13:42:26 2008
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262478AbUCCPSp (ORCPT ); Wed, 3 Mar 2004 10:18:45 -0500
Received: from 104.engsoc.carleton.ca ([134.117.69.104]:41871 "EHLO quickman.certainkey.com") by vger.kernel.org with ESMTP id S262477AbUCCPSl convert rfc822-to-8bit (ORCPT ); Wed, 3 Mar 2004 10:18:41 -0500
Received: from jlcooke by quickman.certainkey.com with local (Exim 3.36 #1 (Debian)) id 1AyXxP-0000UN-00; Wed, 03 Mar 2004 10:06:47 -0500
Date: Wed, 3 Mar 2004 10:06:47 -0500
From: Jean-Luc Cooke
To: dean gaudet
Cc: James Morris , Christophe Saout , Carl-Daniel Hailfinger , Linux Kernel Mailing List , Andrew Morton
Subject: Re: dm-crypt, new IV and standards
Message-Id: <20040303150647.GC1586@certainkey.com>
References: <20040220172237.GA9918@certainkey.com> <20040221164821.GA14723@certainkey.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: 8BIT
In-Reply-To:
User-Agent: Mutt/1.5.5.1+cvs20040105i
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/