[erlang-questions] Handshake failure with DHE-DSS cipher suites

Per Hedeland per@REDACTED
Tue May 15 18:12:51 CEST 2018


On 2018-05-15 15:08, Ingela Andin wrote:
> Hi!
> 
> I think that the oid is missing due to an oversight in adding it when crypto was updated to support it. For some reason (which I do not know)  early versions of crypto did only
> support sha1 (sha) with dsa.

Afer further digging, I think it's just a matter of "evolution" - the
'id-dsa-with-sha1' oid is defined in asn1/PKIX1Algorithms88.asn1, but
'id-dsa-with-sha256' is a more recent thing, and neither defined there
nor in any of the other modules i the asn1 directory, and I'm not sure
it "belongs" in any of them.

The definitions that can be found on the 'net agree on the numerical oid
elements, but there are actually at least two variants on the
(irrelevant here) naming of them - the one under "DSA with SHA-2 family"
on
https://csrc.nist.gov/Projects/Computer-Security-Objects-Register/Algorithm-Registration
seems pretty authoritative to me:-), but it's not given as part of any
ASN.1 module AFAIU. However
https://www.itu.int/ITU-T/formal-language/itu-t/x/x509/2016/AlgorithmObjectIdentifiers.html
seems to do that, with a module that also includes most but not all of
the definitions that are handled by public_key:pkix_sign_types/1...

> The correct oid name should be in the generated include file included in public_key.hrl 

Well it isn't, since it isn't defined in any of the modules in the asn1
directory. But anyway, just dropping the definition from above into the
one of them that seems to have most of the definitions handled by
pkix_sign_types/1 makes for a slighly nicer diff (below).

> Without looking into this further, I suspect that  the passing of the suites, could be due to that the  actual sha function used is a result of the "hash_sign negotiation"  that depends on the
> hash_sign hello extension.

I'm not worried by that:-), but I'd like to make the DHE-DSS suites
work. I'll go with the below diff for now, but maybe OTP will fix it
"properly" in some future version?

--Per

diff --git a/lib/public_key/asn1/PKCS-1.asn1 b/lib/public_key/asn1/PKCS-1.asn1
index 117eacd..1df6719 100644
--- a/lib/public_key/asn1/PKCS-1.asn1
+++ b/lib/public_key/asn1/PKCS-1.asn1
@@ -87,6 +87,12 @@ id-sha512  OBJECT IDENTIFIER  ::=  { joint-iso-itu-t(2)
         nistalgorithm(4) hashalgs(2) 3 }


+-- This probably doesn't belong here, but...
+id-dsa-with-sha256  OBJECT IDENTIFIER  ::=  { joint-iso-itu-t(2)
+        country(16) us(840) organization(1) gov(101) csor(3)
+        nistalgorithm(4) sigalgs(3) 2 }
+
+
 RSAPublicKey ::= SEQUENCE {
     modulus           INTEGER,  -- n
     publicExponent    INTEGER   -- e
diff --git a/lib/public_key/src/public_key.erl b/lib/public_key/src/public_key.erl
index 0341266..75305cb 100644
--- a/lib/public_key/src/public_key.erl
+++ b/lib/public_key/src/public_key.erl
@@ -498,6 +498,8 @@ pkix_sign_types(?'id-dsa-with-sha1') ->
     {sha, dsa};
 pkix_sign_types(?'id-dsaWithSHA1') ->
     {sha, dsa};
+pkix_sign_types(?'id-dsa-with-sha256') ->
+    {sha256, dsa};
 pkix_sign_types(?'ecdsa-with-SHA1') ->
     {sha, ecdsa};
 pkix_sign_types(?'ecdsa-with-SHA256') ->



More information about the erlang-questions mailing list