Re: I-patch problem statement (update)

[Robert Varga <nite@hq.alert.sk>]

On Thu, Sep 06, 2001 at 02:51:15PM +0300, Jari Ruusu wrote:
> Herbert Valerio Riedel wrote:
> > just to let you know, what the crypto patch code status is in at the
> > moment;
> 
> You forgot to mention the "sleeping in the make_request_fn()" bug, which is
> a real NO-NO, and can cause a panic().
>  
> > On Tue, 10 Jul 2001, Dale Amon wrote:
> > >       * kernel bloat. This is probably a non-issue. Linus
> > >         will at some point go for hooks into the kernel
> > >         for encryption support. The API for that will perhaps
> > >         be influenced by kerneli but that will not be the
> > >         final word. I do suspect it will have great influence
> > >         because everyone is using the new util-linux which
> > >         supports the new api for loopback encryption types.
> > >         In that sense we are already main stream.
> > >         (The util-linux support is mainstream debian now)
> > btw, I don't see any major kernel bloat;
> > the actual implementation does dynamic allocation of cipher modules,
> > and uses strings for identification; instead of having to use some magic
> > number IDs... (see also the mknod problem and devfs; which can be regarded
> > as kernel bloat as well... actually the whole kernel is bloat... why do we
> > use at all a virtual machine abstraction layer instead of coding directly
> > without any underlying OS?!? ;-)
> 
> Crypto-api is the bloat as it is just an unnecessary layer slowing things
> down. If someone is unable to do string to magic number conversion in
> userspace, it is no excuse to do that in kernel.

A couple questions:
Is encrypted loopback the only place in kernel where encryption can be used?
Is AES the only cipher worthy enough to be used ?
Is it better to have aes_set_key, des_set_key, and probably quite a few others
rather than:

struct crypto_ctx *ctx = crypto_newctx("aes");
crypto_setkey(ctx, "blahblah");
crypto_encrypt(ctx, dest, src, len);
?

Reason why I'm asking this is I'm working on per-file encryption support for
ext2 and I would really hate to limit its users to single encryption algorithm
(and hashing for that matter).

<flame>
Do you think of VFS as "kernel bloat" ?
</flame>

-- 
Kind regards,
Robert Varga
------------------------------------------------------------------------------
n@hq.sk                                          http://hq.sk/~nite/gpgkey.txt

PGP signature