Re: [PATCH resend][CRYPTO]: RSA algorithm patch

[Indan Zupancic]

On Thu, April 12, 2007 11:35, Satyam Sharma wrote:
> Firstly, I'd like to steer clear of all the RSA-in-kernel-or-userspace
> / MPI-in-kernel-or-userspace arguments. True, MPI / RSA / (PKI? that
> even requires some knowledge of ASN.1 etc to parse certificates) do
> add a lot of bloat to the kernel. That said, I don't see any other
> reason to _not_ do asymmetric crypto in the kernel either. In some
> situations, that in fact simplifies the overall system by avoiding the
> use of additional userspace components / daemons to do the key
> management stuff.

Because it can all be done in userspace? Can trap all binary loading from
user-space too, though that must be done carefully, without changing the
kernel.

> 1. First, sorry, I don't think an RSA implementation not conforming to
> PKCS #1 qualifies to be called RSA at all. That is definitely a *must*
> -- why break strong crypto algorithms such as RSA by implementing them
> in insecure ways?

It's still RSA, that it's not enough to get a complete and secure crypto
system doesn't mean it isn't RSA anymore. Maybe you're right and having
RSA without the rest makes no sense. But things like padding schemes change,
the core RSA algorithm does't, so I think when adding anything that's unused
by the rest of the kernel it has more chance if it's a low maintenance bare
RSA implementation.


> 3. Please, try to re-use the MPI library from GnuPG that has already
> been ported to the kernel -- not the mainline tree, but most
> distributions such as Red Hat, Fedora, Debian, Suse(?) have maintained
> an MPI library in crypto/ for the modsign stuff for years now -- that
> would make your entire RSA module merely a set of wrappers
> (implementing PKCS#1) to the core modular exponentiation functions in
> that MPI library. It also contains implementations of optimized
> algorithms for a lot of the mathematics involved, so you have only to
> benefit from utilizing a library that has been used, maintained and
> tested for years.

Right, and that MPI implementation isn't merged. Perhaps a smaller, simpler,
not complexified by optimisations version has more chance. RSA is damn slow
anyway, so better to concentrate on other things than speed, IMHO.

That said, perhaps the different groups could concentrate on one implementation
they all agree on? That's the main advantage of having it mainline, that there's
a common place to cencentrate all effort into.

But keep in mind that it's a precaurious balance, at least that's how I see it.
Right now it's about a rather static 800 lines of code which implements some
common algorithms. Not much bloat, low maintenance, over all not much reason
to not merge it, except that it isn't used by the rest of the kernel.

If you're going to add the full kitchen sink, it might not look that appealing
anymore, and merging it will become much harder, especially as no one provided
good arguments why it can't be done in user space.

Perhaps, with that in mind, it's better to not merge the bare RSA version either,
as it might give false hope for more, because it looks like most implementations
should be done in user space (either because that's better anyway, or because of
legal reasons).

Greetings,

Indan


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