RSA sign/verify and hash generation functions

[Nikos Mavrogiannopoulos]

On 01/15/2011 06:26 PM, Murray S. Kucherawy wrote:
>> -----Original Message----- From: Nikos Mavrogiannopoulos 
>> [mailto:n.mavrogiannopoulos at gmail.com] On Behalf Of Nikos 
>> Mavrogiannopoulos Sent: Saturday, January 15, 2011 5:13 AM To: 
>> Murray S. Kucherawy Cc: help-gnutls at gnu.org Subject: Re: RSA 
>> sign/verify and hash generation functions
>> 
>> btw. I'm planning into deprecating all the gnutls_x509_* functions
>>  to sign and verify data, and only leave the gnutls_privkey_ and 
>> gnutls_pubkey_ equivalent functions. That is to simplify internals 
>> and avoid having the same functions for each certificate type. Just
>> in case this change affects you.
> 
> It does.  Right now I'm using:
> 
> - gnutls_x509_privkey_init() to allocate an object - 
> gnutls_x509_privkey_import() to read in a PEM-encoded or DER-encoded
>  RSA key - gnutls_privkey_import_x509() to extract a generic private
>  key from the above - gnutls_privkey_get_pk_algorithm() just to get 
> the key size of the above - gnutls_x509_privkey_deinit() to 
> deallocate - gnutls_x509_privkey_sign_hash2() to sign

You can use gnutls_privkey_sign_hash2() instead of
gnutls_x509_privkey_sign_hash2(). There shouldn't be any side-effects.
For verification you could use gnutls_pubkey_verify_data/hash.

> As I recall, what was missing from the basic privkey interface was 
> the means to get a PEM/DER-encoded RSA key; I had to go through the 
> gnutls_x509_*() functions to do that.  What I need is a 
> gnutls_privkey_import() that can do the same, and a matching 
> gnutls_privkey_sign_hash2(), and then I can get rid of the 
> gnutls_x509_*() calls altogether.

Currently the privkey interface has only operations on keys, and does
not really need to access the key itself. That is because it is
a front-end for the x509/openpgp and pkcs11 interfaces, and the pkcs11
interface may not have access to the key. That could be because the key
is in a smart-card, that only provides operations.

You can use the gnutls_x509_ interface to import/export from a
file/buffer and then use the gnutls_privkey_ interface to import
from that and access operations. In a language like C++ it would
be easier to express that a gnutls_x509_privkey_t is also a
gnutls_privkey_t, but in C it causes that inconvenience.

> If you have a version available that has those API changes, I can 
> give it a try next week.

You can check the version in master.

regards,
Nikos