David von Oheimb via RT | 2 Jul 12:21 2015
Picon

Re: [openssl.org #3922] Bug: EVP_get_digestbynid() does not support ECDSA

Thanks a lot Steve for your constructive comments.

> That's expected behaviour. The EVP_get_digestbynid funtion expects a digest NID
> whereas you are passing a signature NID instead. It does accept some signature
> NIDs for historical compatibility reasons.

I now understand that the code I extended for EC support was abusing
EVP_get_digestbynid(), which worked just for compatibility reasons for
RSA (only). Yet why not broaden this function (or better its underlying
mapping) to handle ECDSA (and possibly any other types of) signatures.

> The thread you mention shows you how to convert a signature NID into the digest
> and public key algorithm NID.

The hint you gave in that thread was to use  OBJ_find_sigid_algs()
and this indeed works fine and is cleaner :-)

> However I suspect you shouldn't be trying to do things at that level for
> signatures. If you need to sign or verify ASN.1 data you can use ASN1_item_sign
> or ASN1_item_verify and key and digest handling and lookup is handled automatically.

Good point that they better should have used a more high-level
signature/verification function. Yet the proposed functions, as well as
ASN1_sign and ASN1_verify, still require the (plain) md parameter.
And for instance the more abstract function
  int PKCS7_SIGNER_INFO_sign(PKCS7_SIGNER_INFO *si)
uses again
  md = EVP_get_digestbyobj(si->digest_alg->algorithm);
such that the use of OBJ_find_sigid_algs() appears indispensable.

(Continue reading)

nikolavan | 2 Jul 10:34 2015

AES-GCM for ARM: what is the status of the new work published by

Hi,

What is the status of the improvements on security and performance for AES-GCM on ARM published recently by Conrado P. L. Gouvêa, Julio López ?

Implementing GCM on ARMv8. Conrado P. L. Gouvêa, Julio López. 2015 [1]
Which details also the ARMv7 case, and was presented at the RSA Conference 2015 in the US, 2 months ago.
The paper is here [2].
The code is available here [3]

My question goes primarily to Andy Polyakov.

Is there any plan for integrating the code into openssl ?

Best regards,

Niko



_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Patil, Ashwini IN BLR STS | 1 Jul 08:24 2015
Picon

Openssl 1.0.2c include the FIPS 140-2 Object Module

Hello All,
 
Please let me know if openssl-1.0.2c include FIPS 140-2 Object Module.
Also please explain how to validate the application.
 
Your help is appreciated.
 
With best regards,
Ashwini V Patil
 
Siemens Technology and Services Private Limited
CT DC AA HC H1-FH STD IBP 6
84, Hosur Road
Bengaluru 560100, Indien
Mobil: +91 9008132565
 
Registered Office: 130, Pandurang Budhkar Marg, Worli, Mumbai 400 018. Telephone +91 22 39677000. Fax +91 22 39677075. Other Offices: Bengaluru, Chennai, Gurgaon, Noida, Pune. Corporate Identity number:U99999MH1986PLC093854
 
 
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Stephen Henson via RT | 29 Jun 19:17 2015
Picon

