From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <octane@alinto.com>
Received: from mail.saout.de ([127.0.0.1])
 by localhost (mail.saout.de [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 413VCw4f0Cis for <dm-crypt@saout.de>;
 Tue, 21 May 2013 09:25:13 +0200 (CEST)
Received: from vauxhall.alinto.net (vauxhall.alinto.net [83.145.109.24])
 by mail.saout.de (Postfix) with ESMTP
 for <dm-crypt@saout.de>; Tue, 21 May 2013 09:25:13 +0200 (CEST)
Received: from http2alinto.alinto.net (http2alinto.alinto.net [83.145.109.62])
 by vauxhall.alinto.net (Postfix) with ESMTP id 478E428CC58
 for <dm-crypt@saout.de>; Tue, 21 May 2013 09:24:44 +0200 (CEST)
Message-ID: <1369121083.519b213be8fd2@www.inmano.com>
Date: Tue, 21 May 2013 09:24:43 +0200
From: octane indice <octane@alinto.com>
In-Reply-To: <20130521021714.GA563@tansi.org>
References: <519AA42D.4000609@ramses-pyramidenbau.de>
 <20130520234122.GA31243@tansi.org> <519AB8C5.7090908@ramses-pyramidenbau.de>
 <20130521021714.GA563@tansi.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [dm-crypt] Authenticated Encryption for dm-crypt
List-Id: <dm-crypt.saout.de>
List-Unsubscribe: <http://www.saout.de/mailman/options/dm-crypt>,
 <mailto:dm-crypt-request@saout.de?subject=unsubscribe>
List-Archive: <http://www.saout.de/pipermail/dm-crypt/>
List-Post: <mailto:dm-crypt@saout.de>
List-Help: <mailto:dm-crypt-request@saout.de?subject=help>
List-Subscribe: <http://www.saout.de/mailman/listinfo/dm-crypt>,
 <mailto:dm-crypt-request@saout.de?subject=subscribe>
To: dm-crypt@saout.de

En r=E9ponse =E0 Arno Wagner <arno@wagner.name> :
> The additional space is not the problem. The problem is
> keeping  data and additonal data consistent and keeping
> head-movements  minimal. There is quite a bit of discussion
> and literature around about these problems as this gets
> proposed time and again.=20
> If I remember correctly, some people even tried with custom
> disks  that had 540 byte sectors or something like that. All
> efforts failed, this idea always dies as soon as practical
> filesystem aspects come  into play.=20
>=20
Maybe it's off topic, but why we don't put integrity at
filesystem level?
If we mess something at ciphered level, we could detect
it at filesystem level because it's really unlikely that somebody
could break the ciphered level *and* keep filesystem integrity.

Thanks

Envoy=E9 avec Inmano, ma messagerie renversante et gratuite : http://www.in=
mano.com