Herbert Valerio Riedel <hvr@xxxxxxxxxx> wrote:
>I've released cryptoapi-2.4.7.0 right now;
>you can download the source tarball from the projects' file section on
>sourceforge;
Great! I now have two notebook computers running cryptoloop
AES root partitions using cryptoapi-2.4.7.0 with the initial value
patch. (Yes, I am prepared to decrypt and reencrypt if the underlying
cryptoloop format changes and reinstall if the power goes out during
that operation.) It feels like a slight hardware downgrade when there
is a lot of disk activity, and is unnoticible at all other times.
Psychologically, though, I have a substantial feeling of relief at
having my data encrypted.
Your new release does just about everything I want, and is
organized in a very convenient way. I believe this arrangement will
make encrypted loopback devices much more widely used. Thank you so
much for your work on it.
Here are four minor bits of feedback to your excellent work:
1. The only bug that I have found so far is very minor: for some
unknown reason, the automatic loading of cipher modules by name seems
to happen too late for the cipher to be found. I have not yet debugged
this. Here is an example of what I am talking about:
# losetup -e aes /dev/loop/5 /tmp/junk
The cipher does not exist, or a cipher module needs to be loaded into the kernel
ioctl: LOOP_SET_STATUS: Invalid argument
# losetup -e aes /dev/loop/5 /tmp/junk
Available keysizes (bits): 128 192 256
Keysize: 256
Password :
#
2. The util-linux patch could use some cleanup, which I
will attend to if nobody beats me to it. In particular:
a. The additional "old style" numeric cipher codes
that the patch add to lomount.c are not supported
by either cryptoapi-2.4.7.0 or any of Linus's kernels,
so they should be deleted. Right? This is what confused
me before into thinking that the current cryptoapi
did not allow selection of ciphers by name.
b. I have added a system("modprobe cryptoloop") at a point
in lomount.c, which is the other piece of module loading
that is necessary to make everything work without the
user ever having to know that any of this is implemented
in a loadable module. Here is the simple patch:
--- util-linux/mount/lomount.c~ Tue Aug 14 02:47:26 2001
+++ util-linux/mount/lomount.c Tue Aug 14 22:07:54 2001
@@ -344,6 +344,7 @@
again:
set_loop_passwd(&loopinfo, pfd, keysz, encryption, fd, ffd);
+ system("modprobe -s -k cryptoloop");
if (ioctl (fd, LOOP_SET_STATUS, &loopinfo) < 0) {
/* Try again with old-style LO_CRYPT_XX if
new-style LO_CRYPT_CRYPTOAPI ioctl didn't work */
3. I have made a small cleanup to shrink the module
autoloading code in cryptoapi/api/cryptoapi.c by six lines. (The bug
I described in item #1 is the same with or without this patch.)
Here is the patch:
--- cryptoapi/api/cryptoapi.c.orig Tue Aug 14 23:28:48 2001
+++ cryptoapi/api/cryptoapi.c Tue Aug 14 23:31:59 2001
@@ -115,16 +115,19 @@
struct list_head *tmp;
struct transform_group *tg;
#ifdef CONFIG_KMOD
- int mod_try = 0;
char module_name[200];
char *p;
-retry:
#endif
if (tgroup >= MAX_TRANSFORM)
return NULL;
tg = &transforms[tgroup];
+#ifdef CONFIG_KMOD
+ sprintf(module_name, "%s-%s-", tg->tg_name, name);
+retry:
+#endif
+
read_lock(&tg->tg_lock);
for (tmp = tg->tg_head->next; tmp != tg->tg_head; tmp = tmp->next) {
struct transform_implementation *t;
@@ -138,13 +141,6 @@
}
read_unlock(&tg->tg_lock);
#ifdef CONFIG_KMOD
- if (mod_try == 0) {
- mod_try = 1;
- sprintf(module_name, "%s-%s", tg->tg_name, name);
- printk(KERN_DEBUG "cryptoapi: trying %s\n", module_name);
- request_module(module_name);
- goto retry;
- }
/* We try loading more and more general modules in succession.
* For example, if the module_name initially is set to
* "cipher-blowfish-cbc", we first try a module called
4. It would help maximize distribution of this software, if,
at some point, it were divided into separate packages to accomodate
legal and distribution policy distinctions. For example, cryptoapi
without the ciphers may be legal to import into countries where the
ciphers of any serious key length require further permission from the
government, or it may just simplify import/export paperwork. So, that
part would probably be adopted into even the tamest distributions if
it were separate. Among the ciphers, there is also a distinction
between countries where the idea cipher patent is legal and where it
is not. So, distributing the idea cipher separately would help
distributions that want to include "official" sources, but for legal
or product definition reasons do not want to distribute software
covered by the idea software patent.
Adam J. Richter __ ______________ 4880 Stevens Creek Blvd, Suite 104
adam@xxxxxxxxxxxxx \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United States of America
fax +1 408 261-6631 "Free Software For The Rest Of Us."
Linux-crypto: cryptography in and on the Linux system
Archive: http://mail.nl.linux.org/linux-crypto/
