Re: I-patch problem statement (update)

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

 



[stripped down CC list]

On Fri, 7 Sep 2001, Jari Ruusu wrote:
>> So instead of writing cipher-specific code all over the place, wouldn't it be
>> better to have some kind of crypto-VFS ?
> If the API provided pointers to low-level functions, it might be usable
> for all sorts of use, and be fast too. Something like this:
>
>     encrypt_function1 = crypto_get_ecrypt_function("aes", 128, 128);
>     encrypt_function2 = crypto_get_ecrypt_function("fish2", 128, 128);
>     do {
>         (*encrypt_function1)(ctx1, from, to);
>         [snip]
>         (*encrypt_function2)(ctx2, to, to);
>         [snip]
>         if(current->need_resched) schedule();
>     } while(--x);

if you look close enough, the cryptoapi already provides you with pointers
to low-level encryption functions; and it provides also pointers to
possibly optimized versions of the common ECB and CBC schemes... but keep
in mind, the the cryptoapi is not yet finished completely, some features
need a bit of polishing...

anyway, as I notice you propose a function like
crypto_get_ecrypt_function(), which implies that you seem to promote a
identification of cipher algos by string, and the use of a cipher
context... doesn't sound much different than what the crypto api does :-)

I'm trying to bring the crypto API closer to what might be convenient for
programmers; that's why some months ago I tried to gather some
wishes/requirements for a re-design (if needed at all)...

> =======================================

> When Alexander Kjeldaas was maintaining kerneli patch, he said "no" to my
> enhancements. HVR has largely ignored what I send him, so I don't expect him
> to act any different now.
you haven't send me any patches/enhancements as far as I know; and the
criticism you sent me about the cryptoapi hasn't been ignored;
I've fixed most of the problems you mentioned in the past;

ok, I ignored actually one thing; namely your request/recommendation to
let cryptoapi die...

> HVR is free to merge the fixes from loop-AES if he so wishes.
thanks :-)

> Marc, as long as you and rest of kerneli/crypto-api clan don't even admit
> that loop-AES exists, I reserve the right to "advertise" loop-AES.
I didn't know anyone here would ignore the existence of loop-AES...
actually judging from the recent mailing list traffic the opposite seems
to be the case ;-)

btw, I've never told anyone not to use your patch, nor that it was crap or
anything like that... on the contrary, there's even a link on
http://cryptoapi.sourceforge.net/ linking to your project...

> =======================================

> What? Are you asking me NOT to make loop bugs public?
he surely is not... maybe he's just trying to tell you not print t-shirts
having the bugs listed and running around with them... ;-)

regards,
-- 
Herbert Valerio Riedel       /    Phone: (EUROPE) +43-1-58801-18840
Email: hvr@xxxxxxxxxx       /    Finger hvr@xxxxxxx for GnuPG Public Key
GnuPG Key Fingerprint: 7BB9 2D6C D485 CE64 4748  5F65 4981 E064 883F 4142


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