[openssl.org #3927] regression in 1.0.2c spotted by Net-SSLeay

On Mon Jun 29 14:27:18 2015, meissner <at> suse.de wrote:
> Hi,
>
> I am debugging a testsuite error in the perl Net-SSLeay module, which
> got introduced between 1.0.2a
> and 1.0.2c.
>
> The test code looks like this:
>
> ... private key in $pk ...
>
> ok(my $alg2 = Net::SSLeay::EVP_get_cipherbyname("DES-EDE3-OFB"),
> "EVP_get_cipherbyname");
> like(my $key_pem4 =
> Net::SSLeay::PEM_get_string_PrivateKey($pk,"password",$alg2), qr/-----
> BEGIN (ENCRYPTED|RSA) PRIVATE KEY-----/,
> "PEM_get_string_PrivateKey+passwd+enc_alg");
>
> Previously it returned a encrypted key, now it does not.
>
> The error stack has:
> 0:error:0D0A706C:asn1 encoding
> routines:PKCS5_pbe2_set_iv:cipher has no object
> identifier:p5_pbev2.c:104:
> 0:error:2307D00D:PKCS12 routines:PKCS8_encrypt:ASN1
> lib:p12_p8e.c:86:
>
[snip]
>
> which comes from the objects entry:
> obj_dat.h:{"DES-EDE3-CBC","des-ede3-
> cbc",NID_des_ede3_cbc,8,&(lvalues[235]),0},
> obj_dat.h:{"DES-EDE3-OFB","des-ede3-ofb",NID_des_ede3_ofb64,0,NULL,0},
>
> I was not able to find out why des-ede3-cbc does have length 8, but
> ofb does not?
>
> How to fix this? Should it have length 8 too?
>

That should never have worked in the first place. It has a length 0 because the
NID has no corresponding object identifier and such NIDs cannot be properly
encoded in PKCS#8 format. The fact that OpenSSL let you do that previously
(with a garbage OID) is the bug.

The fix is to use a cipher mode which is properly supported for PKCS#8 format
such as CBC mode.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Marcus Meissner via RT | 29 Jun 16:27 2015
Picon

[openssl.org #3927] regression in 1.0.2c spotted by Net-SSLeay

Hi,

I am debugging a testsuite error in the perl Net-SSLeay module, which got introduced between 1.0.2a
and 1.0.2c.

The test code looks like this:

  ... private key in $pk ...

  ok(my $alg2 = Net::SSLeay::EVP_get_cipherbyname("DES-EDE3-OFB"), "EVP_get_cipherbyname");
  like(my $key_pem4 = Net::SSLeay::PEM_get_string_PrivateKey($pk,"password",$alg2),
qr/-----BEGIN (ENCRYPTED|RSA) PRIVATE KEY-----/, "PEM_get_string_PrivateKey+passwd+enc_alg");

Previously it returned a encrypted key, now it does not.

The error stack has:
	0:error:0D0A706C:asn1 encoding routines:PKCS5_pbe2_set_iv:cipher has no object identifier:p5_pbev2.c:104:
	0:error:2307D00D:PKCS12 routines:PKCS8_encrypt:ASN1 lib:p12_p8e.c:86:

Which I _think_ is caused by this change between 1.0.2a and 1.0.2c:

diff --git a/crypto/objects/obj_dat.c b/crypto/objects/obj_dat.c
index 5cd755d..aca382a 100644
--- a/crypto/objects/obj_dat.c
+++ b/crypto/objects/obj_dat.c
 <at>  <at>  -400,6 +400,8  <at>  <at>  static int obj_cmp(const ASN1_OBJECT *const *ap, const unsigned int *bp)
     j = (a->length - b->length);
     if (j)
	 return (j);
+    if (a->length == 0)
+        return 0;
     return (memcmp(a->data, b->data, a->length));
 }

 <at>  <at>  -415,6 +417,9  <at>  <at>  int OBJ_obj2nid(const ASN1_OBJECT *a)
     if (a->nid != 0)
	 return (a->nid);

+    if (a->length == 0)
+        return NID_undef;
+
     if (added != NULL) {
	 ad.type = ADDED_DATA;
	 ad.obj = (ASN1_OBJECT *)a; /* XXX: ugly but harmless */

which comes from the objects entry:
obj_dat.h:{"DES-EDE3-CBC","des-ede3-cbc",NID_des_ede3_cbc,8,&(lvalues[235]),0},
obj_dat.h:{"DES-EDE3-OFB","des-ede3-ofb",NID_des_ede3_ofb64,0,NULL,0},

I was not able to find out why des-ede3-cbc does have length 8, but ofb does not? 

How to fix this? Should it have length 8 too?

Ciao, Marcus

_______________________________________________
openssl-bugs-mod mailing list
openssl-bugs-mod <at> openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod

_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

rsteck | 28 Jun 00:52 2015

RSA SigVer (FIPS 186-4) Issue

I am getting incorrect False-Negative results when performing tests with 
186-4 vectors (generated by CAVS 17.6).

This vector is being reported false while CAVS says they should pass.

[mod = 1024]
n = 
d915e54ecbf96e1daadb5faa22856c4544a80c03d4cabeb58f7558a2ac9e939d387f86eebfa32aa81d6624def50684b46855a7cb86a15305ea84f34e9c18b1ca2b77e26f616f464cc675a9628aa2bc847c7a9f4ec2a3c49809901aa9ef76e5c779f621ddc791565708e65ea97a786653c745573c34310f135e29322d304fc009

SHAAlg = SHA512
e = 
00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001f2acb
Msg = 
912ca58670bda8a7d76c2f97bbeb76b1d795bc4ff2a6a29864a7d599d72dec984bc394a45d25ea71c8af28632c1484e90e53550c20e77848c33ef29acb6dd6da82226a4befda857158543b220545bce0474d7a66b92a8a81c62c4d216be84fb03e316fa2b044414e8f43b0fccfe5e83f896b738544d6a1ec74572e5740071fc2
S = 
122efd4d9f6dd746b959aebfe8e23fb0181afce8905cae19861da977aaff4c97792c488b065cc0a0f5c97f50f6545a77606d2e9b3e3533d3c54f6feb3670888238f3a58569a77f7a3178df599f637b13eaf13fa7a7706a7970aa3ab725b5e844d2861cc56cfed910328a8cf45b6f053e06f2b18c1a71ee48b38fed757a99b0c3

I've added some debug output and I get the following:

DIGEST = 
423d03646e5e4105181a5d9815b7fe3d588c3097ce7109ae4635add1be5ec026eb6860198914d1eb7fb1e62d86f60b3929fc6549d1b6b445ecc7b61219bf90d3
SIG = 
122EFD4D9F6DD746B959AEBFE8E23FB0181AFCE8905CAE19861DA977AAFF4C97792C488B065CC0A0F5C97F50F6545A77606D2E9B3E3533D3C54F6FEB3670888238F3A58569A77F7A3178DF599F637B13EAF13FA7A7706A7970AA3AB725B5E844D2861CC56CFED910328A8CF45B6F053E06F2B18C1A71EE48B38FED757A99B0C3
N   = 
D915E54ECBF96E1DAADB5FAA22856C4544A80C03D4CABEB58F7558A2AC9E939D387F86EEBFA32AA81D6624DEF50684B46855A7CB86A15305EA84F34E9C18B1CA2B77E26F616F464CC675A9628AA2BC847C7A9F4EC2A3C49809901AA9EF76E5C779F621DDC791565708E65EA97A786653C745573C34310F135E29322D304FC009
RR  = 
CE64B6D692597419FB9E6E4FF65B1A1181352AEF44565DDAC0F5F4C6B7E228853740B98FAAA513F4F3F4A42C908584496FF7E03D63E086AD23C6044F1506F98A23EB6BB31DD55E735C74EBDD17AB50DFB94008B2912B4CA77734DDC416866E5862E6C18DBF598BF243192FB1A657E5A4E5681DCBB34DF229D6136E0282AFEAC
SUB = 
CC2F99E162D3D6DC0B2178C5231FBAA42C94B954E08558D7E365F95641207114E50B7B55C4F8D968CE26DA9C2BFE2C6FD15629C7B0634A9B18489309AAC8423189392BB42F91F06590AE5AA4B928077680E69EC399910FCD921CCCCDAE0E7EE1F3C7B5C4EB9BBD97E4B4CBAE6012E7F978EED55F78FC2FF0C0C7FB4D0824C15D
IR  = 
CE64B6D692597419FB9E6E4FF65B1A1181352AEF44565DDAC0F5F4C6B7E228853740B98FAAA513F4F3F4A42C908584496FF7E03D63E086AD23C6044F1506F98A23EB6BB31DD55E735C74EBDD17AB50DFB94008B2912B4CA77734DDC416866E5862E6C18DBF598BF243192FB1A657E5A4E5681DCBB34DF229D6136E0282AFEAC
SigVer Result = 0

"RR" is the result of the power-E-mod-N operation, and "SUB" is the 
computed (N-RR) value.  "IR" is the choice of RR or (N-RR) used for the 
remainder of verification.

It seems clear to me that neither RR nor SUB has the correct form, and 
that this vector should not pass.

The lab is saying this must be a bug in OpenSSL, but no modification has 
been made that would introduce such a bug.  It's my contention that this 
is a bug in CAVS.  Can anyone shed some additional light onto the issue?

Thanks,
Randy Steck
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

rsteck | 29 Jun 08:48 2015

RSA SigVer (FIPS 186-4) Issue

I am getting incorrect False-Negative results when performing tests with 
186-4 vectors (generated by CAVS 17.6).

This vector is being reported false while CAVS says they should pass.

[mod = 1024]
n = 
d915e54ecbf96e1daadb5faa22856c4544a80c03d4cabeb58f7558a2ac9e939d387f86eebfa32aa81d6624def50684b46855a7cb86a15305ea84f34e9c18b1ca2b77e26f616f464cc675a9628aa2bc847c7a9f4ec2a3c49809901aa9ef76e5c779f621ddc791565708e65ea97a786653c745573c34310f135e29322d304fc009

SHAAlg = SHA512
e = 
00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001f2acb
Msg = 
912ca58670bda8a7d76c2f97bbeb76b1d795bc4ff2a6a29864a7d599d72dec984bc394a45d25ea71c8af28632c1484e90e53550c20e77848c33ef29acb6dd6da82226a4befda857158543b220545bce0474d7a66b92a8a81c62c4d216be84fb03e316fa2b044414e8f43b0fccfe5e83f896b738544d6a1ec74572e5740071fc2
S = 
122efd4d9f6dd746b959aebfe8e23fb0181afce8905cae19861da977aaff4c97792c488b065cc0a0f5c97f50f6545a77606d2e9b3e3533d3c54f6feb3670888238f3a58569a77f7a3178df599f637b13eaf13fa7a7706a7970aa3ab725b5e844d2861cc56cfed910328a8cf45b6f053e06f2b18c1a71ee48b38fed757a99b0c3

I've added some debug output and I get the following:

DIGEST = 
423d03646e5e4105181a5d9815b7fe3d588c3097ce7109ae4635add1be5ec026eb6860198914d1eb7fb1e62d86f60b3929fc6549d1b6b445ecc7b61219bf90d3
SIG = 
122EFD4D9F6DD746B959AEBFE8E23FB0181AFCE8905CAE19861DA977AAFF4C97792C488B065CC0A0F5C97F50F6545A77606D2E9B3E3533D3C54F6FEB3670888238F3A58569A77F7A3178DF599F637B13EAF13FA7A7706A7970AA3AB725B5E844D2861CC56CFED910328A8CF45B6F053E06F2B18C1A71EE48B38FED757A99B0C3
N   = 
D915E54ECBF96E1DAADB5FAA22856C4544A80C03D4CABEB58F7558A2AC9E939D387F86EEBFA32AA81D6624DEF50684B46855A7CB86A15305EA84F34E9C18B1CA2B77E26F616F464CC675A9628AA2BC847C7A9F4EC2A3C49809901AA9EF76E5C779F621DDC791565708E65EA97A786653C745573C34310F135E29322D304FC009
RR  = 
CE64B6D692597419FB9E6E4FF65B1A1181352AEF44565DDAC0F5F4C6B7E228853740B98FAAA513F4F3F4A42C908584496FF7E03D63E086AD23C6044F1506F98A23EB6BB31DD55E735C74EBDD17AB50DFB94008B2912B4CA77734DDC416866E5862E6C18DBF598BF243192FB1A657E5A4E5681DCBB34DF229D6136E0282AFEAC
SUB = 
CC2F99E162D3D6DC0B2178C5231FBAA42C94B954E08558D7E365F95641207114E50B7B55C4F8D968CE26DA9C2BFE2C6FD15629C7B0634A9B18489309AAC8423189392BB42F91F06590AE5AA4B928077680E69EC399910FCD921CCCCDAE0E7EE1F3C7B5C4EB9BBD97E4B4CBAE6012E7F978EED55F78FC2FF0C0C7FB4D0824C15D
IR  = 
CE64B6D692597419FB9E6E4FF65B1A1181352AEF44565DDAC0F5F4C6B7E228853740B98FAAA513F4F3F4A42C908584496FF7E03D63E086AD23C6044F1506F98A23EB6BB31DD55E735C74EBDD17AB50DFB94008B2912B4CA77734DDC416866E5862E6C18DBF598BF243192FB1A657E5A4E5681DCBB34DF229D6136E0282AFEAC
SigVer Result = 0

"RR" is the result of the power-E-mod-N operation, and "SUB" is the 
computed (N-RR) value.  "IR" is the choice of RR or (N-RR) used for the 
remainder of verification.

It seems clear to me that neither RR nor SUB has the correct form, and 
that this vector should not pass.

The lab is saying this must be a bug in OpenSSL, but no modification has 
been made that would introduce such a bug.  It's my contention that this 
is a bug in CAVS.  Can anyone shed some additional light onto the issue?

Thanks,
Randy Steck
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Richard Levitte | 26 Jun 16:31 2015
Picon

Re: [BISECTED] make install_sw fails

rm -f include/openssl/des_old.h

In message <DUB123-W41F4CF0407278CBFC5F9D4EDAD0 <at> phx.gbl> on Fri, 26 Jun 2015 16:08:13 +0200, Lukas
Tribus <luky-37 <at> hotmail.com> said:

luky-37> Hi!
luky-37> 
luky-37> 
luky-37> Since commit dee502be89e7 ("Stop symlinking, move files to intended
luky-37> directory"), "make install_sw" fails with (and other, similar errors,
luky-37> depending on the git HEAD):
luky-37> 
luky-37> cp: cannot stat ‘include/openssl/des_old.h’: No such file or directory
luky-37> make: *** [install_sw] Error 1
luky-37> 
luky-37> 
luky-37> I'm testing like this:
luky-37> rm -r /home/user/libsslbuild/
luky-37> mkdir /home/user/libsslbuild/
luky-37> cd /home/user/openssl/
luky-37> ./config --prefix=/home/user/libsslbuild/ no-shared
luky-37> make
luky-37> make install_sw
luky-37> 
luky-37> 
luky-37> 
luky-37> 
luky-37> Could you please take a look?
luky-37> 
luky-37> 
luky-37> 
luky-37> Thanks,
luky-37> 
luky-37> Lukas 		 	   		  
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Kurt Cancemi via RT | 26 Jun 14:33 2015
Picon

[openssl.org #3926] [PATCH] Fix -evp option in openssl speed command

Hello,

The -evp option in the openssl speed command doesn't work in the
current master due to the check on line 952:
if (argc == 0) should be if (argc == 0 && !doit(D_EVP))

the reason is on line 856: argc = opt_num_rest(); which sets argc to 0
because the argument of -evp <insert cipher/hash> doesn't count as an
argument in the opt_num_rest() function.

See the attached patch

--
Kurt Cancemi
https://www.x64architecture.com

_______________________________________________
openssl-bugs-mod mailing list
openssl-bugs-mod <at> openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Marcus Meissner | 26 Jun 09:27 2015
Picon

testsuite error in Net-SSLeay

Hi,

I am debugging a testsuite error in the perl Net-SSLeay module, which got introduced between 1.0.2a
and 1.0.2c.

The test code looks like this:

  ... private key in $pk ...

  ok(my $alg2 = Net::SSLeay::EVP_get_cipherbyname("DES-EDE3-OFB"), "EVP_get_cipherbyname");
  like(my $key_pem4 = Net::SSLeay::PEM_get_string_PrivateKey($pk,"password",$alg2),
qr/-----BEGIN (ENCRYPTED|RSA) PRIVATE KEY-----/, "PEM_get_string_PrivateKey+passwd+enc_alg");

Previously it returned a encrypted key, now it does not.

The error stack has:
	0:error:0D0A706C:asn1 encoding routines:PKCS5_pbe2_set_iv:cipher has no object identifier:p5_pbev2.c:104:
	0:error:2307D00D:PKCS12 routines:PKCS8_encrypt:ASN1 lib:p12_p8e.c:86:

Which I _think_ is caused by this change between 1.0.2a and 1.0.2c:

diff --git a/crypto/objects/obj_dat.c b/crypto/objects/obj_dat.c
index 5cd755d..aca382a 100644
--- a/crypto/objects/obj_dat.c
+++ b/crypto/objects/obj_dat.c
 <at>  <at>  -400,6 +400,8  <at>  <at>  static int obj_cmp(const ASN1_OBJECT *const *ap, const unsigned int *bp)
     j = (a->length - b->length);
     if (j)
	 return (j);
+    if (a->length == 0)
+        return 0;
     return (memcmp(a->data, b->data, a->length));
 }

 <at>  <at>  -415,6 +417,9  <at>  <at>  int OBJ_obj2nid(const ASN1_OBJECT *a)
     if (a->nid != 0)
	 return (a->nid);

+    if (a->length == 0)
+        return NID_undef;
+
     if (added != NULL) {
	 ad.type = ADDED_DATA;
	 ad.obj = (ASN1_OBJECT *)a; /* XXX: ugly but harmless */

which comes from the objects entry:
obj_dat.h:{"DES-EDE3-CBC","des-ede3-cbc",NID_des_ede3_cbc,8,&(lvalues[235]),0},
obj_dat.h:{"DES-EDE3-OFB","des-ede3-ofb",NID_des_ede3_ofb64,0,NULL,0},

I was not able to find out why des-ede3-cbc does have length 8, but ofb does not? 

How to fix this? Should it have length 8 too?

Ciao, Marcus
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Alexander Gostrer | 25 Jun 17:26 2015
Picon

A new openssl engine

Hi All,

Sorry for a wide distribution. I am in a process of writing an OpenSSL engine to support my client hardware. The client requested to publish the code on the openssl.org site. What are openssl criterions for publishing new engines/adding new features? Is there a document or a person who can help to understand the process?

Thank you,
Alexander Gostrer.
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Gmane