From: Andreas Happe <andreashappe@snikt.net>
To: linux-kernel@vger.kernel.org
Subject: Re: Announcing crypto suspend
Date: Mon, 20 Mar 2006 22:24:28 +0000 (UTC) [thread overview]
Message-ID: <slrne1uass.ffs.andreashappe@localhost.localdomain> (raw)
In-Reply-To: 441F2727.6020407@gmail.com
On 2006-03-20, Alon Bar-Lev <alon.barlev@gmail.com> 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.
>
> Suspend is a feature that is most used by the mobile community.
> Disk encryption is also common for most of this community.
And it still is a PITA backup wise. There's nothing wrong with the stuff
Pavel said.
> Calling your clients stupid is not wise!
He hasn't done that.
>> [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...
* natively in the swap implementation (easier for end-users)
* distributions should do this through initramfs and dm-crypt (as long
as this is done by distributions it is still easy for end users)
> Jari Ruusu had written the loop-aes which was not merged...
> From a similar reason suspend2 was rejected by you.
>
> I hope you don't think that file-system encryption should be
> implemented in user mode too...
I don't think that you followed the discussion or understand the reasons
behind uswsusp. If there's a (performance-wise) sane way to put
encryption (only the data translation) into userspace without copying of
buffers and too many context switches why not? But this won't happen.
> The dm-crypt is weak...
If you mean the IV schemes: as I understand it, this was mostly done to
stay compatible to cryptoloop. You are free to submit a patch that adds
another mode to dm_crypt.
> 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?
As well as swsusp-encryption is concerned this should be _userspace_ and
they can reuse libopenssl or such.
> As a result of this mess the mobile community uses external solutions.
I'm quite happy with dm_crypt + pam_mount. Works transparent and like a
charm. Don't know what your requirements are.
> Best Regards, Alon Bar-Lev.
cheers,
andreas happe
--
"With the proper course of action made so explicit, we had merely to choose
between wisdom and folly. Precisely how we chose folly in this instance is
not entirely clear." someone on penny-arcade.com
next prev parent reply other threads:[~2006-03-20 22:24 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-20 8:04 Announcing crypto suspend Pavel Machek
2006-03-20 14:13 ` Andreas Jellinghaus
2006-03-20 18:35 ` Peter Wainwright
2006-03-20 18:44 ` Pavel Machek
2006-03-20 19:26 ` Peter Wainwright
2006-03-20 18:54 ` Rafael J. Wysocki
2006-03-20 19:11 ` Alon Bar-Lev
2006-03-20 20:26 ` Rafael J. Wysocki
2006-03-20 20:35 ` Pavel Machek
2006-03-20 21:22 ` Rafael J. Wysocki
2006-03-20 21:34 ` Pavel Machek
2006-03-20 22:05 ` Alon Bar-Lev
2006-03-20 22:18 ` Pavel Machek
2006-03-20 22:24 ` Andreas Happe [this message]
2006-03-21 9:45 ` Andreas Jellinghaus
2006-03-21 20:50 ` Pavel Machek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=slrne1uass.ffs.andreashappe@localhost.localdomain \
--to=andreashappe@snikt.net \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox