SHA256 support for ssldump
Hello, Anyone implemented SHA256 for ssldump. I need this for my current project, finding if anyone has done it. Can you please share the patch, if it is already there. Thanks -Raja __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Decrypt fail with rc4_40_md5
I am using ssldump to decrypt the traffic enrypted with cipher rc4_40_md5. I see error with RSA_private_decrypt() function returning key length != 48. What could be there reason? Any help is appreciated. Thanks -Raja __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #2070] wrong cast
There is a wrong cast in engines/ccgost/gost_crypt.c, line 374: gost_destroy((gost_ctx *)ctx-cipher_data); Must be: gost_destroy(((struct ossl_gost_cipher_ctx *)ctx-cipher_data)-cctx); Regards __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: What does cache field in X509_STORE struct do?
On 2009.10.12 at 19:00:30 +0200, Dr. Stephen Henson wrote: Well we are in the middle of a beta relase cycle so making incompatible changes and/or major new functionality isn't an option. Is this (#2) a major new functionality, given that cache field in X509_CTX is already here and applications rely on it? Handling multi-megabyte CRLs is problematical in any cases. OpenSSL typically trebles the size of them at least when storing in memory for example. Servers which use fork() and are not multithreaded will suffer big perormance hits reloading such CRLs. This is why I suggest this feature be controllable using cache field of X509_STORE. Application writer can than decide what is worse for him - performance hit from reloading of CRLs or interrupt of service, required when reload of server needed each time CRL is issued. Documentation I think should really concentrate on the verification mechanism and X509_STORE_CTX. X509_STORE is badly broken and was supposed to have been replaced long ago but that hasn't happened for various reasongs. Documentation should concentrate on how to do the right thing. For most purposes the right thing is to point OpenSSL to the trusted store directory/file, set neccessary X509_V_FLAGs and let it care about the rest. With current API typical application writer never sees X509_STORE_CTX. 1. SSL_CTX allows him to get pointer to X509_STORE, not X509_STORE_CTX in order to set flags or may be cache field. Locations, callbacks and such is set using SSL_CTX API. 2. PKCS7_verify and CMS_verify receive X509_STORE, not X509_STORE_CTX. These two cases cover about 99% of use of the trusted certificate store in the applications. Rest would be probably attempts to implement application-specific lookup method, say store trusted certificates and CRLs in the SQL database. Only application where I myself had to create X509_STORE_CTX in my code was PKI Client application which handles certificates and CRLs received from CA and put it into the right place (doing some checks). There I have to use X509_STORE_CTX to manually check certificates and manually lookup CRLs (because there is no CRL validation function analougue to X509_verify_cert). I think that describing life cycle of CA certificates and CRLs is much more imporaint than details of X509_STORE_CTX API. Although details of verification process are, of course, important. But this process is already documented in the verify(1) man page. Only reference to this page can be made in the X509_verify_cert(3) man page. Some flags can be described just as reference to corresponding verify(1) option. But some flags, such as X509_V_FLAG_USE_CHECK_TIME do not have corresponding command line option in the verify command,. And some (such as X509_V_FLAG_CB_ISSUER_CHECK and X509_V_FLAG_NOTIFY_POLICY) have quite different semantic on API level than on command-line level. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: What does cache field in X509_STORE struct do?
On Mon, Oct 12, 2009, Victor B. Wagner wrote: 2. Make X509_LOOKUP_hash_dir lookup method honour cache field in the X509_STORE structure. (I think that it is better to make this field a bit mask and interpret constants X509_LU_CERT and X509_LU_CRL as bit flags, but it would conflict with X509_LU_PKEY constant, which seems to be unused anyway. But for first time handle this field as boolean flag is better than nothing) Ah I just remembered something about how this works which makes disabling caching more complex. The X509_LOOKUP API retrieves one matching object: that's a limitation of the API. It however populates the cache with all matching objects. The API limitation can be worked around by examining the cache after a lookup. If you disable the cache without having something equivalent to retrieve multiple matching objects you can stop verificaion working properly in some cases, for example: 1. CRLs with only partial scope (deltas and partitioned ones). 2. Certificates with different AKID but same subject names. 3. Historical checks on chains using certificates and/or CRLs that are not current. Admittedly #3 isn't likely to be used much but in the case of #1 and #2 some paths will just fail to verify. We'd at least need to document that: in many cases such features wont be used so it wont matter. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: What does cache field in X509_STORE struct do?
On Tue, Oct 13, 2009, Victor B. Wagner wrote: On 2009.10.12 at 19:00:30 +0200, Dr. Stephen Henson wrote: Well we are in the middle of a beta relase cycle so making incompatible changes and/or major new functionality isn't an option. Is this (#2) a major new functionality, given that cache field in X509_CTX is already here and applications rely on it? If it breaks existing applications yes, if it is a bugfix no. I think in this case it is arguably fixing something which is broken so it could come under that. Handling multi-megabyte CRLs is problematical in any cases. OpenSSL typically trebles the size of them at least when storing in memory for example. Servers which use fork() and are not multithreaded will suffer big perormance hits reloading such CRLs. This is why I suggest this feature be controllable using cache field of X509_STORE. Application writer can than decide what is worse for him - performance hit from reloading of CRLs or interrupt of service, required when reload of server needed each time CRL is issued. I'd suggest using a bitfield in this case but you need rather more flags than just each type of object. For example some application which need to verify certificates at times in the past might want to keep expired objects around. Since cache is unused it could (for example) use (1 X509_LU_WHATEVER) for flags which avoids clashes with X509_LU_PKEY, though as you note that is currently unused. Documentation I think should really concentrate on the verification mechanism and X509_STORE_CTX. X509_STORE is badly broken and was supposed to have been replaced long ago but that hasn't happened for various reasongs. Documentation should concentrate on how to do the right thing. For most purposes the right thing is to point OpenSSL to the trusted store directory/file, set neccessary X509_V_FLAGs and let it care about the rest. With current API typical application writer never sees X509_STORE_CTX. 1. SSL_CTX allows him to get pointer to X509_STORE, not X509_STORE_CTX in order to set flags or may be cache field. Locations, callbacks and such is set using SSL_CTX API. 2. PKCS7_verify and CMS_verify receive X509_STORE, not X509_STORE_CTX. These two cases cover about 99% of use of the trusted certificate store in the applications. Rest would be probably attempts to implement application-specific lookup method, say store trusted certificates and CRLs in the SQL database. Only application where I myself had to create X509_STORE_CTX in my code was PKI Client application which handles certificates and CRLs received from CA and put it into the right place (doing some checks). There I have to use X509_STORE_CTX to manually check certificates and manually lookup CRLs (because there is no CRL validation function analougue to X509_verify_cert). I think that describing life cycle of CA certificates and CRLs is much more imporaint than details of X509_STORE_CTX API. Although details of verification process are, of course, important. But this process is already documented in the verify(1) man page. Only reference to this page can be made in the X509_verify_cert(3) man page. Some flags can be described just as reference to corresponding verify(1) option. But some flags, such as X509_V_FLAG_USE_CHECK_TIME do not have corresponding command line option in the verify command,. And some (such as X509_V_FLAG_CB_ISSUER_CHECK and X509_V_FLAG_NOTIFY_POLICY) have quite different semantic on API level than on command-line level. Although applications don't use X509_STORE_CTX directly they do use it and related APIs indirectly and some understading of how these structures interact would help. In that vein we'd need to document X509_STORE_CTX, X509_verify_cert() and X509_VERIFY_PARAM (and related functions). Some of this could just copy and paste or point to some existing documentation for the verify utility. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: What does cache field in X509_STORE struct do?
On 2009.10.13 at 14:12:22 +0200, Dr. Stephen Henson wrote: On Tue, Oct 13, 2009, Victor B. Wagner wrote: On 2009.10.12 at 19:00:30 +0200, Dr. Stephen Henson wrote: Well we are in the middle of a beta relase cycle so making incompatible changes and/or major new functionality isn't an option. Is this (#2) a major new functionality, given that cache field in X509_CTX is already here and applications rely on it? If it breaks existing applications yes, if it is a bugfix no. I think in this case it is arguably fixing something which is broken so it could come under that. It shouldn't break existing applications, which do not care about cache field, because X509_STORE_new initializes it to 1 (may be change it to 0xfff for future use of bitfield just now). It would probably fix stunnel, which sets cache for CRL store to 0 and expects CRLs to be reloaded. I'd suggest using a bitfield in this case but you need rather more flags than just each type of object. For example some application which need to verify certificates at times in the past might want to keep expired objects around. So, we have at least two flags for each type of object 1 X509_LU_whaterver and X509_LU_KEEP_EXPIRED X509_LU_whatever Although applications don't use X509_STORE_CTX directly they do use it and related APIs indirectly and some understading of how these structures interact would help. Of course. In that vein we'd need to document X509_STORE_CTX, X509_verify_cert() and X509_VERIFY_PARAM (and related functions). Some of this could just copy and paste or point to some existing documentation for the verify utility. Now I'm attaching a pod file which documents parts of X509_STORE API which is needed to initialize X509_STORE for verifying PKCS7/CMS/TS_response and altering behavoir of SSL_CTX certificate validation, because I've already written it. X509_STORE_CTX, X509_VERIFY_PARAM and X509_LOOKUP_hash_dir/X509_LOOKUP_file documents would follow. =pod =head1 NAME X509_STORE_new, X509_STORE_free, X509_STORE_load_locations, X509_STORE_set_default_paths, X509_STORE_add_cert, X509_STORE_add_crl, X509_verify_cert, X509_STORE_add_lookup, X509_STORE_set_flags, X509_STORE_set_purpose, X509_STORE_set_depth, X509_STORE_set1_param X509_STORE_set_verify_cb_func, X509_STORE_set_trust - manipulate trusted certificate store =head1 SYNOPSIS #include openssl/x509_vfy.h X509_STORE *X509_STORE_new(); void X509_STORE_free(X509_STORE *store); int X509_STORE_load_locations (X509_STORE *store, const char *file, const char *dir); int X509_store_set_default_paths(X509_STORE *store); int X509_STORE_add_cert(X509_STORE *store, X509 *cert); X509_LOOKUP *X509_STORE_add_lookup(X509_STORE *store, X509_LOOKUP_METHOD *m); int X509_STORE_add_crl(X509_STORE *store, X509_CRL *crl); int X509_STORE_set1_param(X509_STORE *store, X509_VERIFY_PARAM *param); int X509_STORE_set_flags(X509_STORE *store, unsigned long flags); int X509_STORE_set_purpose(X509_STORE *store, int purpose); int X509_STORE_set_trust(X509_STORE *store, int trust); int X509_STORE_set_depth(X509_STORE *store, int depth); X509_STORE_set_verify_cb_func(X509_STORE *store, int (*verify_cb)(int ok, X509_STORE_CTX *ctx)) =head1 DESCRIPTION BX509_STORE structure holds information, neccessary for certificate verification process. This information include set of trusted CA certificates and corresponding CRLs, various flags modifying verification process and additional information such as required certificate purpose and policy. This structure can be passed to LPKCS7_verify(3)|PKCS7_verify(#) and LCMS_verify(3)|CMS_verify(3) functions. When SSL_CTX is created, it creates BX509_STORE internally. This store can be obtained using LSSL_CTX_get_cert_store(3)|SSL_CTX_get_cert_store(3) function and its behavoir modified by setting flags and other verification parameters. It is also possible to replace internally created BX509_STORE by custom one using LSSL_CTX_set_cert_store(3)|SSL_CTX_set_cert_store(#). BX509_STORE doesn't neccessary hold all trusted certificates and CRLs in itself. There is flexible mechanism of BX509_LOOKUP_METHODS which allows to implement own certificate storage, for example with relational database backend or LDAP. OpenSSL implements two simple lookup methods: LX509_LOOKUP_file(3)|X509_LOOKUP_file(3) and LX509_LOOKUP_hash_dir(3)|X509_LOOKUP_hash_dir(3). Users typically don't need to create instances of these lookup methods explicitely. They are created in the BX509_STORE_load_locations (or LSSL_CTX_load_verify_locations(3)|SSL_CTX_load_verify_locations(3)). Actual certificate verification, lookup and chain building is performed by BX509_STORE_CTX object, which is created based on BX509_STORE object. Unless application need to check certificates and CRLs by its own, it doesn't need to create BX509_STORE_CTX, it would be created internally by SSL or PKCS7/CMS API functions.
Re: What does cache field in X509_STORE struct do?
On Tue, Oct 13, 2009, Victor B. Wagner wrote: In that vein we'd need to document X509_STORE_CTX, X509_verify_cert() and X509_VERIFY_PARAM (and related functions). Some of this could just copy and paste or point to some existing documentation for the verify utility. Now I'm attaching a pod file which documents parts of X509_STORE API which is needed to initialize X509_STORE for verifying PKCS7/CMS/TS_response and altering behavoir of SSL_CTX certificate validation, because I've already written it. X509_STORE_CTX, X509_VERIFY_PARAM and X509_LOOKUP_hash_dir/X509_LOOKUP_file documents would follow. OK thanks. I'll have a look at that. I'll add some documentation for X509_VERIFY_PARAM myself when I have time (I'm more familiar with it having written the stuff). Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: What does cache field in X509_STORE struct do?
On 2009.10.13 at 14:30:50 +0200, Dr. Stephen Henson wrote:
On Mon, Oct 12, 2009, Victor B. Wagner wrote:
2. Make X509_LOOKUP_hash_dir lookup method honour cache field in the
X509_STORE structure. (I think that it is better to make this field
a bit mask and interpret constants X509_LU_CERT and X509_LU_CRL as
bit flags, but it would conflict with X509_LU_PKEY constant, which
seems to be unused anyway. But for first time handle this field as
boolean flag is better than nothing)
Ah I just remembered something about how this works which makes disabling
caching more complex.
The X509_LOOKUP API retrieves one matching object: that's a limitation of the
API. It however populates the cache with all matching objects. The API
limitation can be worked around by examining the cache after a lookup.
If you disable the cache without having something equivalent to retrieve
multiple matching objects you can stop verificaion working properly in some
cases, for example:
1. CRLs with only partial scope (deltas and partitioned ones).
2. Certificates with different AKID but same subject names.
3. Historical checks on chains using certificates and/or CRLs that are not
current.
Admittedly #3 isn't likely to be used much but in the case of #1 and #2 some
paths will just fail to verify. We'd at least need to document that: in many
cases such features wont be used so it wont matter.
This can be solved by just one-line patch
--- x509_lu.c.orig 2009-10-13 17:23:48.0 +0400
+++ x509_lu.c 2009-10-13 17:24:15.0 +0400
@@ -290,7 +290,7 @@
tmp=X509_OBJECT_retrieve_by_subject(ctx-objs,type,name);
- if (tmp == NULL || type == X509_LU_CRL)
+ if (!cache || tmp == NULL || type == X509_LU_CRL)
{
for
(i=vs-current_method;
isk_X509_LOOKUP_num(ctx-get_cert_methods);
i++)
{
This solution has drawback that it doesn't save memory used by cache,
but it would make X509_STORE repeat search in the hashed directory each
time if cache is disabled.
And it still allow examining cache for additional matches. after search
I've now noticed that three years ago you've already commited fix
that makes search for CRLs each time.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
Re: Bug in ECDSA_do_sign?
thank you, very much! Mounir IDRASSI wrote: Hi, In order to be able to sign a digest with ECDSA, the bit length of the digest value must be lesser than or equal to the bit size of field used in the elliptic curve. So, if you want to sign an SHA-256 digest, you must use an elliptic curve defined over a field with a bit size greater than 256. The sample code you modified is using the |wap-wsg-idm-ecid-wtls8 curve which is defined over a 112 bits prime field. Thus, it is normal that ECDSA_do_sign fail because the input size (256 bit) is greater than 112. You have two possible solutions here: either use another curve with a bigger field (like ||secp256k1 or ||secp384r1) or truncate the digest value to be lesser than or equal to 14 bytes (equivalent to 112 bits) Cheers, -- Mounir IDRASSI IDRIX http://www.idrix.fr | Kirk81 wrote: Actually I'm looking for the EVP interface and I found out that 'The EVP interface should almost always be used in preference to the low level interfaces. This is because the code then becomes transparent to the algorithm used and much more flexible'. It might be true but... ...I would like to know, how can I use the low level functions for the example that I posted?! What am I missing? Anyone can help me? Dr. Stephen Henson wrote: On Fri, Oct 09, 2009, Kirk81 wrote: Hello, I found your example of ECDSA_do_sign/verify very uselful. Now I'm trying to modify the code and I would like to use an SHA-256's message digest in your sign function. Something like: unsigned char obuf[32]; SHA-256(data, len, obuf); // now, in obuf there's the message digest (calculated using the SHA-256 function). but I have an error in the ECDSA_do_sign function when I pass the message digest in this way: sig = ECDSA_do_sign(obuf, 32, pkey); what's wrong? Problably I'm missing the conversion between data types: I mean, something used to convert the output of the SHA to an integer. In this case: which function should I use and how? I'd suggest you try OpenSSL 1.0.0 and the EVP interface instead. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org -- View this message in context: http://www.nabble.com/Bug-in-ECDSA_do_sign--tp1071562p25869174.html Sent from the OpenSSL - Dev mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Bug in ECDSA_do_sign?
Dr. Stephen Henson st...@openssl.org writes: [...] I'd suggest you try OpenSSL 1.0.0 and the EVP interface instead. Wouldn't it make sense for the truncation to be done in ECDSA_do_sign(), as it is in dsa_do_sign()? For the OP's question surely using the EVP interface isn't possible, is it? AFAI for EVP one needs an EVP_MD, and there's no appropriate EVP_MD for ECDSA and SHA256. (Indeed, if one believes the manpages there's no EVP_MD at all for ECDSA, but presumably now that EVP_sha1() can be used for DSA as well as RSA, it's been extended to ECDSA too?) Or were you proposing the OP create an EVP_MD and use that---is that how one should proceed in this kind of situation? Or is the EVP_sha1() pattern to be extended, so that one specifies (For signing and verification) just the digest and the key determines the signing/verification type? I note that this fails, suggesting that (AFAIU, anyway) the correct truncation isn't being done (I presume openssl req is using the recommended way to do things): brs% ./openssl ecparam -name secp128r1 -out ecparam.pem brs% ./openssl req -newkey ec:ecparam.pem -x509 -nodes -keyout key.pem -subj /CN=foo Generating a 128 bit EC private key writing new private key to 'key.pem' - 3084462792:error:2A065065:lib(42):ECDSA_do_sign:data too large for key size:ecs_ossl.c:265: [...] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: What does cache field in X509_STORE struct do?
On Tue, Oct 13, 2009, Victor B. Wagner wrote:
--- x509_lu.c.orig 2009-10-13 17:23:48.0 +0400
+++ x509_lu.c 2009-10-13 17:24:15.0 +0400
@@ -290,7 +290,7 @@
tmp=X509_OBJECT_retrieve_by_subject(ctx-objs,type,name);
- if (tmp == NULL || type == X509_LU_CRL)
+ if (!cache || tmp == NULL || type == X509_LU_CRL)
{
for
(i=vs-current_method;
isk_X509_LOOKUP_num(ctx-get_cert_methods);
i++)
{
This solution has drawback that it doesn't save memory used by cache,
but it would make X509_STORE repeat search in the hashed directory each
time if cache is disabled.
And it still allow examining cache for additional matches. after search
I've now noticed that three years ago you've already commited fix
that makes search for CRLs each time.
There is some additional logic for CRLs though. In by_dir.c it stores the last
suffix value of a CRL so if you have CRL links:
12345678.r0
12345678.r1
12345678.r2
12345678.r3
It notes that r3 is the last CRL looked up if now a new one is added:
12345678.r4
it only looks for r4 and doesn't reload all the (potentially large) previous
CRLs. The logic is that CRLs change far more regularly than certificates.
Though in certificates the likelihood of matching hash values is far less.
Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
Re: What does cache field in X509_STORE struct do?
On 2009.10.13 at 18:20:12 +0200, Dr. Stephen Henson wrote: There is some additional logic for CRLs though. In by_dir.c it stores the last suffix value of a CRL so if you have CRL links: This logic have to be clearly documented in the X509_LOOKUP_hash_dir manual page. I'd write what I've learned from this letter, but I hope, you'll read and improve it. Because it is critically important information for utilities which update hashed directory - that new CRL should be added, rather than replace outdating ones. Of course, keeping history in the hashed directory makes some sense. It notes that r3 is the last CRL looked up if now a new one is added: 12345678.r4 it only looks for r4 and doesn't reload all the (potentially large) previous CRLs. The logic is that CRLs change far more regularly than certificates. Though in certificates the likelihood of matching hash values is far less. This is place I've not got complete understanding from the code reading. In our case we need to perform root certificate rollover each year. But I'm not sure yet, that if new root certificate would be issued with same DN (but, of course, different subjectKeyIdentifier) certificate chains would be constructed properly. Idea is that root certificate is issued with validity period of two years, but is changed year after. And client certificates are issued with validity period 1 year. So root certificate expires same day as last certificate possible signed by it is expired. Of course, it is possible to add something to DN of new root certificate, such as serialNumber or UID, and increment this field each time new certificate is issued. I also have an idea of issuing certificate for old CA key signed by new CA key, so new client which joined system after rollover have to manually install only one, current, CA certificate (manually install means - compare fingerprint with some printed document), and older certificates are verified with chain of length 2. But this is just marginal usablity improvement. So, if chain of two certificates with identical DN cannot be built, it is not a big problem. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
What can we do to push AES-NI acceleration patches into 1.0.0 and 0.9.8 branches
Hi, All, We are working on AES-NI acceleration in OpenSSL. With the help of Andy, we have pushed the AES-NI acceleration patches into OpenSSL CVS development branch. But It seems that the patches have not been merged by the 1.0.0 and/or 0.9.8 branches. So We have some questions: - Is there any rules for a patch to move from CVS development version to the stable branches (1.0.0 and/or 0.9.8)? - What can we do to help the moving occurs? Although there is no machine in market supporting AES-NI now yet. But AES-NI support will be available in the next generation of Intel platform Westmere instead of the one after that SandyBridge. And OSV such as Redhat and Novell are waiting for the AES-NI supporting in OpenSSL now. Thanks, Huang Ying __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
