> I have updated the patches that he referred to (from berkeley.edu)
> to work with the latest 2.0.* kernel. They are available from
> ftp://ftp.is.co.za/linux/local/kernel/crypto/
I'm afraid, you're still missing the whole point of my original post. I was
saying that the "large" loop encryption patches available on the net are
somewhat broken anyway (new ciphers should be registered at runtime, etc),
and need re-coding. They're not getting into the standard kernel anyway.
Meanwhile, loop.c in the standard kernel _does_ have some hooks for loop
encryption. These hooks are totally non-working at the moment (the DES key
passing example applies here). So, I proposed a _tiny_ patch that fixed
the hooks that are _already_ in the standard kernel so that they at least
work. My guess was that this way the patch had a small chance (and not none
at all, like the Berkeley patches) of getting into the kernel. It's a shame
that our current code in every copy of the standard kernel is totally buggy
and insecure.
> Surely CBC mode can't work across the whole loopback device anyway? It
> only applies across the whole device it would mean we couldn't random-seek,
> right?
Wrong. CBC has a nice property that can help us here: we only need to read
_one_ preceding block to be able to decrypt the next one correctly. We don't
have to read all the preceding blocks for that.
Still, reading one extra block does take a bit of extra time, so the "use
block number as IV" approach might be better.
> > Also, it seems to me that the entire loop encryption code is broken, and
> > needs re-coding to make it easy to add new ciphers, possibly via modules
> > or similar.
>
> I believe that this would mean that people can't export the kernel then,
> since I believe that encryption hooks are still illegal.
Wrong. It would in fact make the export things _easier_. The encryption
modules don't have to be supplied with the kernel. We will only have the
_support_ for such modules in the kernel.
> Ok - so you have confirmed that it works on a block basis.
>
> Doesn't this mean that we can't transfer an FS made on one platform to a
> different architecture? (eg i386 to Alpha - I believe that Alpha have
> 4k blocks - if my memory serves me)
If you mean the pages, then they're 8 Kb on Alpha by default, but this has
nothing to do with our encryption blocks.
Signed,
Solar Designer
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html