Re: [openssl-users] Why openssl 1.0.1p accepts composite $q$ in DSA?

2015-09-09 Thread Viktor Dukhovni 
On Wed, Sep 09, 2015 at 03:02:36PM +0300, Georgi Guninski wrote:

> On Wed, Sep 09, 2015 at 11:55:36AM +, Viktor Dukhovni wrote:
> > 
> > The expected time for this sort of check is when CAs sign certificates,
> > not when TLS handshake participants validate the certificates of
> > their peers (issued by trusted issuers, or else why bother).
> 
> Are you saying I can't sign the cert with another cert
> (the pubkey is easy to extract from the cert) with openssl?

If you control a trusted root CA, or an intermediate CA issued
(possibly indirectly) by a trusted root CA, you can sign anything
you want and it will be trusted.  The fact that malfeasant CAs can
compromise security is not new.

If you don't control a trusted CA, what significance would such a
signature carry?  Yes, most certificates (sometimes constrained by
KeyUsage) can be used for signing, but unless "CA=true", they can't
be used to sign other certificates that will be trusted by peers.

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

Re: [openssl-users] Why openssl 1.0.1p accepts composite $q$ in DSA?

2015-09-09 Thread Georgi Guninski 
On Wed, Sep 09, 2015 at 07:03:59AM -0400, Jeffrey Walton wrote:
> On Wed, Sep 9, 2015 at 6:28 AM, Georgi Guninski  wrote:
> > In short openssl 1.0.1p accepts composite $q$
> > in DSA verify/SSL.
> >
> > If $q$ is backdoored in the DSA/DH group parameters,
> > this breaks all private keys using it (see links at
> > bottom)...
> >
> Just bikeshedding, but before I went any further with it, I would
> verify DSA_check_key(...) does *not* reject the key.
>

Doesn't the sessions with s_client/s_server and
dsa verify (in the links) show this works in practice,
no matter of your question?


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

Re: [openssl-users] Why openssl 1.0.1p accepts composite $q$ in DSA?

2015-09-09 Thread Jeffrey Walton 
On Wed, Sep 9, 2015 at 7:15 AM, Georgi Guninski  wrote:
> On Wed, Sep 09, 2015 at 07:03:59AM -0400, Jeffrey Walton wrote:
>> On Wed, Sep 9, 2015 at 6:28 AM, Georgi Guninski  
>> wrote:
>> > In short openssl 1.0.1p accepts composite $q$
>> > in DSA verify/SSL.
>> >
>> > If $q$ is backdoored in the DSA/DH group parameters,
>> > this breaks all private keys using it (see links at
>> > bottom)...
>> >
>> Just bikeshedding, but before I went any further with it, I would
>> verify DSA_check_key(...) does *not* reject the key.
>>
>
> Doesn't the sessions with s_client/s_server and
> dsa verify (in the links) show this works in practice,
> no matter of your question?

