Message-ID: <3785.81.207.0.53.1176390072.squirrel@secure.samage.net>
Date:	Thu, 12 Apr 2007 17:01:12 +0200 (CEST)
From:	"Indan Zupancic" <indan@....nu>
To:	"Satyam Sharma" <satyam.sharma@...il.com>
Cc:	"Tasos Parisinos" <t.parisinos@...ensis.com>,
	"Bill Davidsen" <davidsen@....com>,
	"Andi Kleen" <andi@...stfloor.org>, herbert@...dor.apana.org.au,
	linux-kernel@...r.kernel.org, randy.dunlap@...cle.com
Subject: Re: [PATCH resend][CRYPTO]: RSA algorithm patch

On Thu, April 12, 2007 16:20, Satyam Sharma wrote:
> Of course, once an infrastructure is indeed merged into the kernel, it
> better already have (or quickly develop) some users for itself. If it
> doesn't, it does end up as rot. If it does, that pretty much solves
> the maintenance problem there itself.

Yes, but currently those users are more or less hidden and working
independently.


> Getting specific to *this* particular case, I _can_ think of other
> users in the kernel that could gladly use general asymmetric crypto
> capabilities added to the cryptoapi -- encrypting file systems, module
> signing (as of now they've just implemented DSA directly for
> themselves, not through the cryptoapi) to name a few.

The potential for users is the bare minimum expected, next step is that
there are any and them agreeing on common implementations.


> Well, then *all* the users of the RSA cryptoapi code would end up
> duplicating the PKCS padding for themselves! (because if we don't care
> about padding in a "low-maintenance-bare-RSA-implementation", then we
> might as well not implement any RSA crypto at all :-) Also, padding
> schemes are careful cryptographic constructions -- much like ciphers
> themselves. Much thought has gone into PKCS#1 over the years (and it's
> later revisions). We wouldn't want users to re-invent some kind of
> insecure padding for themselves.
>
> The way I think about this is: (1) RSA without PKCS#1 makes no sense,
> and (2) PKCS#1 is *defined* only for RSA. Combine (1) and (2), and it
> makes *all* sense to encapsulate the two in just one module.
>
> Coming to padding standards, RSA has been around for ~20 years now,
> and only 3 PKCS#1 padding schemes were ever defined (at least AFAICR).
> That's not something that changes so frequently as to not implement it
> in the core RSA code itself, especially when the penalties of not
> doing so could be quite embarrassing indeed.

Very good points there, you're right.


> If RSA is slow, then optimizing it to make it fast (and thus have more
> impact on relative performance) should make *more* sense, shouldn't
> it? That MPI implementation is derived from GPG, which has been around
> for a decade now. I'd much rather prefer well-known and
> well-understood code that has been used, tested and maintained for a
> decade than some recent/unused contraption, thank you.

I prefer clear, simple code that is easily audited to be correct or at least
not cause problems, which is small enough to not add much bloat. I don't care
about "very slow" or merely "slow" code. RSA/DSA isn't used as a symmetric block
cipher, where it does make sense to optimize it to death.

>From the kernel's point of view it's all new and unused code, so it should be
judged by its quality, not by its heritage.

I know you didn't want to talk about the user versus kernel space question,
but I think it's a very important and interesting one. As you said, GPG is
there around for years and tested, why making a new implementation in the kernel?
Your argument holds for the whole as much as for parts of the infrastructure.


> Hmmm ... and again I'll excuse myself from the debate whether to
> *actually* merge MPI and asymmetric crypto capabilities into the
> mainline tree or not -- it's all about whether the potential users
> named earlier really want to be able to do all that stuff in-kernel or
> wouldn't mind writing userspace components for it.

And whether they can agree on a common implementation. If they all just want to do
their own thing, and not combine resources, then it doesn't make any sense to merge
anything at all, as it would be ignored anyway.

As for the userspace issue, I get the impression that they didn't consider it very
well, ignoring things like initramfs versus main filesystem and so on. It's also a
gradual thing, some things can be done best in the kernel, and others in user space.
Another alternative is to push it up into the boot loader. ;-)

Greetings,

Indan


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists