Re: I-patch problem statement (update)

[Jari Ruusu <jari.ruusu@pp.inet.fi>]

[ replying to multiple persons in same email ]

Robert Varga wrote:
> On Thu, Sep 06, 2001 at 09:36:02PM +0300, Jari Ruusu wrote:
> > Above code is AES specific (since you hardcoded the string "aes"), so yes.
> > :-)
> 
> sure :-))) same way I hardcoded the encryption key to "blahblah" ;-)))

Exactly  :-)
 
> 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);

> Yes, I know I am moving away rapidly from loopback encryption. It is a nice feature,
> but generally not really usable on multi-user machines.

Yep. Loop encryption is useful on laptops that are easily lost or stolen.

=======================================

Marc Mutz wrote:
> Jari, you will not make friends with being so bold all the time. You know,
> as an open source developer, your only reward is the respect of the fellow
> developers and the thanks of happy users. Don't sacrifice the former by
> aggeressively advertizing your patch, repeatedly stating that it is so
> superior. As a matter of fact, instead of complaining about the bugs in
> kerneli, it behoves you to provide patches to fix 'em...

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.

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

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.

=======================================

"Janusz A. Urbanowicz" wrote:
> What if tomorrow some cryptographer will publish cheap, practical attack
> on AES? This is unlikely but possible.

If that happens, loop-twofish is born.

> I'm impressed with your patch and I intent touse it but in this
> situation I'm stuck with a weak algorithm. In other crypto applications I
> can switch to always-safe and well researched 3DES. In your patch I can't do
> this.

In previous life, loop-AES used to be loop-TripleDES for years. There was
nothing wrong with that, except that is was slow. loop-TripleDES was not
publically available. I made loop-AES publically available after I swithed
the cipher from 3DES to AES.

> Change of cipher algorithm is not a 'weirdo setup requirement'.

By weirdo I meant unusual initialization and block chaining stuff.

=======================================

"IT3 Stuart B. Tener, USNR-R" wrote:
> Forgive me for being so blunt, but dare I state we are not dealing with
> kernel bloat, but in fact "ego bloat" and "arrogance bloat".

Opinions vary.

> Conversely perhaps the reason you are touting your solution so strongly is
> because you want to refocus the deficiency issues on the I-patch when in
> fact deep down you are aware it is your product which may also (in
> comparison to the I-patch, a comparison you are continuing to force people
> to make with your statements) is absent functionality the I-patch has.

What? Are you asking me NOT to make loop bugs public?

The "absent functionality" of loop-AES is unnecessary bloat that I don't
want in loop-AES. Loop-AES is small by desing, and that means less bugs and
less code to audit.

> Besides, if you were truly trying to out do people, you would have fixed
> the I-patch a while back.

I do not maintain i-patch or HVR crypto-api. I maintain loop-AES. What is
wrong with little competition? At least then people have a choice.

> While I agree one good cipher will fit most people's needs, I disagree
> that you ought to be the one to choose it.

I am not forcing anyone to use loop-AES.

> However, if in fact it is your own cognitive deficiencies (I am not saying
> it is, but "if it is") which prevent you from helping to improve the
> I-patch, or add ciphers to your software, or even write your own kernel
> patch, then in fact I humbly apologize for all I have said, absent that
> fact, I would request that you think about what I (and others) have said
> about what we are looking for.

As I said before, I do not maintain i-patch or HVR crypto-api.

Kernel patch version of loop-AES, -p option for losetup/mount, encrypted
swap were _all_ requested by loop-AES users. I added them because they were
requested and made a lot of sense.

You, Stuart, have requested me to add some shitty Winblows support, and I
have replied that I won't do that. That does not count as "cognitive
deficiency".

Regards,
Jari Ruusu <jari.ruusu@pp.inet.fi>


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