[openssl-users] openssl rsa -check

[Georg Höllrigl]

Hello,

 

I think there is something broken with verifying the Private Key with "openssl rsa -check" like it was described in https://blog.hboeck.de/archives/888-How-I-tricked-Symantec-with-a-Fake-Private-Key.html

 

I tried to implement better checking in a script that tells me if a key matches a certificate or certificate request.

 

To reproduce, get the fake private key from https://github.com/hannob/tlshelpers/blob/master/examples/symantec.key

 

Verify the key with openssl 1.0.1e-fips or 1.0.2h:

$OPENSSL rsa -in symantec-broken.key -check -noout
RSA key error: n does not equal p q

 

Verify the key with openssl 1.1.0c or 1.1.0f (gives no output)

$OPENSSL rsa -in symantec-broken.key -check -noout

 

 

I would expect 1.1.0 to report the faked key in some way.

Even the returnvalue for openssl returns with a 0 no matter if used a legimate key or a faked key.

 

 

 

Kind Regards,

Georg

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

Re: [openssl-users] openssl rsa -check

[Paul Yang]

Hmmm, it’s a bug introduced by the use of RSA_check_key_ex function. Thanks for 
reporting.

> On 28 Jul 2017, at 19:16, Georg Höllrigl  wrote:
> 
> Hello,
>  
> I think there is something broken with verifying the Private Key with 
> "openssl rsa -check" like it was described in 
> https://blog.hboeck.de/archives/888-How-I-tricked-Symantec-with-a-Fake-Private-Key.html
>  
> 
>  
> I tried to implement better checking in a script that tells me if a key 
> matches a certificate or certificate request.
>  
> To reproduce, get the fake private key from 
> https://github.com/hannob/tlshelpers/blob/master/examples/symantec.key 
> 
>  
> Verify the key with openssl 1.0.1e-fips or 1.0.2h:
> $OPENSSL rsa -in symantec-broken.key -check -noout
> RSA key error: n does not equal p q
>  
> Verify the key with openssl 1.1.0c or 1.1.0f (gives no output)
> $OPENSSL rsa -in symantec-broken.key -check -noout
>  
>  
> I would expect 1.1.0 to report the faked key in some way.
> Even the returnvalue for openssl returns with a 0 no matter if used a 
> legimate key or a faked key.
>  
>  
>  
> Kind Regards,
> Georg
> -- 
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

Re: [openssl-users] openssl rsa -check

[Paul Yang]

Please refer to this: https://github.com/openssl/openssl/pull/4043 


> On 29 Jul 2017, at 00:21, Paul Yang  > wrote:
> 
> Hmmm, it’s a bug introduced by the use of RSA_check_key_ex function. Thanks 
> for reporting.
> 
>> On 28 Jul 2017, at 19:16, Georg Höllrigl > > wrote:
>> 
>> Hello,
>>  
>> I think there is something broken with verifying the Private Key with 
>> "openssl rsa -check" like it was described in 
>> https://blog.hboeck.de/archives/888-How-I-tricked-Symantec-with-a-Fake-Private-Key.html
>>  
>> 
>>  
>> I tried to implement better checking in a script that tells me if a key 
>> matches a certificate or certificate request.
>>  
>> To reproduce, get the fake private key from 
>> https://github.com/hannob/tlshelpers/blob/master/examples/symantec.key 
>> 
>>  
>> Verify the key with openssl 1.0.1e-fips or 1.0.2h:
>> $OPENSSL rsa -in symantec-broken.key -check -noout
>> RSA key error: n does not equal p q
>>  
>> Verify the key with openssl 1.1.0c or 1.1.0f (gives no output)
>> $OPENSSL rsa -in symantec-broken.key -check -noout
>>  
>>  
>> I would expect 1.1.0 to report the faked key in some way.
>> Even the returnvalue for openssl returns with a 0 no matter if used a 
>> legimate key or a faked key.
>>  
>>  
>>  
>> Kind Regards,
>> Georg
>> -- 
>> openssl-users mailing list
>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users 
>> 
> 

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

[openssl-users] Is RDRAND the default engine in OpenSSL 1.1.0?

[Jeffrey Walton]

I thought RDRAND was disabled as the default random engine since
1.0.1f. Has that changed in OpenSSL 1.1.0?

Related, see:

* https://stackoverflow.com/q/45370852/608639
* http://seclists.org/fulldisclosure/2013/Dec/99
* 
https://software.intel.com/en-us/blogs/2014/10/03/changes-to-rdrand-integration-in-openssl
* https://trac.torproject.org/projects/tor/ticket/10402
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Is RDRAND the default engine in OpenSSL 1.1.0?

[Blumenthal, Uri - 0553 - MITLL]

I sincerely hope it is not so.

--
Regards,
Uri Blumenthal

On 7/28/17, 15:47, "openssl-users on behalf of Jeffrey Walton" 
 wrote:

I thought RDRAND was disabled as the default random engine since
1.0.1f. Has that changed in OpenSSL 1.1.0?

Related, see:

* https://stackoverflow.com/q/45370852/608639
* http://seclists.org/fulldisclosure/2013/Dec/99
* 
https://software.intel.com/en-us/blogs/2014/10/03/changes-to-rdrand-integration-in-openssl
* https://trac.torproject.org/projects/tor/ticket/10402
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users



smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Is RDRAND the default engine in OpenSSL 1.1.0?

[Salz, Rich via openssl-users]

> I thought RDRAND was disabled as the default random engine since
> 1.0.1f. Has that changed in OpenSSL 1.1.0?

No.  Do "git grep ENGINE_set_default_RAND"


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

Re: [openssl-users] Is RDRAND the default engine in OpenSSL 1.1.0?

[Jeffrey Walton]

On Fri, Jul 28, 2017 at 3:53 PM, Salz, Rich  wrote:
>> I thought RDRAND was disabled as the default random engine since
>> 1.0.1f. Has that changed in OpenSSL 1.1.0?
>
> No.  Do "git grep ENGINE_set_default_RAND"

Ack, thanks. I wonder where that's coming from for 1.1.0. Maybe
Dropbox is providing vendor patches.

Jeff
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Openssl 1.1 RSA_get0_key() documentation

[Salz, Rich via openssl-users]

> The __current__ code for this function returns values if the **BIGNUM is
> not NULL.  Thus, it appears safe to pass in NULL for values not needed.

Yes.  That's true for many "get" functions.

> However, the documentation is silent on this behavior.
> 
> If this behavior is guaranteed, it would be nice if it was documented.

Wanna open an issue to fix the doc? :)
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Openssl 1.1 RSA_get0_key() documentation

[Ken Goldman]

On 7/28/2017 4:05 PM, Salz, Rich via openssl-users wrote:

The __current__ code for this function returns values if the **BIGNUM is
not NULL.  Thus, it appears safe to pass in NULL for values not needed.




If this behavior is guaranteed, it would be nice if it was documented.


Wanna open an issue to fix the doc? :)



I'd be happy to, but I don't know how.

I'd also be willing to help with documentation, if that's possible.


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