I don't believe so. Its been my experience that very few
secure/high-integrity applications actually validate parameters out of
the box :(

In some cases, crypto parameters cannot be validated; for example,
those damn Lim-Lee primes. To validate a Lim-Lee prime, you need the
unique factorization of 'q' as a witness, which no one provides. (As
opposed to a Sophie-Germain or safe primes).

I also think the validation problems that plague high integrity
software makes ed25519 and friends so appealing. I think all of the
keys are valid, so you don't need to validate them.

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

Re: [openssl-users] Why openssl 1.0.1p accepts composite $q$ in DSA?

2015-09-09 Thread Viktor Dukhovni 
On Wed, Sep 09, 2015 at 02:46:05PM +0300, Georgi Guninski wrote:

> Is this ``issue'' real or imaginary according to developers, developers,
> developers(!) ?

On Wed, Sep 09, 2015 at 01:28:42PM +0300, Georgi Guninski wrote:

> In short openssl 1.0.1p accepts composite $q$
> in DSA verify/SSL.
> 
> On my blog I summarized with title:
> 
> RFC-2631, fips 186-3 and openssl's implementation of DSA appear broken
> (and possibly backdoored)
> 
> https://j.ludost.net/blog/archives/2015/09/05/rfc-2631_fips_186-3_and_openssls_implementation_of_dsa_appear_broken_and_possibly_backdoored/index.html

The backdoor assertion looks wrong, the check on the bit-length of
q is correct as required by the standards, and the subgroups in
question are not "small", rather they are commensurate with the
expected security level.  As for running primality tests, presumably
certificates signed by a trusted CA use a prime q.  If the certificate
is *not* signed by a trusted CA, of course the connection is not
secure...

You forgot to include the full context from the standard:

   ...

   Whether agents provide validation information in their certificates
   is a local matter between the agents and their CA.

The expected time for this sort of check is when CAs sign certificates,
not when TLS handshake participants validate the certificates of
their peers (issued by trusted issuers, or else why bother).

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

Re: [openssl-users] Why openssl 1.0.1p accepts composite $q$ in DSA?

2015-09-09 Thread Jeffrey Walton 
Hi Georgi,

Sorry to go offlist...

Also keep in mind that the IETF has effectively deprecated the DH
parameters in PKIX certificates. In fact, they moved to fixed DH
groups to avoid the option dance between client and server; and that
has the benefit that the parameters can be validated offline. As for
DSA, the IETF is killing it off, too.

See, for example,
https://tools.ietf.org/html/draft-gillmor-tls-negotiated-dl-dhe-00 and
https://www.ietf.org/mail-archive/web/tls/current/msg17489.html
(archive of latter at
https://www.ietf.org/mail-archive/web/tls/current/maillist.html).

Jeff

On Wed, Sep 9, 2015 at 6:28 AM, Georgi Guninski  wrote:
> In short openssl 1.0.1p accepts composite $q$
> in DSA verify/SSL.
>
> If $q$ is backdoored in the DSA/DH group parameters,
> this breaks all private keys using it (see links at
> bottom).
>
> On linux:
> $./apps/openssl s_server -accept 8080 -cert /tmp/cacert2.pem -key
> /tmp/key-comp2.key
>
> $./apps/openssl s_client -connect localhost:8080
>
> Verify return code: 18 (self signed certificate)
>
>
> $./apps/openssl x509 -text -in /tmp/cacert2.pem
> (make Q hex).
>
> In sage:
> sage: q=0x00801d812b
> sage: factor(q)
> 604462909807314587353111 * 1208925819614629174706189
>
> The self signed cert and key are attached.
>
> The discussion started on cypherpunks:
> https://cpunks.org/pipermail/cypherpunks/2015-September/009007.html
>
> On my blog I summarized with title:
>
> RFC-2631, fips 186-3 and openssl's implementation of DSA appear broken
> (and possibly backdoored)
>
> https://j.ludost.net/blog/archives/2015/09/05/rfc-2631_fips_186-3_and_openssls_implementation_of_dsa_appear_broken_and_possibly_backdoored/index.html
>
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Why openssl 1.0.1p accepts composite $q$ in DSA?

2015-09-09 Thread Georgi Guninski 
On Wed, Sep 09, 2015 at 11:55:36AM +, Viktor Dukhovni wrote:
> 
> The expected time for this sort of check is when CAs sign certificates,
> not when TLS handshake participants validate the certificates of
> their peers (issued by trusted issuers, or else why bother).
>

Are you saying I can't sign the cert with another cert
(the pubkey is easy to extract from the cert) with openssl?

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

Re: [openssl-users] Why openssl 1.0.1p accepts composite $q$ in DSA?

2015-09-09 Thread Georgi Guninski 
On Wed, Sep 09, 2015 at 07:45:16AM -0400, Jeffrey Walton wrote:
> Hi Georgi,
> 
> Sorry to go offlist...
> 
> Also keep in mind that the IETF has effectively deprecated the DH
> parameters in PKIX certificates. In fact, they moved to fixed DH
> groups to avoid the option dance between client and server; and that
> has the benefit that the parameters can be validated offline. As for
> DSA, the IETF is killing it off, too.
> 
> See, for example,
> https://tools.ietf.org/html/draft-gillmor-tls-negotiated-dl-dhe-00 and
> https://www.ietf.org/mail-archive/web/tls/current/msg17489.html
> (archive of latter at
> https://www.ietf.org/mail-archive/web/tls/current/maillist.html).
> 
> Jeff
>

10x, might try to see these later.

the issue appears still alive in openssl or am i
missing something?

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

[openssl-users] Why openssl 1.0.1p accepts composite $q$ in DSA?

2015-09-09 Thread Georgi Guninski 
In short openssl 1.0.1p accepts composite $q$
in DSA verify/SSL.

If $q$ is backdoored in the DSA/DH group parameters,
this breaks all private keys using it (see links at
bottom).

On linux:
$./apps/openssl s_server -accept 8080 -cert /tmp/cacert2.pem -key
/tmp/key-comp2.key

$./apps/openssl s_client -connect localhost:8080

Verify return code: 18 (self signed certificate)


$./apps/openssl x509 -text -in /tmp/cacert2.pem
(make Q hex).

In sage:
sage: q=0x00801d812b
sage: factor(q)
604462909807314587353111 * 1208925819614629174706189

The self signed cert and key are attached.

The discussion started on cypherpunks:
https://cpunks.org/pipermail/cypherpunks/2015-September/009007.html

On my blog I summarized with title:

RFC-2631, fips 186-3 and openssl's implementation of DSA appear broken
(and possibly backdoored)

https://j.ludost.net/blog/archives/2015/09/05/rfc-2631_fips_186-3_and_openssls_implementation_of_dsa_appear_broken_and_possibly_backdoored/index.html

-BEGIN CERTIFICATE-
MIIDWTCCAxmgAwIBAgIJANFIfLCCwmohMAkGByqGSM44BAMwRTELMAkGA1UEBhMC
QVUxEzARBgNVBAgMClNvbWUtU3RhdGUxITAfBgNVBAoMGEludGVybmV0IFdpZGdp
dHMgUHR5IEx0ZDAeFw0xNTA5MDUwNDU5MDhaFw0xNTEwMDUwNDU5MDhaMEUxCzAJ
BgNVBAYTAkFVMRMwEQYDVQQIDApTb21lLVN0YXRlMSEwHwYDVQQKDBhJbnRlcm5l
dCBXaWRnaXRzIFB0eSBMdGQwggH6MIIBWAYHKoZIzjgEATCCAUsCgZcPiGcA
AAADlG+9JEigmgAA

JwOatQAACP3Up7cAAFsia2LP
AhUAgAAAHYAAASsCgZcJ0Mj2s9j1N/CsS+vIqYa5k3wugZhu
yrgI1i+ZMmtqo7LrO49iH3YjnqRakj8ULK5mCzpSBR9KLBAlpO/1bmUHQc+231A1
71MfJ8M7rMQvn0mSKwIKSt9vdwRXv8cOIUiO3tP9ik1waHPM+EtoPAWhQwohG4wA
vPvONp9j3mXkvICvx2qQwBa5PeEupzYR66yUJATABKClA4GbAAKBlwrWl9e0mw+D
DEMMIjLRtfD4nJilQHF7cYHqhr6vJcFwYwkPuLyRZxokMHvOQmFH5XOdF9RG9Txt
nfYw0gbmmnEQPWOqId2AGd5VJRHeeVvd5SPWKwQzETp0NkpaQjreMgwEb28elDUP
xIvlT+/NOwjVVl/JiqrFDOIKEidQQxIVq227m60bvxbCymmUGOKMpNvy59dpUiyj
UDBOMB0GA1UdDgQWBBR86RWS1KB00TAlUbBQ5fvT+m/dZDAfBgNVHSMEGDAWgBR8
6RWS1KB00TAlUbBQ5fvT+m/dZDAMBgNVHRMEBTADAQH/MAkGByqGSM44BAMDLwAw
LAIUIgfVcrrQmbZ66mEuuovK1VMcw4gCFCIx+eoRWZKvFiuA6eBg++lN0uV9
-END CERTIFICATE-


key-comp2.key
Description: application/pgp-keys
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Why openssl 1.0.1p accepts composite $q$ in DSA?

2015-09-09 Thread Jeffrey Walton 
On Wed, Sep 9, 2015 at 6:28 AM, Georgi Guninski  wrote:
> In short openssl 1.0.1p accepts composite $q$
> in DSA verify/SSL.
>
> If $q$ is backdoored in the DSA/DH group parameters,
> this breaks all private keys using it (see links at
> bottom)...
>
Just bikeshedding, but before I went any further with it, I would
verify DSA_check_key(...) does *not* reject the key.

I can't find the name of the routine at the moment, though (I know its
called RSA_check_key for RSA).

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

Re: [openssl-users] Why openssl 1.0.1p accepts composite $q$ in DSA?

2015-09-09 Thread Georgi Guninski 
Ok, never mind.

Is this ``issue'' real or imaginary according to developers, developers,
developers(!) ?

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

Re: [openssl-users] Why openssl 1.0.1p accepts composite $q$ in DSA?

2015-09-09 Thread Viktor Dukhovni 
On Wed, Sep 09, 2015 at 03:17:01PM +0300, Georgi Guninski wrote:

> If I am CA and sign cert requests with vanilla openssl,
> will I sign a composite $q$?

The "openssl ca" command won't stop you from signing a non-prime
DSA $q$.  Real CAs need to do a lot more than is done in "openssl
ca".

No real public CAs issue DSA certificates.  Perhaps some internal
USG CAs issue DSA certificates.

What specific attack did you have in mind?  The MiTM obtains a weak
certificate from a trusted CA?  And then uses static DH_DSS with
a smooth $q$ allowing the attacker to recover the peer's ephemeral
DH private exponent?  What then?  The peer is now performing a
handshake with the authenticated MiTM, where's the attack against
a third party?

To make this interesting (not saying it is impossible, but no
evidence has been provided yet that anything interesting is afoot),
you need a more complete attack description than "OpenSSL accepts
non-prime $q$".

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

Re: [openssl-users] Why openssl 1.0.1p accepts composite $q$ in DSA?

2015-09-09 Thread Georgi Guninski 
On Wed, Sep 09, 2015 at 12:07:43PM +, Viktor Dukhovni wrote:
> > 
> > Are you saying I can't sign the cert with another cert
> > (the pubkey is easy to extract from the cert) with openssl?
> 
> If you control a trusted root CA, or an intermediate CA issued
> (possibly indirectly) by a trusted root CA, you can sign anything
> you want and it will be trusted.  The fact that malfeasant CAs can
> compromise security is not new.
> 
> If you don't control a trusted CA, what significance would such a
> signature carry?  Yes, most certificates (sometimes constrained by
> KeyUsage) can be used for signing, but unless "CA=true", they can't
> be used to sign other certificates that will be trusted by peers.
>

I am gonna leave this list very soon.

Feel free to CC me with answer:

If I am CA and sign cert requests with vanilla openssl,
will I sign a composite $q$?



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

Re: [openssl-users] Why openssl 1.0.1p accepts composite $q$ in DSA?

2015-09-09 Thread Erwann Abalea 
Bonjour,

> Le 9 sept. 2015 à 14:17, Georgi Guninski  a écrit :
> 
> On Wed, Sep 09, 2015 at 12:07:43PM +, Viktor Dukhovni wrote:
>>> 
>>> Are you saying I can't sign the cert with another cert
>>> (the pubkey is easy to extract from the cert) with openssl?
>> 
>> If you control a trusted root CA, or an intermediate CA issued
>> (possibly indirectly) by a trusted root CA, you can sign anything
>> you want and it will be trusted.  The fact that malfeasant CAs can
>> compromise security is not new.
>> 
>> If you don't control a trusted CA, what significance would such a
>> signature carry?  Yes, most certificates (sometimes constrained by
>> KeyUsage) can be used for signing, but unless "CA=true", they can't
>> be used to sign other certificates that will be trusted by peers.
>> 
> 
> I am gonna leave this list very soon.
> 
> Feel free to CC me with answer:
> 
> If I am CA and sign cert requests with vanilla openssl,
> will I sign a composite $q$?

If you’re a CA and sign cert requests, you’re responsible to check the public 
key you’re signing.
You could also sign an RSA key with e=1 or a dumb modulus, and it’s not a 
backdoor in RSA or OpenSSL.


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