Re: 2.6.0-test2+Util-linux/cryptoapi

Re: 2.6.0-test2+Util-linux/cryptoapi

[Andries.Brouwer]

> I hope we can get the control of key length back

Maybe you didnt see earlier mail about this.

Look: half a year ago there was nothing in vanilla kernel and
util-linux, and one had to use outside patches. Today there
is some support in vanilla kernel and util-linux, but nobody
stops you from continued use of outside patches.

In case you would prefer kernel and util-linux to improve,
don't say "I want improvements", but say very precisely
what syntax you would prefer and why.
Think first about things mounted from /etc/fstab.
Implementing stuff is trivial, but after things have been
implemented they won't be changed, so it is better to do
things right at once.

Re: 2.6.0-test2+Util-linux/cryptoapi

[Bill Davidsen]

On Thu, 31 Jul 2003 Andries.Brouwer@cwi.nl wrote:

> > First of all, in util-linux 2.12 the keybits option is gone
> > I wanted to have losetup/mount hash the passphrase
> 
> 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.

I'm not sure what value of stable you want, I've been using 2.6.0-test1
(ac?) with crypto since it came out. Clearly there are a lot of things
missing before 2.6 is ready for general use, but it sure is nice to have
that filesystem protected. The crypto seems stable, as long as that's the
main thing you do with the box.

I hope we can get the control of key length back, while I doubt that
anyone who actually could break the default is going to be involved in
anything I do, I'd like to see it for future applications.

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: 2.6.0-test2+Util-linux/cryptoapi

[Andries.Brouwer]

    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.]

Re: 2.6.0-test2+Util-linux/cryptoapi

[Ben Slusky]

On Thu, 31 Jul 2003 11:41:25 +0200, Andries.Brouwer@cwi.nl wrote:
> 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.

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.

Questions? Comments? Flames?

-- 
Ben Slusky                      | A free society is a society
sluskyb@paranoiacs.org          | where it is safe to be
sluskyb@stwing.org              | unpopular.
PGP keyID ADA44B3B              |               -Adlai Stevenson

Re: 2.6.0-test2+Util-linux/cryptoapi

[Frank v Waveren]

On Thu, Jul 31, 2003 at 03:20:48PM +1000, James Morris wrote:
> > Owch. But I assume this didn't sneak in since the testing cryptoAPI
> > patches? Or have the algorithms been redone?
> I'm not sure what you mean.
I'm currently using hvr's testing cryptoAPI patches for 2.4.x, and I
have a block device encrypted with 256 bits serpent. This cannot be
correctly decrypted with linux-2.6.0-test2. Has something in the use
of serpent changed since then (or has block numbering changed again)?
Or should I go bug-hunting?

-- 
Frank v Waveren                                      Fingerprint: 21A7 C7F3
fvw@[var.cx|stack.nl|chello.nl] ICQ#10074100            1FF3 47FF 545C CB53
Public key: hkp://wwwkeys.pgp.net/fvw@var.cx            7BD9 09C0 3AC1 6DF2

Re: 2.6.0-test2+Util-linux/cryptoapi

[Andries.Brouwer]

> First of all, in util-linux 2.12 the keybits option is gone
> I wanted to have losetup/mount hash the passphrase

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.

(I do not read crypto lists, and see only a very small fraction of
what passes by on lk, so if you want to influence util-linux
an explicit cc is a good idea.)

> has the encryption setup changed again since 2.4.x with hvr's
> testing cryptoapi stuff?

cryptoloop as it went in is essentially hvr's.

Andries

Re: 2.6.0-test2+Util-linux/cryptoapi

[James Morris]

On Thu, 31 Jul 2003, Frank v Waveren wrote:

> Owch. But I assume this didn't sneak in since the testing cryptoAPI
> patches? Or have the algorithms been redone?

I'm not sure what you mean.

> 
> > > Lastly: Why the move from a /proc/crypto directory containing files
> > > for all the algorithms to one monolithic /proc/crypto file? Isn't the
> > > former a lot nicer from the userspace programmer's point of view?
> > Possibly, although it's probably too late to change now for 2.6.
> But why was it ever changed to on big file in the first place?
> 

This is a new API, so it wasn't really changed.  The single file is
simpler and less bloated from the kernel point of view.  This may change 
down the track with hardware support.



