Message-ID: <20040616002204.61941.qmail@web41101.mail.yahoo.com>
Date: Tue, 15 Jun 2004 17:22:04 -0700 (PDT)
From: tom st denis <tomstdenis@yahoo.com>
Subject: Re: RSA
To: linux-kernel@vger.kernel.org
In-Reply-To: <20040615235409.GA12186@escher.cs.wm.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2681
Lines: 64

--- "Serge E. Hallyn" <serue@us.ibm.com> wrote:
> (repeating a privately posted question for all to respond)
> 
> Is a separate generic assymetric crypto API really necessary?

It depends on how the symmetric crypto API has been implemented
[warning: I'm a kernel looking-at-code newbie so I'm just chiming in my
crypto two cents ;-)].

> The cryptoapi usage model is to do a setkey before any encrypt or
> decrypt.
> The setkey will be done with either a public or private key.  So
> there is no
> need to have a public_key_alg with separate public_encrypt and
> private_encrypt functions, as this distinction is implied at the
> setkey
> time.  So our plan was to just add another crypto_alg for rsa_1024.

In essence for a digsig module you'll require the ability to 

1.  import a PK key [from a binary packet or a cert, preferably the
former].
2.  free a PK key from memory (no need to waste dynamic resources like
bignums while not being used).
3.  ability to sign/verify/encrypt/decrypt which amounts to a exptmod
and PKCS #1 [v2.0 preferably] padding.

An API exactly mirroring the symmetric side won't really work 100%. 
For instance, symmetric operations are not likely to fail [I don't know
how error handling is performed].  Also decrypt/verify ops may fail
hard [due to lack of heap] or soft [invalid packet].

It would probably make more sense to design a simple API for PK crypto
[say support RSA/ECC/DH/DSA ;-)] then to mash the symmetric crypto API
into something compatible.

On a side note I've been contacted about my interest in making this
happen [hence my reply here].  I'm offering my public domain
LibTomCrypt [and indirectly LibTomMath] for the task.  Currently I'm
working on reducing the stack usage in LibTomCrypt's PK operations.

What I propose is we can port LibTomCrypt's [by stripping out stuff
that isn't required like symmetric crypto] PK code to a kernel module
to be released under the GPL.  Since the code is already public domain
[and I personally wrote all of the relevent code myself == no copyright
issues] there shouldn't be any problems with this.

As I said I'm not really a kernel-coder.  Actually just recently I've
moved from 2.4.26 to 2.6.6.  So mostly I'd like to see someone else
head up this task and I'd provide help porting LibTomCrypt.

Tom


__________________________________
Do you Yahoo!?
Yahoo! Mail is new and improved - Check it out!
http://promotions.yahoo.com/new_mail
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/