Meta information:
This mail proposes a fix for:
must-fix list item "drivers/block/loop.c" and
should-fix list item "drivers/block/cryptoloop"
Content:
loop.c is broken. It's broken since 2.4. In particular the initial vector
calculation which every cryptographic loop transformation uses is broken.
What's the problem you might ask.. It's that that the IV calculation is
based on the logical block sector of the block device. Just think of what
happends if you move your image to another device with a different block
size..
Correct! The IV metric changes and everyone who knows what's CBC
encryption will correctly conclude: you can't read your image.
That's bad. And that's the reason why every project which provides you with
encryption via loop.c will also provide you with a patch for this broken
loop.c behavior.
The fix is quite simple. Just switch to a fixed IV metric. Which is: the
smallest granulity -> fixed 512-byte and kerneli.org's cryptoloop as well as
Jari's loop-AES do exactly that.
These two packages are the only facilities I'm aware of that provides
harddisc encryption for the 2.4. kernel. However marcello refused to switch
the IV metric for 2.4. because it will - yes that's correct - break any
image which has been created with a IV-sensitiv loop transformation..
..BUT except for cryptoloop and loop-AES there are no such loop
transformation modules! And those two projects have already fixed this
issue. So we're providing backward compatiblity for nothing here. No user
base could ever benefit from this backward compatiblity, since the only
reason the initial vector calculation is done is for crypto and every crypto
project out there already uses the 512-byte IV-metric.
So go for it. Fix it before 2.6.x is out and we're stuck with this crap
again.
http://bugzilla.kernel.org/show_bug.cgi?id=192
Just apply the patch.
If this bug is fixed, we can go ahead and add cryptoloop which is ready and
tested.
Regards, Clemens
Fruhwirth Clemens <[email protected]> wrote:
>
> If this bug is fixed, we can go ahead and add cryptoloop which is ready and
> tested.
Does it use the crypto framework which is present in the 2.5 kernel?
If it does not then the cryptoloop implementation which you mention
is inappropriate for inclusion.
If it does then it would be nice to see the full patchset.
Fruhwirth Clemens <[email protected]> writes:
> So go for it. Fix it before 2.6.x is out and we're stuck with this crap
> again.
This will break existing crypto loop installations, making
the existing encrypted image unreadable. After all this is Linux
here, not HackOS where you can break user file system formats at will.
The only way to implement this is with a new flag that is set by losetup
and keep the old behaviour by default.
-Andi
On Fri, Jun 20, 2003 at 11:30:03AM +0200, Andi Kleen wrote:
> Fruhwirth Clemens <[email protected]> writes:
>
> > So go for it. Fix it before 2.6.x is out and we're stuck with this crap
> > again.
>
> This will break existing crypto loop installations, making
> the existing encrypted image unreadable. After all this is Linux
> here, not HackOS where you can break user file system formats at will.
> The only way to implement this is with a new flag that is set by losetup
> and keep the old behaviour by default.
There is no cryptoloop installation which is affected by this. Read my mail
properly. Every cryptoloop setup out there uses loop-AES or kerneli's
patch-int. And both fixed this issue a _long_ time ago. (Have a look at
the linux-crypto archives of 2001).
Adam Richter's version of loop.c which is in his ygg tree is quite nice,
but his changes are HUGE. Nobody is going to split them up in small patches.
Again: _no_ userbase is affected by this change. Every userbase which
could have ever been affected has done the fix for itself.
Clemens
On Fri, Jun 20, 2003 at 12:14:52PM +0200, Fruhwirth Clemens wrote:
> On Fri, Jun 20, 2003 at 11:30:03AM +0200, Andi Kleen wrote:
> > Fruhwirth Clemens <[email protected]> writes:
> >
> > > So go for it. Fix it before 2.6.x is out and we're stuck with this crap
> > > again.
> >
> > This will break existing crypto loop installations, making
> > the existing encrypted image unreadable. After all this is Linux
> > here, not HackOS where you can break user file system formats at will.
> > The only way to implement this is with a new flag that is set by losetup
> > and keep the old behaviour by default.
>
> There is no cryptoloop installation which is affected by this. Read my mail
> properly. Every cryptoloop setup out there uses loop-AES or kerneli's
> patch-int. And both fixed this issue a _long_ time ago. (Have a look at
That's completely wrong. I know of several independent implementation
and installations.
> Again: _no_ userbase is affected by this change. Every userbase which
> could have ever been affected has done the fix for itself.
That's also incorrect.
-Andi
On Fri, 20 June 2003 12:24:55 +0200, Andi Kleen wrote:
> On Fri, Jun 20, 2003 at 12:14:52PM +0200, Fruhwirth Clemens wrote:
> > On Fri, Jun 20, 2003 at 11:30:03AM +0200, Andi Kleen wrote:
> > > Fruhwirth Clemens <[email protected]> writes:
> > >
> > > > So go for it. Fix it before 2.6.x is out and we're stuck with this crap
> > > > again.
> > >
> > > This will break existing crypto loop installations, making
> > > the existing encrypted image unreadable. After all this is Linux
> > > here, not HackOS where you can break user file system formats at will.
> > > The only way to implement this is with a new flag that is set by losetup
> > > and keep the old behaviour by default.
> >
> > There is no cryptoloop installation which is affected by this. Read my mail
> > properly. Every cryptoloop setup out there uses loop-AES or kerneli's
> > patch-int. And both fixed this issue a _long_ time ago. (Have a look at
>
> That's completely wrong. I know of several independent implementation
> and installations.
That leaves the question of what the default behaviour should be. If
we have to switch to 512Byte in the long run anyway, there is little
point in postponing the pain. Make it the default, and old behaviour
depends on the flag.
If we can avoid the pain completely, use that better fix instead, even
if it isn't ready before 2.7, and ignore the problem until then.
Can we?
J?rn
--
Fantasy is more important than knowlegde. Knowlegde is limited,
while fantasy embraces the whole world.
-- Albert Einstein
On Fri, Jun 20, 2003 at 12:24:55PM +0200, Andi Kleen wrote:
> On Fri, Jun 20, 2003 at 12:14:52PM +0200, Fruhwirth Clemens wrote:
> > There is no cryptoloop installation which is affected by this. Read my mail
> > properly. Every cryptoloop setup out there uses loop-AES or kerneli's
> > patch-int. And both fixed this issue a _long_ time ago. (Have a look at
>
> That's completely wrong. I know of several independent implementation
> and installations.
Can't you just name them?
Clemens
> That leaves the question of what the default behaviour should be. If
> we have to switch to 512Byte in the long run anyway, there is little
> point in postponing the pain. Make it the default, and old behaviour
> depends on the flag.
In my opinion it doesn't make much difference. crypto-loop
has broken beyond belief[1] IV anyways, so they will
eventually need to change it. Or just use CBC, which is simpler
and compatible and has nearly equivalent security to the easily
predictable IV :-) And when they change it they can as well set the flag.
Also I think Clemens is exaggerating the problem too.
The old 2.2 behaviour of using absolute IVs caused quite
some problems, but the relative IVs used in 2.4 are
not that bad because it is near always used with 4K
blocks (there are exceptions to this, but they're quite
rare assuming your file systems are all big enough
and you don't use a S390)
-Andi
[1] the problem is that it is too predictable. consider block 0,
which is usually filled with zeros. It also has IV==0. 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
installations generated by standard installers is quite predictible.
Fixing it is simple, but requires a new secret per file system.
Typo in there.
On Fri, Jun 20, 2003 at 12:49:53PM +0200, Andi Kleen wrote:
> In my opinion it doesn't make much difference. crypto-loop
> has broken beyond belief[1] IV anyways, so they will
> eventually need to change it. Or just use CBC, which is simpler
^^^
should be ECB of course.
>
> [1] the problem is that it is too predictable. consider block 0,
> which is usually filled with zeros. It also has IV==0. This means
> it it 100% equivalent to CBC and worse even has known plain text.
^^^
also ECB here.
-Andi
On Fri, Jun 20, 2003 at 12:35:38PM +0200, J?rn Engel wrote:
> On Fri, 20 June 2003 12:24:55 +0200, Andi Kleen wrote:
> > On Fri, Jun 20, 2003 at 12:14:52PM +0200, Fruhwirth Clemens wrote:
> > > There is no cryptoloop installation which is affected by this. Read my mail
> > > properly. Every cryptoloop setup out there uses loop-AES or kerneli's
> > > patch-int. And both fixed this issue a _long_ time ago. (Have a look at
> >
> > That's completely wrong. I know of several independent implementation
> > and installations.
>
> That leaves the question of what the default behaviour should be. If
> we have to switch to 512Byte in the long run anyway, there is little
> point in postponing the pain. Make it the default, and old behaviour
> depends on the flag.
Let's see. If there is flag based fix and we make the old behavior default
we will trick many new users into using the old broken IV metric. If we make
the new metric default the user can't mount his old images.
As there is no autodetection for default behavior, there will be no way to
avoid the pain. Well, almost. We could allocate a new major for a different
metric, and create /dev/loop-ng*. That'd be feasible, but actually just a
pain transfer .. from the user to the developer :)
> If we can avoid the pain completely, use that better fix instead, even
> if it isn't ready before 2.7, and ignore the problem until then.
No please, I don't wanna patch my kernel for another 2 years. Andrew Morton
is right when he puts this issue on his must-fix list.
Clemens
On Fri, 20 June 2003 12:51:20 +0200, Fruhwirth Clemens wrote:
>
> Let's see. If there is flag based fix and we make the old behavior default
> we will trick many new users into using the old broken IV metric. If we make
> the new metric default the user can't mount his old images.
Unless he starts thinking and reads up how it works in 2.6.
> As there is no autodetection for default behavior, there will be no way to
> avoid the pain. Well, almost. We could allocate a new major for a different
> metric, and create /dev/loop-ng*. That'd be feasible, but actually just a
> pain transfer .. from the user to the developer :)
I don't see a problem with that, assuming there are more users than
developers. :)
J?rn
--
Do not stop an army on its way home.
-- Sun Tzu
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==0. 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
> 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.
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
Andi Kleen <[email protected]> wrote:
>
> > So go for it. Fix it before 2.6.x is out and we're stuck with this crap
> > again.
>
> This will break existing crypto loop installations, making
> the existing encrypted image unreadable.
I think we should just live with that breakage Andi. You're suggesting
that we retain compatibility with something which was never merged into the
kernel. That is asking too much.
I'd prefer to see a good, clean, solid implementation of cryptoloop.
Presumably migration tools from old to new will turn up.
On Fri, 2003-06-20 at 10:56, Andrew Morton wrote:
> Andi Kleen <[email protected]> wrote:
> >
> > > So go for it. Fix it before 2.6.x is out and we're stuck with this crap
> > > again.
> >
> > This will break existing crypto loop installations, making
> > the existing encrypted image unreadable.
>
> I think we should just live with that breakage Andi. You're suggesting
> that we retain compatibility with something which was never merged into the
> kernel. That is asking too much.
There was effectively no cryptoloop support in the vanilla
kernel. Andi is totally right here. We should be compatible
with what people actually used, which were the external cryptoloop
patches.
Nobody, and I mean nobody, has a cryptoloop based upon the IV
selection done in vanilla kernels.
On Fri, Jun 20, 2003 at 11:14:14AM -0700, David S. Miller wrote:
> On Fri, 2003-06-20 at 10:56, Andrew Morton wrote:
> > Andi Kleen <[email protected]> wrote:
> > >
> > > > So go for it. Fix it before 2.6.x is out and we're stuck with this crap
> > > > again.
> > >
> > > This will break existing crypto loop installations, making
> > > the existing encrypted image unreadable.
> >
> > I think we should just live with that breakage Andi. You're suggesting
> > that we retain compatibility with something which was never merged into the
> > kernel. That is asking too much.
>
> There was effectively no cryptoloop support in the vanilla
> kernel. Andi is totally right here. We should be compatible
> with what people actually used, which were the external cryptoloop
> patches.
>
> Nobody, and I mean nobody, has a cryptoloop based upon the IV
> selection done in vanilla kernels.
Ha David - you repeat what Clemens was saying and Andi disputed.
Andries
[I watch what is happening with interest - have delayed util-linux 2.12
in the hope of being able to come with something that works out of the
box together with a sufficiently recent kernel. A handful of loop
patches are needed. I hope they will be applied and documented one
by one.]
Fruhwirth Clemens <[email protected]> writes:
> On Fri, Jun 20, 2003 at 12:35:38PM +0200, J?rn Engel wrote:
[...]
> > If we can avoid the pain completely, use that better fix instead,
> > even if it isn't ready before 2.7, and ignore the problem until
> > then.
> No please, I don't wanna patch my kernel for another 2
> years. Andrew Morton is right when he puts this issue on his
> must-fix list.
FWIW, I've been patching my kernels for who knows how long now with this
fix. And I know other people who have been doing the same.
Clemens is right, it's really needed.
--J.
On Fri, 20 Jun 2003, Andi Kleen wrote:
> On Fri, Jun 20, 2003 at 12:14:52PM +0200, Fruhwirth Clemens wrote:
> > There is no cryptoloop installation which is affected by this. Read my mail
> > properly. Every cryptoloop setup out there uses loop-AES or kerneli's
> > patch-int. And both fixed this issue a _long_ time ago. (Have a look at
>
> That's completely wrong. I know of several independent implementation
> and installations.
Could you point to these implementations?
>
> > Again: _no_ userbase is affected by this change. Every userbase which
> > could have ever been affected has done the fix for itself.
>
> That's also incorrect.
I think the point is that if moving to another device will really break
data, then this is a good time to fix the problem. Breaking things is
allowed, look at modules.
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.