From: Andries.Brouwer@cwi.nl
To: Andries.Brouwer@cwi.nl, sluskyb@paranoiacs.org
Cc: fvw@var.cx, linux-crypto@nl.linux.org, linux-kernel@vger.kernel.org
Subject: Re: 2.6.0-test2+Util-linux/cryptoapi
Date: Fri, 1 Aug 2003 23:00:53 +0200 (MEST) [thread overview]
Message-ID: <UTC200308012100.h71L0ri01916.aeb@smtp.cwi.nl> (raw)
From: Ben Slusky <sluskyb@paranoiacs.org>
> The patches I got were maximal, too much junk.
> So I went for a minimal version instead.
>
> It is usable (when the kernel part is stable, which it isn't today)
> but mount/losetup may well acquire a few options before it is
> conveniently usable.
Can we discuss those options now? I find the latest losetup to be
completely unusable, tho' I appreciate the effort that's gone into it
so far.
Firstly, are the other key size choices (128-bit, 192-bit) gone for
good? If so then I'll need to redo this entire hard disk (which currently
uses 128-bit AES) before I can test 2.6 on my laptop.
We need some discussion - there is no hurry.
Consider:
Crypto users are a small minority. On the other hand, every Linux user
needs mount. Also in emergency situations. Possibly from a rescue floppy.
Consider:
mount is suid root.
Both reasons imply that it is undesirable to add a lot of messy code
to mount, quite apart from maintainability.
If the messy code is in an external program of which the path name
is given as a -o option, then the correctness of the external program
is the invokers responsibility, and it doesnt take space on the rescue
floppies of non crypto users.
Consider:
Most people want to invoke losetup from mount. But we just concluded
that it is desirable to try and prevent bloating mount. Yes, it is
full of garbage already, but that is no reason to add even more.
You want key size choices. OK. I don't like to add another option
to mount. Probably all encryption stuff can be part of the -o encryption=
option. How is stuff coded? Well, everybody can invent some suitable
syntax. The one I like best wins. Proposals complete with (nice, readable)
code get bonus points.
Secondly, there's the issue of passphrase hashing. I agree with the
decision to cut it out of losetup, but where do we put it now? Andries
has suggested an external program, but this isn't as simple as it sounds.
To get this working would require a new way of reading the passphrase,
since the hashed passphrase might contain a newline, or a null. Maybe
change the semantics of the -p option, so that:
losetup -e aes /dev/loop/10 /home/sluskyb/testloop
will work when I give it the passphrase "foobar", but also
pwhash -h sha1 | losetup -e aes -k 128 -p 0 /dev/loop/0 \
/dev/discs/disc0/part3
will read exactly 16 bytes of (probably) non-printable chars and use
that as the key.
Sounds entirely reasonable. This is good for doing things "by hand".
But people also want to have crypto mounts described in /etc/fstab.
The option column there should contain all information needed to do
the losetup and mount.
I would be most happy if people on crypto lists would discuss details.
I do not think this belongs on linux-kernel.
Andries
[I see that this is cc-ed to linux-crypto@nl.linux.org - maybe that
is an appropriate list.]
next reply other threads:[~2003-08-01 21:01 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-08-01 21:00 Andries.Brouwer [this message]
-- strict thread matches above, loose matches on Subject: below --
2003-08-13 16:42 2.6.0-test2+Util-linux/cryptoapi Andries.Brouwer
2003-07-31 9:41 2.6.0-test2+Util-linux/cryptoapi Andries.Brouwer
2003-08-01 18:45 ` 2.6.0-test2+Util-linux/cryptoapi Ben Slusky
2003-08-13 14:42 ` 2.6.0-test2+Util-linux/cryptoapi Bill Davidsen
2003-07-31 3:45 2.6.0-test2+Util-linux/cryptoapi Frank v Waveren
2003-07-31 4:39 ` 2.6.0-test2+Util-linux/cryptoapi James Morris
2003-07-31 5:04 ` 2.6.0-test2+Util-linux/cryptoapi Frank v Waveren
2003-07-31 5:20 ` 2.6.0-test2+Util-linux/cryptoapi James Morris
2003-07-31 16:37 ` 2.6.0-test2+Util-linux/cryptoapi Frank v Waveren
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=UTC200308012100.h71L0ri01916.aeb@smtp.cwi.nl \
--to=andries.brouwer@cwi.nl \
--cc=fvw@var.cx \
--cc=linux-crypto@nl.linux.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sluskyb@paranoiacs.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
all inboxes | Powered by JetHome®