Skip Menu |

This queue is for tickets about the Crypt-OpenSSL-RSA CPAN distribution.

Report information
The Basics
Id: 45498
Status: resolved
Priority: 0/
Queue: Crypt-OpenSSL-RSA

People
Owner: Nobody in particular
Requestors: MARKLE [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: Important
Broken in: 0.25
Fixed in: (no value)



Subject: OpenSSL error: padding check failed at t/rsa.t line 149
I expanded the test a little to warn the actual $@ if "ok(!$@)" fails. PERL_DL_NONLAZY=1 /usr/bin/perl "-MExtUtils::Command::MM" "-e" "test_harness(0, 'blib/lib', 'blib/arch')" t/*.t t/bignum.t .. skipped: (no reason given) t/format.t .. ok t/rsa.t ..... 1/63 # Failed test 63 in t/rsa.t at line 151 # t/rsa.t line 151 is: ok(!$err); # error: RSA.xs:301: OpenSSL error: padding check failed at t/rsa.t line 149. t/rsa.t ..... Failed 1/63 subtests
I also get this failure, on 64-bit RHEL 5.3. The failure does NOT occur on 32-bit Fedora 9. This is the part of the t/rsa.t test script that fails... Show quoted text
># check subclassing > >eval { Crypt::OpenSSL::RSA::Subpackage->generate_key(256); }; >ok(!$@);
I find that if I change the key length in this line to 512, the test script passes. Not sure why though. Jason Long
The error comes from openssl. Maybe RHell/CentOS modify openssl libs to require 512 bit keys?
On Mon Jun 01 14:03:09 2009, MARKLE wrote: Show quoted text
> The error comes from openssl. Maybe RHell/CentOS modify openssl libs
to Show quoted text
> require 512 bit keys?
I don't think so. I run two different RHell/CentOS distros, one 32bit and the other 64bit. The 32bit machine passes this test, the 64bit machine fails this test. The 32bit machine is: [root@wilber ~]# cat /etc/release ClarkConnect Community Edition release 4.2 [root@wilber ~]# cat /etc/redhat-release CentOS release 4.2 (Final) [root@wilber ~]# By memory ClarkConnect also use some RHEL4 rpms as well. The 64bit machine is: [root@server ~]# cat /etc/redhat-release CentOS release 5.3 (Final) [root@server ~]# The 32bit machine openssl libs: [root@wilber ~]# rpm -qa | grep -i ssl | sort cc-ssl-4.2-10 docbook-style-dsssl-1.78-4 mod_ssl-2.0.52-22.cc openssl096b-0.9.6b-22.46 openssl-0.9.7a-43.17.el4_7.2 openssl-devel-0.9.7a-43.17.el4_7.2 openssl-perl-0.9.7a-43.17.el4_7.2 perl-Crypt-SSLeay-0.51-5 perl-IO-Socket-SSL-0.97-1.cc perl-Net-SSLeay-1.26-2.cc [root@wilber ~]# The 64bit machine openssl libs: [root@server ~]# rpm -qa | grep -i ssl | sort mod_ssl-2.2.3-22.el5.centos openssl097a-0.9.7a-9.el5_2.1 openssl-0.9.8e-7.el5 openssl-0.9.8e-7.el5 openssl-devel-0.9.8e-7.el5 openssl-devel-0.9.8e-7.el5 openssl-perl-0.9.8e-7.el5 perl-Crypt-SSLeay-0.51-11.el5 perl-IO-Socket-SSL-1.01-1.fc6 perl-Net-SSLeay-1.30-4.fc6 pyOpenSSL-0.6-1.p24.7.2.2 xmlsec1-openssl-1.2.9-8.1 xmlsec1-openssl-1.2.9-8.1 xmlsec1-openssl-devel-1.2.9-8.1 xmlsec1-openssl-devel-1.2.9-8.1 [root@server ~]#
I'm seeing a similar problem on my redhat 5.3 system: not ok 63 # Failed test 63 in t/rsa.t at line 150 # t/rsa.t line 150 is: ok(!$@);
I'm not seeing this behavior on my suse 11.1 64bit box with openssl-0.9.8h (also 64 bit).. Moreover, I can bump the keysize on the test in question as low as 31 bits; after that, the error is "OpenSSL error: bad signature", not the "padding check failed" error. One person mentioned that bumping the key size from 256 to 512 made the problem go away. Are others seeing the same behavior? Those who are seeing this; does the problem go away if you change line 149 from generate_key(256) to generate_key(512)? Also, what happens if you run: openssl genrsa 256 from the command line?
On Tue Nov 17 23:12:52 2009, IROBERTS wrote: Show quoted text
> Also, what happens if you run: > > openssl genrsa 256 > > from the command line?
Yes, in CentOS with perl 5.8.8 changing the test to 512 makes the test succeed. hedges@anubis:~$ openssl genrsa 256 Generating RSA private key, 256 bit long modulus ...+++++++++++++++++++++++++++ ..................+++++++++++++++++++++++++++ 1584:error:0408C070:rsa routines:FIPS_RSA_SIGN:digest too big for rsa key:fips_rsa_sign.c:280: 1584:error:2D06D075:FIPS routines:fips_pkey_signature_test:test failure:fips.c:672: 1584:error:2D06A06B:FIPS routines:FIPS_CHECK_RSA:pairwise test failed:fips_rsa_gen.c:132: 1584:error:04081003:rsa routines:RSA_BUILTIN_KEYGEN:BN lib:fips_rsa_gen.c:298: hedges@anubis:~$ openssl genrsa 512 Generating RSA private key, 512 bit long modulus ...++++++++++++ .....++++++++++++ unable to write 'random state' e is 65537 (0x10001) Show quoted text
-----BEGIN RSA PRIVATE KEY----- MIIBOwIBAAJBANTqQfnWtnj5ZPdyzdq+MuvmGfPctQMOZ0NokaOlfsnugY1u6oSn kY+9n5Yi1uTW7IeyfQTZpX5ElOOwmR3Bv5sCAwEAAQJAL3BKZuoqGeYnUuLnbtd1 7Q2Ftsn0IswwwdooqPeUulTbgetAVVBL04uJ1aF2bcjhDPWepFTb/Y8r2Ki/nvj1 oQIhAPt1jBvbH/+Rg/LyM6tpqtQLGdZS6klEWC+p1N2oJOlJAiEA2MKHE4R0yo23 kFvJFvJvnRm0drGX1ezMSZlKkE0IpcMCIQDAp5+v2+OZJ8DDSuNhafTSvqqN9TrA 5Zb29ZQ8Os4E2QIhALCRXUjHx/9Li7D7I4YevE6jpr5dEgr/1rVJOlTre1TTAiAJ E9nuA4eRvnXMoRug0a5GwSX7RXrCQNTsdkK4QPKYDA== -----END RSA PRIVATE KEY----- Thanks for checking this out! I would love to have another item on my checklist of why RedHate sucks. --mark--
Another thing to try: after running make test (and having it fail), try running just this: PERL_DL_NONLAZY=1 /usr/bin/perl -e '$dir = `pwd`; chop $dir; unshift @INC, "$dir/blib/lib", "$dir/blib/arch"; eval "use Crypt::OpenSSL::RSA"; Crypt::OpenSSL::RSA->generate_key(256);' I'm wondering if there are some unexpected interactions between the tests at play here; running the above can help either eliminate or support that possibility.
On Tue Nov 17 23:22:53 2009, MARKLE wrote: Show quoted text
> On Tue Nov 17 23:12:52 2009, IROBERTS wrote:
> > Also, what happens if you run: > > > > openssl genrsa 256 > > > > from the command line?
> > Yes, in CentOS with perl 5.8.8 changing the test to 512 makes the test > succeed. > > hedges@anubis:~$ openssl genrsa 256 > Generating RSA private key, 256 bit long modulus > ...+++++++++++++++++++++++++++ > ..................+++++++++++++++++++++++++++ > 1584:error:0408C070:rsa routines:FIPS_RSA_SIGN:digest too big for rsa > key:fips_rsa_sign.c:280: > 1584:error:2D06D075:FIPS routines:fips_pkey_signature_test:test > failure:fips.c:672: > 1584:error:2D06A06B:FIPS routines:FIPS_CHECK_RSA:pairwise test > failed:fips_rsa_gen.c:132: > 1584:error:04081003:rsa routines:RSA_BUILTIN_KEYGEN:BN > lib:fips_rsa_gen.c:298: > > hedges@anubis:~$ openssl genrsa 512 > Generating RSA private key, 512 bit long modulus > ...++++++++++++ > .....++++++++++++ > unable to write 'random state' > e is 65537 (0x10001) > -----BEGIN RSA PRIVATE KEY----- > MIIBOwIBAAJBANTqQfnWtnj5ZPdyzdq+MuvmGfPctQMOZ0NokaOlfsnugY1u6oSn > kY+9n5Yi1uTW7IeyfQTZpX5ElOOwmR3Bv5sCAwEAAQJAL3BKZuoqGeYnUuLnbtd1 > 7Q2Ftsn0IswwwdooqPeUulTbgetAVVBL04uJ1aF2bcjhDPWepFTb/Y8r2Ki/nvj1 > oQIhAPt1jBvbH/+Rg/LyM6tpqtQLGdZS6klEWC+p1N2oJOlJAiEA2MKHE4R0yo23 > kFvJFvJvnRm0drGX1ezMSZlKkE0IpcMCIQDAp5+v2+OZJ8DDSuNhafTSvqqN9TrA > 5Zb29ZQ8Os4E2QIhALCRXUjHx/9Li7D7I4YevE6jpr5dEgr/1rVJOlTre1TTAiAJ > E9nuA4eRvnXMoRug0a5GwSX7RXrCQNTsdkK4QPKYDA== > -----END RSA PRIVATE KEY----- > > Thanks for checking this out! I would love to have another item on my > checklist of why RedHate sucks. --mark--
Sorry - I didn't see your response before my second response. I'll work on getting out a new release with a 512 bit key instead of 256 bit in the next few days. - Ian
'use blib' accomplishes the same thing and incidentally should be used in all the test scripts. Your suggestion resulted in this: hedges@anubis:~/lame/Crypt-OpenSSL-RSA-0.25$ PERL_DL_NONLAZY=1 /usr/bin/perl -e '$dir = `pwd`; chop $dir; unshift @INC, "$dir/blib/lib", "$dir/blib/arch"; eval "use Crypt::OpenSSL::RSA"; Crypt::OpenSSL::RSA->generate_key(256);' RSA.xs:301: OpenSSL error: digest too big for rsa key at -e line 1. Why isn't a 256-bit key valid? It works on other platforms. openssl is hacked by RedHate to disallow it? Mark
Fixed in 0.26, now available at https://pause.perl.org/pub/PAUSE/authors/id/I/IR/IROBERTS/ and doubtlessly working its way through the distribution channels.
On Sun Nov 22 15:46:09 2009, IROBERTS wrote: Show quoted text
> Fixed in 0.26, now available at > https://pause.perl.org/pub/PAUSE/authors/id/I/IR/IROBERTS/ and > doubtlessly working its way through the distribution channels.
Closing