Re: Announcing crypto suspend

From: Pavel Machek
Date: Mon Mar 20 2006 - 17:17:02 EST


On Út 21-03-06 00:05:27, Alon Bar-Lev wrote:
> Pavel Machek wrote:
> > Of course, agreed. Encrypting filesystem is stupid thing from
> > data-recovery standpoint; and I care about my data; it is also hard to
> > backup. For some uses it is of course neccessary, but it has lots of
> > disadvantages, too.
>
> Pavel, you keep doing the same basic mistake...
> Understand your client!
>
> Suspend is a feature that is most used by the mobile community.
> Disk encryption is also common for most of this community.
> Putting them to work together should be your interest...
> Calling your clients stupid is not wise!

Are you trying to flame me or is it that you can't understand english?

I never claimed my users are stupid. Read that sentence again.

> > Encrypted swsusp has basically no disadvantages.
> >
> > [I believe we should encrypt swap with random key generated on boot by
> > default. That should be also very cheap, and has no real
> > disadvantages].
>
> Well... Good thinking... But how do you plan to encrypt the
> swap? There are about 1000 ways to do this...

Yep, but one good enough way is ... well ... enough.

> Jari Ruusu had written the loop-aes which was not merged...
> >From a similar reason suspend2 was rejected by you.

suspend2 was never submitted in the first place.

> I hope you don't think that file-system encryption should be
> implemented in user mode too...

Don't put words into my mouths.

> The dm-crypt is weak... So we left with specific encryption
> implementation of swsusp... And now you offer a specific
> encryption for swap as well... Why not realize that there
> should be one encryption solution for block devices in kernel?

Why not working on that solution instead of flaming me? Last time I
seen, it was not quite easy to work with Jari.
Pavel
--
Picture of sleeping (Linux) penguin wanted...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/