Re: [openssl-users] Why openssl 1.0.1p accepts composite $q$ in DSA?
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
Re: [openssl-users] Why openssl 1.0.1p accepts composite $q$ in DSA?
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?
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?
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?
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?
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?
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
Re: [openssl-users] Why openssl 1.0.1p accepts composite $q$ in DSA?
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?
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?
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?
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?
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
[openssl-users] Why openssl 1.0.1p accepts composite $q$ in DSA?
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