- James
-- 
James Morris
<jmorris@intercode.com.au>

Re: 2.6.0-test2+Util-linux/cryptoapi

[Frank v Waveren]

On Thu, Jul 31, 2003 at 02:39:45PM +1000, James Morris wrote:
> > Moving to the slightly more ontopic stuff for lk@vger: Is access to
> > the cryptoapi algorithms exposed to userspace yet?
> No, there is no point (apart from testing) unless the kernel API is 
> providing access to crypto hardware.
Even if we don't have the drivers yet, the sooner it's available and
in use the better, then we can always drop in hardware support later.
(Still, I'm not volunteering for either job so I won't complain, just
wondering if it had been done)

> > Thirdly, has the encryption setup changed again since 2.4.x with hvr's
> > testing cryptoapi stuff? I have a filesystem encrypted with 256 bits
> > serpent, yet it won't decrypt using 2.6.0-test2 and util-linux 2.12.
> The kerneli serpent implementation is incorrect (it's reversed, a common
> implementation problem with this algorithm).
Owch. But I assume this didn't sneak in since the testing cryptoAPI
patches? Or have the algorithms been redone?

> > Lastly: Why the move from a /proc/crypto directory containing files
> > for all the algorithms to one monolithic /proc/crypto file? Isn't the
> > former a lot nicer from the userspace programmer's point of view?
> Possibly, although it's probably too late to change now for 2.6.
But why was it ever changed to on big file in the first place?

-- 
Frank v Waveren                                      Fingerprint: 21A7 C7F3
fvw@[var.cx|stack.nl|chello.nl] ICQ#10074100            1FF3 47FF 545C CB53
Public key: hkp://wwwkeys.pgp.net/fvw@var.cx            7BD9 09C0 3AC1 6DF2

Re: 2.6.0-test2+Util-linux/cryptoapi

[James Morris]

On Thu, 31 Jul 2003, Frank v Waveren wrote:

> Moving to the slightly more ontopic stuff for lk@vger: Is access to
> the cryptoapi algorithms exposed to userspace yet?

No, there is no point (apart from testing) unless the kernel API is 
providing access to crypto hardware.


> Thirdly, has the encryption setup changed again since 2.4.x with hvr's
> testing cryptoapi stuff? I have a filesystem encrypted with 256 bits
> serpent, yet it won't decrypt using 2.6.0-test2 and util-linux 2.12.

The kerneli serpent implementation is incorrect (it's reversed, a common
implementation problem with this algorithm).

> Lastly: Why the move from a /proc/crypto directory containing files
> for all the algorithms to one monolithic /proc/crypto file? Isn't the
> former a lot nicer from the userspace programmer's point of view?

Possibly, although it's probably too late to change now for 2.6.


- James
-- 
James Morris
<jmorris@intercode.com.au>

2.6.0-test2+Util-linux/cryptoapi

[Frank v Waveren]

I was giving 2.6.0-test2 a spin, and run into a few issues with
loopback crypto:

First of all, in util-linux 2.12 the keybits option is gone, and the
number of keybits is fixed to 256 (even though some algorithms in the
kernel support more). Is this a temporary thing or a design decision?

Moving to the slightly more ontopic stuff for lk@vger: Is access to
the cryptoapi algorithms exposed to userspace yet? I wanted to have
losetup/mount hash the passphrase before passing it to the kernel, and
it seems silly to actually put a separate hashing algorithm in
util-linux when they're there in the kernel anyway.

Thirdly, has the encryption setup changed again since 2.4.x with hvr's
testing cryptoapi stuff? I have a filesystem encrypted with 256 bits
serpent, yet it won't decrypt using 2.6.0-test2 and util-linux 2.12.

Lastly: Why the move from a /proc/crypto directory containing files
for all the algorithms to one monolithic /proc/crypto file? Isn't the
former a lot nicer from the userspace programmer's point of view?


-- 
Frank v Waveren                                      Fingerprint: 21A7 C7F3
fvw@[var.cx|stack.nl|chello.nl] ICQ#10074100            1FF3 47FF 545C CB53
Public key: hkp://wwwkeys.pgp.net/fvw@var.cx            7BD9 09C0 3AC1 6DF2