From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S262861AbTFTLDP (ORCPT ); Fri, 20 Jun 2003 07:03:15 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262874AbTFTLDP (ORCPT ); Fri, 20 Jun 2003 07:03:15 -0400 Received: from chello080108023209.34.11.vie.surfer.at ([80.108.23.209]:8065 "HELO ghanima.endorphin.org") by vger.kernel.org with SMTP id S262861AbTFTLDN (ORCPT ); Fri, 20 Jun 2003 07:03:13 -0400 Date: Fri, 20 Jun 2003 13:15:40 +0200 To: Andi Kleen Cc: J?rn Engel , Fruhwirth Clemens , linux-kernel@vger.kernel.org Subject: Re: [PATCH] Initial Vector Fix for loop.c. Message-ID: <20030620111540.GA2649@ghanima.endorphin.org> References: <20030620090612.GA1322@ghanima.endorphin.org.suse.lists.linux.kernel> <20030620101452.GA2233@ghanima.endorphin.org> <20030620102455.GC26678@wotan.suse.de> <20030620103538.GA28711@wohnheim.fh-wedel.de> <20030620104953.GD26678@wotan.suse.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7JfCtLOvnd9MIVvH" Content-Disposition: inline In-Reply-To: <20030620104953.GD26678@wotan.suse.de> User-Agent: Mutt/1.3.28i From: Fruhwirth Clemens X-Delivery-Agent: TMDA/0.51 (Python 2.1.3 on Linux/i686) Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org --7JfCtLOvnd9MIVvH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jun 20, 2003 at 12:49:53PM +0200, Andi Kleen wrote: Comment: [1] stands for cryptoloop's CBC mode. > [1] the problem is that it is too predictable. consider block 0, > which is usually filled with zeros. It also has IV=3D=3D0. This means > it it 100% equivalent to CBC and worse even has known plain text. > Same problem applies to other blocks - the layout of most=20 > installations generated by standard installers is quite predictible. > Fixing it is simple, but requires a new secret per file system. Adding another secret doesn't improve security in that case.=20 Of course the first block is vulnerable to known plaintext attacks, but you can only prevent those if you make the IV dependend on another secret.. the key for example. But then you could have also just increased the key size, which somehow automatically leads to the conclusion: the key is the only secret which matters. You don't add security if you split the secret. Clemens --7JfCtLOvnd9MIVvH Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE+8uzcW7sr9DEJLk4RAnDCAJ9DIFodjdzGNDiyHzzrzmzXfft+hQCfYPoK c6jaXzdES8lGjw7oITQ2VyU= =FMxx -----END PGP SIGNATURE----- --7JfCtLOvnd9MIVvH--