2.6.0-test2+Util-linux/cryptoapi
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?
Signature · 3 lines
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/[email protected] 7BD9 09C0 3AC1 6DF2
Quoted 2 lines · Frank v Waveren
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.
Quoted 3 lines
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).
Quoted 3 lines
Lastly: Why the move from a
/proc/cryptodirectory containing files for all the algorithms to one monolithic/proc/cryptofile? 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
Signature · 2 lines
James Morris <[email protected]>
Quoted 4 lines · James Morris
Quoted 2 lines
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)
Quoted 5 lines
Quoted 3 lines
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?
Quoted 4 lines
Quoted 3 lines
Lastly: Why the move from a
/proc/cryptodirectory containing files for all the algorithms to one monolithic/proc/cryptofile? 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?
Signature · 3 lines
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/[email protected] 7BD9 09C0 3AC1 6DF2
Quoted 2 lines · Frank v Waveren
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.
Quoted 7 lines
Quoted 5 lines
Quoted 4 lines
Lastly: Why the move from a
/proc/cryptodirectory containing files for all the algorithms to one monolithic/proc/cryptofile? 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
Signature · 2 lines
James Morris <[email protected]>
Quoted 3 lines · James Morris
Quoted 2 lines
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?
Signature · 3 lines
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/[email protected] 7BD9 09C0 3AC1 6DF2