linux-kernel - Re: [PATCH resend][CRYPTO]: RSA algorithm patch

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <a781481a0704120235q34d047c8q350b0ed29cde9f0f@mail.gmail.com>
Date:	Thu, 12 Apr 2007 15:05:39 +0530
From:	"Satyam Sharma" <satyam.sharma@...il.com>
To:	"Tasos Parisinos" <t.parisinos@...ensis.com>
Cc:	"Indan Zupancic" <indan@....nu>,
	"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

Hello,

> I understand and i agree, thing is that i dont decide about which parts are given GPL.
> While the RSA module is given standalone, it can be still used by others to develop
> their own signing and authenticating mechanisms. For example some will decide to do
> hashing of code with md5 while others with sha1 and some will do padding compliant
> with pkcs1 other will implement other schemas e.t.c. I want to say although this is not
> really ready to be used for binary signing, it has the advantage to provide basic functionality
> and freedom to other developers to implement their own schemas.

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.

I do have some comments on the submitted patch, though:

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 shouldn't be too difficult for you to add, and
you _can_ still allow the user to choose the appropriate padding
scheme by taking it as an argument to the encrypt / decrypt API
functions (some possibilities I can think of are PKCS#1 v1.5 padding,
v2.0 i.e. OAEP padding, or null padding).

2. Of course, you can forget about what digest was used to compute the
plaintext input to RSA. We don't really care, as RSA should never be
used to operate on multiple blocks anyway and no real-world hybrid
cryptosystem uses it in such a way either. (RSA could be thought of as
a block cipher of block size == modulus size)

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.

4. Anything in crypto/ belongs to the CryptoAPI. You definitely need
to integrate with it.
-
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/