Re: Generalized infrastructure for public key algorithms
Victor B. Wagner wrote: ... the fact that EC_KEY doesn't contain a method pointer is intentional as the EC_KEY structure is/should be (ec) method indepent. Method depend information should be stored in the derived objects (i.e ECDSA_DATA and ECDH_DATA). Yes. Problem is how to pass an information from the PKCS8/X509 parsing to real implementation of method. If EVP_PKEY structure contains pointer to the method, it is easy. it does With EC_KEY there are two possibilities yet: 1. We don't need to distinguish between ECDH and ECDSA during key loading. Given the EVP_PKEY structure which contain nid of algoritm in the save_type field, we can find out appropriate ECDSA or ECDH method later. 2. We need to store algorithm specific parameters somewhere. In this case current EVP_PKEY structure is inappropriate for passing information from the PKCS8 to actual method implementation. please have a look at ec_key_meth_st in ec.h and how it's used in ecdsa_data_st (in ecdsa.h). The type specific key attributes (including a method pointer) are stored in a kind of derived structure (ecdsa_data_st). If you need more information, feel free to ask ;-) ... 3. To generalize the table of elliptic curves. In the current version of OpenSSL a set of the supported elliptic curve parameters is hardcoded in crypto/ec/ec_curve.c We propose to use the lhash table to handle elliptic curve parameters. I would prefer I linked list instead of lhash Why? lhash tables are already used in OpenSSL to store various tables. Why invent something new instead of reusing existing infrastructure? a hash table is good if you want to have a mapping nid - curve (or, as it's done in crypto/objects, some more keys (nid, sn, ln and oid) - object) in case of ec curve parameters we got quite a lot of parameters and I'm not so sure which of these should be search keys + I don't think the number of groups ,and hence the performance advantage of lhash, justifies the added complexity (note: this is just my personal opinion). what parameter do the GOST signatures curve have ? (I guess there's no non-russian description of this alg) GOST doesn't specify set of parameters. what does GOST specify ? Doesn't is specifiy certain cryptographic algs to be used for signature generation ? ... 8. Provide callbacks for packing and unpacking of a signature objects These callbacks already exist in the message digest structure. ops, I mean a function for the signatureAlgorithm field of a signature Cheers, Nils __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Generalized infrastructure for public key algorithms
On 2004.11.10 at 11:40:12 +0100, Nils Larsch wrote: please have a look at ec_key_meth_st in ec.h and how it's used in ecdsa_data_st (in ecdsa.h). The type specific key attributes (including a method pointer) are stored in a kind of derived structure (ecdsa_data_st). If you need more information, feel free to ask ;-) Thanks for the hint. But it doesn't contain engine pointer. I'm not sure that engine pointer is strictly neccessary, but it is required at least to properly initalize ECDSA and ECDH structure. Why? lhash tables are already used in OpenSSL to store various tables. Why invent something new instead of reusing existing infrastructure? a hash table is good if you want to have a mapping nid - curve (or, as it's done in crypto/objects, some more keys (nid, sn, ln and oid) - object) in case of ec curve parameters we got quite a lot of parameters and I'm not so sure which of these should be search keys + I don't think the number of groups There are EC_GROUP_new_by_nid function in ec_curve.c and it seems to be only accessor to the list of curves. Function EC_get_builtin_curves is used only for listing of supported curves in the ecparam command. Since there is simular command to list builtin ciphers and digests, lhash tables support enumeration of records. what parameter do the GOST signatures curve have ? (I guess there's no non-russian description of this alg) GOST doesn't specify set of parameters. what does GOST specify ? Doesn't is specifiy certain cryptographic algs to be used for signature generation ? Algorithm is algorithm, and parameter set is quite different beast. For instance, for DSA OpenSSL supports even generation of set of parameters. DSS standard places some requirements on this parameter set, but group of people is free to generate its own parameters. Elliptic curve generation is not supported yet by OpenSSL (it is quite complicated), but it is possible to generate these curves. 8. Provide callbacks for packing and unpacking of a signature objects These callbacks already exist in the message digest structure. ops, I mean a function for the signatureAlgorithm field of a signature May be it would be desirable. We need to investigate a bit furher. If it turns out that several signature algorithms (distinguished by OID in secret key or certificate) can be used to sign/verify same digest type, and these algorithms should have different signature packing rules, may be we would need such an abstraction. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Generalized infrastructure for public key algorithms
Victor B. Wagner wrote: ... But it doesn't contain engine pointer. I'm not sure that engine pointer is strictly neccessary, but it is required at least to properly initalize ECDSA and ECDH structure. hmm, there is an engine pointer is in ECDSA_DATA (or ECDH_DATA), but perhaps I've misunderstood something ... ... There are EC_GROUP_new_by_nid function in ec_curve.c and it seems to be only accessor to the list of curves. I was thinking about {explicit parameters} - nid (if existing) function ... what does GOST specify ? Doesn't is specifiy certain cryptographic algs to be used for signature generation ? Algorithm is algorithm, and parameter set is quite different beast. I did _not_ mean some specific parameters. I guess GOST doesn't specify a signature scheme on a arbitrary abelian group but it specifies a signature schmeme on some, for example, elliptic curve specified (char p 2 case, standard notation) by a prime number p, curve parameters a and b, a point g on the elliptic curve (generator) etc. I just wanted to know what kind of parameters are required for the GOST sig algs ... Perhaps I should read (thanks to Vadym for the link): http://cnscenter.future.co.kr/resource/ietf/ind-draft/draft-popov-cryptopro-cpalgs-01.txt Cheers, Nils __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
fragmenting code
Hi, everybody, I wanna know if somebody has succefully fragment de OpenSSL source code. For example, to isolate the rsa function, then you can use that without depending on OpenSSL instalation? thanks for all, waiting answers... -- Reginaldo Oliveira Santos Computer Science University UNESP - BRAZIL -- Mensagem enviada pelo Webmail da Faculdade de Ciências __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: RC4 optimized for AMD64 (+130% speedup)
| However! I totally disagree with the final conclusion you make. | [...] | In other words RC4 is just too special, too memory-bound and too | cache-trashing to be specific, to project its performance improvement | coefficient on other algorithms. My conclusion is not supposed to be a rational technical conclusion, it is more a personal opinion (I am working on other amd64 papers). Well, it might be just me, but if it's not about a rational conclusion, then it's not a paper, rather an essay:-) But never mind! What I wanted to point out is that if it means that you plan to submit more AMD64 code to OpenSSL, then keep in mind that it's expected to be at the very least position independent and preferably support both Win64 and Linux ABIs and assemblers (see crypto/rc4/asm/rc4-amd64.pl for an example). A. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #945] openssl smime segfault
[EMAIL PROTECTED] - Wed Sep 22 17:44:22 2004]: type of request: bug report operating system: Debian GNU/Linux 3.1 (sarge) openssl version: 0.9.7d-4 (from debian sarge) Problem description: openssl segfaults when called as follows: openssl smime -encrypt -des3 -outform DER -in foo.mail foo.cert files foo.mail and foo.cert are attached. Regards Fixed in OpenSSL 0.9.7e, ticket resolves. Sven __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #920] [Fwd: Bug#260357: libssl0.9.7: ASN1_STRING_to_UTF8 doesn't work with UTF-8 strings]
Fixed, in 0.9.7e. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #917] BUG/PATCH: apps/crl.c always returns an error when using noout-option.
Fix applied, thanks for the report. Steve. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #971]
__ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]