On 01/15/2011 06:26 PM, Murray S. Kucherawy wrote: >> -----Original Message----- From: Nikos Mavrogiannopoulos >> [mailto:[email protected]] On Behalf Of Nikos >> Mavrogiannopoulos Sent: Saturday, January 15, 2011 5:13 AM To: >> Murray S. Kucherawy Cc: [email protected] 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 _______________________________________________ Help-gnutls mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-gnutls
