[ 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@xxxxxxxxxx>
Linux-crypto: cryptography in and on the Linux system
Archive: http://mail.nl.linux.org/linux-crypto/
