Re: Generalized infrastructure for public key algorithms

2004-11-10 Thread Nils Larsch
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

2004-11-10 Thread Victor B. Wagner
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

2004-11-10 Thread Nils Larsch
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

2004-11-10 Thread Reginaldo de Oliveira Santos
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)

2004-11-10 Thread Andy Polyakov
| 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

2004-11-10 Thread Stephen Henson via RT

[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]

2004-11-10 Thread Stephen Henson via RT

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.

2004-11-10 Thread Stephen Henson via RT

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]

2004-11-10 Thread via RT

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]