Re: I-patch problem statement

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Jul 10, 2001 at 04:06:47PM +0200, Herbert Valerio Riedel wrote:
> *) providing a general (kernel space) service for ciphers (block and
>    stream), digests and closely related cryptographic algorithms.
 
 *) Provide them all in-place or provide at least in-place
    _variants_ of the ciphers
 
> *) dynamic selection/loading of ciphers by strings (enums require
>    recompilation when a new cipher is added and are less unique, string
>    based identification may need a few more bytes for storage and logic, but it
>    pays off in terms of flexibility); fits well with /proc interface
 
Good idea. Since recompiling user space for providing new drivers
is a clear lack of flexibility in every kind of user<->kernel
space interfaces. 

This is a design BUG to be fixed, no "feature" to be considered!

> *) support for algos implemented in hardware (the actual API has already
>    provisions for atomic and non-atomic encryption functions, and sw vs.
>    hw based implementations)

Or support for (crypto) co-processors. I'm building an API for
DSPs attached to hosts at the moment and crypto is one of our
possible applications. Looking forward to integreate them.

> *) syscalls to allow user space to encrypt data by cryptoapi (n.b. is
>    surely not efficient, but rather meant for the case, where the user
>    space wants to make use of hardware implementation, or maybe to test
>    the ciphers)

Or another idea: Have the ciphers available for compilation into
user space tools without any change. Or at least have an
established library using these modules without any lack of
speed. After all, they are just normal ELF objects ;-)

> which other subsystems can benefit from this:
> 
> *) encrypted network encapsulation (see cipe and freeswan)
> 
> *) encrypting loop filter (that's the only known use of the cryptoapi as
>    of now)
> 
> *) filesystems with integrated encryption support (CFS perhaps?)
> 
> *) swapspace encryption, or for the paranoid ones, encrypting (part of
> the) RAM :)

This all would be easier to implement with in-place encryption,
a flag stating, that this page is encrypted and a special
mapping handling this.

Regards

Ingo Oeser
-- 
Use ReiserFS to get a faster fsck and Ext2 to fsck slowly and gently.

Linux-crypto:  cryptography in and on the Linux system
Archive:       http://mail.nl.linux.org/linux-crypto/


[Index of Archives]     [Kernel]     [Linux Crypto]     [Gnu Crypto]     [Gnu Classpath]     [Netfilter]     [Bugtraq]
  Powered by Linux