Initial Vector Fix for loop.c.
A message that is not in the archive (sent off-list or not yet received): 20030620090612.GA1322@ghanima.endorphin.org.suse.lists.linux.kernel
Quoted 2 lines · Fruhwirth Clemens
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
Quoted 10 lines · Andi Kleen
Quoted 2 lines · Fruhwirth Clemens
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
Quoted 12 lines · Fruhwirth Clemens
Quoted 10 lines · Andi Kleen
Quoted 2 lines · Fruhwirth Clemens
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.
Quoted 3 lines
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.
Quoted 2 lines
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
Quoted 7 lines · Andi Kleen
Quoted 3 lines · Fruhwirth Clemens
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
Quoted 13 lines · Andi Kleen
Quoted 12 lines · Fruhwirth Clemens
Quoted 10 lines · Andi Kleen
Quoted 2 lines · Fruhwirth Clemens
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.
Quoted 6 lines
Quoted 3 lines
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
Signature · 3 lines
Fantasy is more important than knowlegde. Knowlegde is limited, while fantasy embraces the whole world. -- Albert Einstein
Quoted 4 lines
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.
Quoted 3 lines · Andi Kleen
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.
Quoted 4 lines
[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:49:53PM +0200, Andi Kleen wrote:
Comment: [1] stands for cryptoloop's CBC mode.
Quoted 6 lines
[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
Quoted 6 lines · Jörn Engel
Quoted 5 lines · Andi Kleen
Quoted 3 lines · Fruhwirth Clemens
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
Quoted 7 lines
Quoted 2 lines
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 :)
Quoted 2 lines
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
Quoted 4 lines · Fruhwirth Clemens
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.
Quoted 4 lines
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
Signature · 2 lines
Do not stop an army on its way home. -- Sun Tzu
Quoted 1 line · Fruhwirth Clemens
On Fri, Jun 20, 2003 at 12:35:38PM +0200, Jörn Engel wrote:
[...]
Quoted 6 lines
Quoted 3 lines
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.
Quoted 8 lines · Andi Kleen
Quoted 3 lines · Fruhwirth Clemens
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?
Quoted 5 lines
Quoted 3 lines
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.
Signature · 3 lines
bill davidsen <[email protected]> CTO, TMR Associates, Inc Doing interesting things with little computers since 1979.
Quoted 6 lines · Andi Kleen
Quoted 3 lines
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.
Quoted 11 lines · Andrew Morton
Quoted 6 lines · Andi Kleen
Quoted 3 lines
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.
Quoted 13 lines · David S. Miller
Quoted 11 lines · Andrew Morton
Quoted 6 lines · Andi Kleen
Quoted 3 lines
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.
Quoted 7 lines
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.]