Re: [CVS] OpenSSL: openssl/ CHANGES openssl/crypto/ecdsa/ ecs_ossl.c
Dr. Stephen Henson st...@openssl.org writes: [...] +#ifdef ECDSA_POINT_MUL_NO_CONSTTIME + /* We do not want timing information to leak the length of k, +* so we compute G*k using an equivalent scalar of fixed +* bit-length. */ + + if (!BN_add(k, k, order)) goto err; + if (BN_num_bits(k) = BN_num_bits(order)) + if (!BN_add(k, k, order)) goto err; +#endif /* def(ECDSA_POINT_MUL_NO_CONSTTIME) */ + Almost certainly my misunderstanding, but isn't the sense of this wrong? That is, surely the new code should be added if we want the CONSTTIME behaviour (i.e., if NO_CONSTTIME is not defined), and we'd want that by default so it should be #ifndef rather than #ifdef? (I agree it's #ifdef in the eprint too, which increases the likelyhood that I'm just misunderstanding something.) [...] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [CVS] OpenSSL: openssl/ CHANGES openssl/crypto/ecdsa/ ecs_ossl.c
Hi , I agree with Bruce: we should default to a constant time behavior so definitely the code must use #ifndef instead of #ifdef since the patch makes the scalar a fixed bit length value. I think the paper authors got confused when they wrote the code. Cheers, -- Mounir IDRASSI IDRIX http://www.idrix.fr On 5/27/2011 4:10 PM, Bruce Stephens wrote: Dr. Stephen Hensonst...@openssl.org writes: [...] +#ifdef ECDSA_POINT_MUL_NO_CONSTTIME +/* We do not want timing information to leak the length of k, + * so we compute G*k using an equivalent scalar of fixed + * bit-length. */ + +if (!BN_add(k, k, order)) goto err; +if (BN_num_bits(k)= BN_num_bits(order)) +if (!BN_add(k, k, order)) goto err; +#endif /* def(ECDSA_POINT_MUL_NO_CONSTTIME) */ + Almost certainly my misunderstanding, but isn't the sense of this wrong? That is, surely the new code should be added if we want the CONSTTIME behaviour (i.e., if NO_CONSTTIME is not defined), and we'd want that by default so it should be #ifndef rather than #ifdef? (I agree it's #ifdef in the eprint too, which increases the likelyhood that I'm just misunderstanding something.) [...] __ 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: [CVS] OpenSSL: openssl/ CHANGES openssl/crypto/ecdsa/ ecs_ossl.c
FWIW: This isn't like RSA blinding where the impact was significant.The performance impact of this is negligible, it may as well be unconditional. Peter-owner-openssl-...@openssl.org wrote: -To: openssl-dev@openssl.orgFrom: Mounir IDRASSI mounir.idra...@idrix.netSent by: owner-openssl-...@openssl.orgDate: 05/28/2011 12:49AMSubject: Re: [CVS] OpenSSL: openssl/ CHANGES openssl/crypto/ecdsa/ ecs_ossl.cHi ,I agree with Bruce: we should default to a constant time behavior so definitely the code must use #ifndef instead of #ifdef since the patch makes the scalar a fixed bit length value.I think the paper authors got confused when they wrote the code.Cheers,--Mounir IDRASSIIDRIXhttp://www.idrix.frOn 5/27/2011 4:10 PM, Bruce Stephens wrote: "Dr. Stephen Henson"st...@openssl.org writes: [...] +#ifdef ECDSA_POINT_MUL_NO_CONSTTIME + /* We do not want timing information to leak the length of k, + * so we compute G*k using an equivalent scalar of fixed + * bit-length. */ + + if (!BN_add(k, k, order)) goto err; + if (BN_num_bits(k)= BN_num_bits(order)) + if (!BN_add(k, k, order)) goto err; +#endif /* def(ECDSA_POINT_MUL_NO_CONSTTIME) */ + Almost certainly my misunderstanding, but isn't the sense of this wrong? That is, surely the new code should be added if we want the CONSTTIME behaviour (i.e., if NO_CONSTTIME is not defined), and we'd want that by default so it should be #ifndef rather than #ifdef? (I agree it's #ifdef in the eprint too, which increases the likelyhood that I'm just misunderstanding something.) [...] __ OpenSSL Project http://www.openssl.org Development Mailing Listopenssl-dev@openssl.org Automated List Manager majord...@openssl.org__OpenSSL Project http://www.openssl.orgDevelopment Mailing Listopenssl-dev@openssl.orgAutomated 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: [CVS] OpenSSL: openssl/ CHANGES openssl/crypto/bn/ bn_mont.c openssl/c...
Hi, a couple of days ago I've reported the bug: http://rt.openssl.org/Ticket/Display.html?id=1641 It looks like that Bodo's commit (see below) has fixed the reported problem. So the bug can be closed and set to fixed. Best regards, Christian Bodo Moeller wrote: OpenSSL CVS Repository http://cvs.openssl.org/ Server: cvs.openssl.org Name: Bodo Moeller Root: /v/openssl/cvs Email: [EMAIL PROTECTED] Module: openssl Date: 27-Feb-2008 07:01:28 Branch: HEAD Handle: 2008022706012602 Modified files: openssl CHANGES openssl/crypto/bn bn_mont.c openssl/crypto/rsa rsa_eay.c Log: fix BIGNUM fl Index: openssl/crypto/bn/bn_mont.c $ cvs diff -u -r1.49 -r1.50 bn_mont.c --- openssl/crypto/bn/bn_mont.c 18 Sep 2007 16:35:28 - 1.49 +++ openssl/crypto/bn/bn_mont.c 27 Feb 2008 06:01:27 - 1.50 @@ -425,6 +425,7 @@ BIGNUM tmod; BN_ULONG buf[2]; + BN_init(tmod); tmod.d=buf; tmod.dmax=2; tmod.neg=0; @@ . __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [CVS] OpenSSL: openssl/ CHANGES openssl/apps/ s_client.c openssl/crypt...
On 2007.10.26 at 14:06:37 +0200, Dr. Stephen Henson wrote: OpenSSL CVS Repository http://cvs.openssl.org/ Modified files: openssl CHANGES openssl/appss_client.c openssl/crypto/dsa dsa_pmeth.c openssl/crypto/evp evp.h pmeth_fn.c pmeth_lib.c openssl/crypto/hmac hm_pmeth.c openssl/crypto/rsa rsa_pmeth.c openssl/crypto/x509 x509type.c openssl/engines/ccgost e_gost_err.c e_gost_err.h gost2001_keyx.c gost94_keyx.c gost_ameth.c gost_crypt.c gost_ctl.c gost_eng.c gost_lcl.h gost_md.c gost_pmeth.c openssl/ssl d1_enc.c s3_clnt.c s3_lib.c s3_srvr.c ssl.h ssl_ciph.c ssl_err.c ssl_lib.c t1_enc.c t1_lib.c openssl/utillibeay.num But where is README.gost which should have been added into engines/ccgost directory? __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [CVS] OpenSSL: openssl/ CHANGES openssl/crypto/asn1/ x_crl.c x_x509.c ...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dr. Stephen Henson schrieb: patch -p0 '@@ .' Index: openssl/CHANGES $ cvs diff -u -r1.1342 -r1.1343 CHANGES --- openssl/CHANGES 18 Jul 2006 12:36:17 - 1.1342 +++ openssl/CHANGES 24 Jul 2006 12:39:20 - 1.1343 @@ -4,6 +4,12 @@ Changes between 0.9.8b and 0.9.9 [xx XXX ] + *) New function X509_CRL_match() to check if two CRLs are identical. Normally + this would be called X509_CRL_cmp() but that name is already used by + a function that just compares CRL issuer names. Cache several CRL + extensions in X509_CRL structure and cache CRLDP in X509. + [Steve Henson] Wouldn't it be adviseable to rename the old X509_CRL_cmp() to something like X509_CRL_cmp_issuer(), define a macro for the old name and flag it as deprecated ? After some grace time the old macro is removed and after some other grace time the X509_CRL_match() becomes X509_CRL_cmp() ? Bye Goetz - -- DMCA: The greed of the few outweighs the freedom of the many -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFExRPB2iGqZUF3qPYRAraEAJ4/vg0NxJd9umLLWSCUkLN9CEIswgCeOH51 fUAstjCsgATTRx5pERQyPs4= =cMM/ -END PGP SIGNATURE- __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [CVS] OpenSSL: openssl/ CHANGES FAQ openssl/crypto/bn/ bn.h bn_blind.c...
On Fri, Jun 23, 2006 at 04:36:07PM +0100, Joe Orton wrote: Log: New functions CRYPTO_set_idptr_callback(), CRYPTO_get_idptr_callback(), CRYPTO_thread_idptr() for a 'void *' type thread ID, since the 'unsigned long' type of the existing thread ID does not always work well. To clarify this, if CRYPTO_get_idptr_callback() is used, is it unnecessary to also call CRYPTO_set_id_callback? Does C9x actually guarantee that you can take the address of errno? From C99, section 7.5: [#1] The header errno.h defines several macros, all relating to the reporting of error conditions. [#2] The macros are EDOM EILSEQ ERANGE which expand to integer constant expressions with type int, distinct positive values, and which are suitable for use in #if preprocessing directives; and errno which expands to a modifiable lvalue170) that has type int, the value of which is set to a positive error number by several library functions. It is unspecified whether errno is a macro or an identifier declared with external linkage. If a macro definition is suppressed in order to access an actual object, or a program defines an identifier with the name errno, the behavior is undefined. [...] 170The macro errno need not be the identifier of an object. It might expand to a modifiable lvalue resulting from a function call (for example, *errno()). And: 6.5.3.2 Address and indirection operators Constraints [#1] The operand of the unary operator shall be either a function designator, the result of a [] or unary * operator, or an lvalue that designates an object that is not a bit- field and is not declared with the register storage-class specifier. I believe you can take the address of errno. Kurt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [CVS] OpenSSL: openssl/ CHANGES FAQ openssl/crypto/bn/ bn.h bn_blind.c...
On Fri, Jun 23, 2006 at 06:42:10PM +0200, Kurt Roeckx wrote: On Fri, Jun 23, 2006 at 04:36:07PM +0100, Joe Orton wrote: Log: New functions CRYPTO_set_idptr_callback(), CRYPTO_get_idptr_callback(), CRYPTO_thread_idptr() for a 'void *' type thread ID, since the 'unsigned long' type of the existing thread ID does not always work well. To clarify this, if CRYPTO_get_idptr_callback() is used, is it unnecessary to also call CRYPTO_set_id_callback? Yes, exactly. Does C9x actually guarantee that you can take the address of errno? From C99, section 7.5: [...] And: 6.5.3.2 Address and indirection operators [...] I believe you can take the address of errno. Yes, that is what I too was reading from the standard. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [CVS] OpenSSL: openssl/ CHANGES openssl/apps/ progs.h s_apps.h s_socke...
Scholars might like to note two bugs turned up by this change:
Index: openssl/crypto/asn1/a_set.c
$ cvs diff -u -r1.13 -r1.14 a_set.c
--- openssl/crypto/asn1/a_set.c 5 Dec 2004 01:03:06 - 1.13
+++ openssl/crypto/asn1/a_set.c 31 Mar 2005 09:26:25 - 1.14
@@ -210,7 +211,9 @@
char *s;
if (M_ASN1_D2I_end_sequence()) break;
- if ((s=func(NULL,c.p,c.slen,c.max-c.p)) == NULL)
+ /* XXX: This was called with 4 arguments, incorrectly, it seems
+ if ((s=func(NULL,c.p,c.slen,c.max-c.p)) == NULL) */
+ if ((s=d2i(NULL,c.p,c.slen)) == NULL)
{
ASN1err(ASN1_F_D2I_ASN1_SET,ASN1_R_ERROR_PARSING_SET_ELEMENT);
asn1_add_error(*pp,(int)(c.q- *pp));
@@ .
patch -p0 '@@ .'
Index: openssl/crypto/ocsp/ocsp.h
$ cvs diff -u -r1.30 -r1.31 ocsp.h
--- openssl/crypto/ocsp/ocsp.h 17 Dec 2001 19:22:06 - 1.30
+++ openssl/crypto/ocsp/ocsp.h 31 Mar 2005 09:26:31 - 1.31
@@ -349,13 +349,9 @@
#define PEM_STRING_OCSP_REQUEST OCSP REQUEST
#define PEM_STRING_OCSP_RESPONSE OCSP RESPONSE
-#define d2i_OCSP_REQUEST_bio(bp,p) (OCSP_REQUEST*)ASN1_d2i_bio((char*(*)()) \
- OCSP_REQUEST_new,(char *(*)())d2i_OCSP_REQUEST, (bp),\
- (unsigned char **)(p))
-
-#define d2i_OCSP_RESPONSE_bio(bp,p) (OCSP_RESPONSE*)ASN1_d2i_bio((char*(*)())\
- OCSP_REQUEST_new,(char *(*)())d2i_OCSP_RESPONSE, (bp),\
- (unsigned char **)(p))
+#define d2i_OCSP_REQUEST_bio(bp,p) ASN1_d2i_bio_of(OCSP_REQUEST,OCSP_REQUEST_new,d2i_OCSP_REQUEST,bp,p)
+
+#define d2i_OCSP_RESPONSE_bio(bp,p) ASN1_d2i_bio_of(OCSP_RESPONSE,OCSP_RESPONSE_new,d2i_OCSP_RESPONSE,bp,p)
#define PEM_read_bio_OCSP_REQUEST(bp,x,cb) (OCSP_REQUEST *)PEM_ASN1_read_bio( \
(char *(*)())d2i_OCSP_REQUEST,PEM_STRING_OCSP_REQUEST,bp,(char **)x,cb,NULL)
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit. - Robert Woodruff
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: [CVS] OpenSSL: openssl/ CHANGES openssl/crypto/evp/ evp.h p_lib.c open...
Hi Richard,
Richard Levitte wrote:
...
+int EVP_PKEY_cmp(EVP_PKEY *a, EVP_PKEY *b)
Wouldn't be EVP_PKEY_cmp(const EVP_PKEY *a, const EVP_PKEY *b)
more appropriate ?
+ {
+ if (a-type != b-type)
+ return -1;
+
+ switch (a-type)
+ {
+#ifndef OPENSSL_NO_RSA
+ case EVP_PKEY_RSA:
+ if (BN_cmp(b-pkey.rsa-n,a-pkey.rsa-n) != 0
+ || BN_cmp(b-pkey.rsa-e,a-pkey.rsa-e) != 0)
+ return 0;
+ break;
+#endif
+#ifndef OPENSSL_NO_DSA
+ case EVP_PKEY_DSA:
+ if (BN_cmp(b-pkey.dsa-pub_key,a-pkey.dsa-pub_key) != 0)
+ return 0;
Shouldn't we compare the parameters as well (I don't know if it's really
necessary for the intended usage) ?
Regards,
Nils
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: [CVS] OpenSSL: openssl/ CHANGES openssl/crypto/evp/ evp.hp_lib.c open...
In message [EMAIL PROTECTED] on Sun, 6 Apr 2003 12:36:11 +0200, Nils Larsch [EMAIL PROTECTED] said: nlarsch Richard Levitte wrote: nlarsch ... nlarsch+int EVP_PKEY_cmp(EVP_PKEY *a, EVP_PKEY *b) nlarsch nlarsch Wouldn't be EVP_PKEY_cmp(const EVP_PKEY *a, const EVP_PKEY *b) nlarsch more appropriate ? Very good point, thank you. I've now committed a change to implement that. As you can see, I constified a few more, while I was at it. nlarsch Shouldn't we compare the parameters as well (I don't know if nlarsch it's really necessary for the intended usage) ? There's a separate function that does that, EVP_PKEY_cmp_parameters(). -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] [EMAIL PROTECTED] \ S-168 35 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-708-26 53 44 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Unsolicited commercial email is subject to an archival fee of $400. See http://www.stacken.kth.se/~levitte/mail/ for more info. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [CVS] OpenSSL: openssl CHANGES
Not entirely true. I implemented the dynamic locks on Windows in Kermit 95. I do not have any hardware to test it with though. + *) The hw_ncipher.c engine requires dynamic locks. Unfortunately, it + seems that in spite of existing for more than a year, no application + author has done anything to provide the necessary callbacks, which + means that this particular engine will not work properly anywhere. + This is a very unfortunate situation which forces us, in the name + of usability, to give the hw_ncipher.c a static lock, which is part + of libcrypto. + NOTE: This is for the 0.9.7 series ONLY. This hack will never + appear in 0.9.8 or later. We EXPECT application authors to have + dealt properly with this when 0.9.8 is released (unless we actually + make such changes in the libcrypto locking code that changes will + have to be made anyway). + [Richard Levitte] + __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [CVS] OpenSSL: openssl CHANGES
In message [EMAIL PROTECTED] on Thu, 12 Dec 2002 23:34:07 -0500, Jeffrey Altman [EMAIL PROTECTED] said: jaltman Not entirely true. I implemented the dynamic locks on jaltman Windows in Kermit 95. I do not have any hardware to test it jaltman with though. OK, I've now made a small change to CHANGES :-). BTW, why only on Windows? -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] Redakteur@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-708-26 53 44 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Unsolicited commercial email is subject to an archival fee of $400. See http://www.stacken.kth.se/~levitte/mail/ for more info. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
