[openssl-dev] Retrieving DSA public key (Y) in ASN.1 format
Douglas E Engert
deengert at gmail.com
Tue Dec 16 16:40:29 UTC 2014
On 12/16/2014 12:18 AM, Philip Prindeville wrote:
> Is there an easy way to get at the parameter ‘y’ (DSA->pub_key, which is a BIGNUM *) in ASN.1 format? (See (2) below…)
>
> Better yet, how to take that and pass it to ASN_item_digest()?
>
> Also, there’s some confusion (at least for me) about what constitutes DSAPublicKey. According to RFC-5912 you have:
>
> pk-dsa PUBLIC-KEY ::= {
> IDENTIFIER id-dsa
> KEY DSAPublicKey
> PARAMS TYPE DSA-Params ARE inheritable
> -- Private key format not in this module --
> CERT-KEY-USAGE { digitalSignature, nonRepudiation, keyCertSign,
> cRLSign }
> }
>
> id-dsa OBJECT IDENTIFIER ::= {
> iso(1) member-body(2) us(840) x9-57(10040) x9algorithm(4) 1 }
>
> DSA-Params ::= SEQUENCE {
> p INTEGER,
> q INTEGER,
> g INTEGER
> }
>
> DSAPublicKey ::= INTEGER -- public key, y
>
>
> so I’d assume that i2d_DSAPublicKey() would generate a DER string containing the serialization of a single ASN.1 object, i.e. the INTEGER containing ‘y’ or dsa->pub_key as the serialized ASN representation of that BIGNUM.
>
> Alas, it doesn’t.
I would assume it would do what you say. People confuse what is in a SubjectPublicKeyInfo
which includes an algorithm oid, parameters and the public key.
The same type of confusion can occur with ECC.
PKCS#15 has ASN.1 definitions that might help, and it referes to ANSI X9 documents.
>
> If I run test/dsatest for instance and I write out the generated DSA key, then parse it, I get:
>
> .++++++++++++++++++++++++++++++++++++++++++++++++++*
> ...+........+..+...+............+.+..+..........................................................................+++++++++++++++++++++++++++++++++++++++++++++++++++*
> seed
> D5014E4B 60EF2BA8 B6211B40 62BA3224 E0427DD3
> counter=105 h=2
> P:
> 00:8d:f2:a4:94:49:22:76:aa:3d:25:75:9b:b0:68:
> 69:cb:ea:c0:d8:3a:fb:8d:0c:f7:cb:b8:32:4f:0d:
> 78:82:e5:d0:76:2f:c5:b7:21:0e:af:c2:e9:ad:ac:
> 32:ab:7a:ac:49:69:3d:fb:f8:37:24:c2:ec:07:36:
> ee:31:c8:02:91
> Q:
> 00:c7:73:21:8c:73:7e:c8:ee:99:3b:4f:2d:ed:30:
> f4:8e:da:ce:91:5f
> G:
> 62:6d:02:78:39:ea:0a:13:41:31:63:a5:5b:4c:b5:
> 00:29:9d:55:22:95:6c:ef:cb:3b:ff:10:f3:99:ce:
> 2c:2e:71:cb:9d:e5:fa:24:ba:bf:58:e5:b7:95:21:
> 92:5c:9c:c4:2e:9f:6f:46:4b:08:8c:c5:72:af:53:
> e6:d7:88:02
>
>
> as the output of the program, and:
>
> $ openssl asn1parse -in dsa.der -inform DER -i
> 0:d=0 hl=3 l= 222 cons: SEQUENCE
> 3:d=1 hl=2 l= 64 prim: INTEGER :18CF7F66E23221AEA14DB900DA06BE46A91DF113D490C3C6A0C57EEAEE56DF1E9059A541445CFCBE1B63E8197199C0C9FD25A7CCE3354CC1077D577C3112A6CA
> 69:d=1 hl=2 l= 65 prim: INTEGER :8DF2A494492276AA3D25759BB06869CBEAC0D83AFB8D0CF7CBB8324F0D7882E5D0762FC5B7210EAFC2E9ADAC32AB7AAC49693DFBF83724C2EC0736EE31C80291
> 136:d=1 hl=2 l= 21 prim: INTEGER :C773218C737EC8EE993B4F2DED30F48EDACE915F
> 159:d=1 hl=2 l= 64 prim: INTEGER :626D027839EA0A13413163A55B4CB500299D5522956CEFCB3BFF10F399CE2C2E71CB9DE5FA24BABF58E5B79521925C9CC42E9F6F464B088CC572AF53E6D78802
> $
It is not clear to me where the above is defined.
>
> is the result of calling i2d_DSAPublicKey() and writing that to a file.
>
> Calling i2d_DSA_PUBKEY_fp() results in something else:
>
> $ openssl asn1parse -in dsa5.der -inform DER -i
> 0:d=0 hl=3 l= 240 cons: SEQUENCE
> 3:d=1 hl=3 l= 168 cons: SEQUENCE
> 6:d=2 hl=2 l= 7 prim: OBJECT :dsaEncryption
> 15:d=2 hl=3 l= 156 cons: SEQUENCE
> 18:d=3 hl=2 l= 65 prim: INTEGER :8DF2A494492276AA3D25759BB06869CBEAC0D83AFB8D0CF7CBB8324F0D7882E5D0762FC5B7210EAFC2E9ADAC32AB7AAC49693DFBF83724C2EC0736EE31C80291
> 85:d=3 hl=2 l= 21 prim: INTEGER :C773218C737EC8EE993B4F2DED30F48EDACE915F
> 108:d=3 hl=2 l= 64 prim: INTEGER :626D027839EA0A13413163A55B4CB500299D5522956CEFCB3BFF10F399CE2C2E71CB9DE5FA24BABF58E5B79521925C9CC42E9F6F464B088CC572AF53E6D78802
> 174:d=1 hl=2 l= 67 prim: BIT STRING
> $
That appears to be a SubjectPublicKeyInfo (SPKI) , with algorithm ID, parameters, and the public key in the bit string.
But as you say below, the bit string looks like a SPKI!
In PKCS#15 there is:
DSAPublicKeyChoice ::= CHOICE {
raw INTEGER,
spki SubjectPublicKeyInfo, -- See X.509. Must contain a public DSA key.
...
}
In PKCS#15 there is a choice like this for every type of public key.
But DSAPublicKeyChoice is not part SPKI. An SPKI should not include a SPKI of itself.
>
> Using dumpasn1 I find out that the BIT STRING at the end is actually:
>
> $ dumpasn1 -a -d -z -h -l dsa5.der
> <30 81 F0>
> 0 240: SEQUENCE {
> <30 81 A8>
> 3 168: . SEQUENCE {
> <06 07>
> 6 7: . . OBJECT IDENTIFIER dsa (1 2 840 10040 4 1)
> : . . . (ANSI X9.57 algorithm)
> <30 81 9C>
> 15 156: . . SEQUENCE {
> <02 41>
> 18 65: . . . INTEGER
> : . . . . 00 8D F2 A4 94 49 22 76 AA 3D 25 75 9B B0 68 69
> : . . . . CB EA C0 D8 3A FB 8D 0C F7 CB B8 32 4F 0D 78 82
> : . . . . E5 D0 76 2F C5 B7 21 0E AF C2 E9 AD AC 32 AB 7A
> : . . . . AC 49 69 3D FB F8 37 24 C2 EC 07 36 EE 31 C8 02
> : . . . . 91
> <02 15>
> 85 21: . . . INTEGER
> : . . . . 00 C7 73 21 8C 73 7E C8 EE 99 3B 4F 2D ED 30 F4
> : . . . . 8E DA CE 91 5F
> <02 40>
> 108 64: . . . INTEGER
> : . . . . 62 6D 02 78 39 EA 0A 13 41 31 63 A5 5B 4C B5 00
> : . . . . 29 9D 55 22 95 6C EF CB 3B FF 10 F3 99 CE 2C 2E
> : . . . . 71 CB 9D E5 FA 24 BA BF 58 E5 B7 95 21 92 5C 9C
> : . . . . C4 2E 9F 6F 46 4B 08 8C C5 72 AF 53 E6 D7 88 02
> : . . . }
> : . . }
> <03 43>
> 174 67: . BIT STRING, encapsulates {
> <02 40>
> 177 64: . . INTEGER
> : . . . 18 CF 7F 66 E2 32 21 AE A1 4D B9 00 DA 06 BE 46
> : . . . A9 1D F1 13 D4 90 C3 C6 A0 C5 7E EA EE 56 DF 1E
> : . . . 90 59 A5 41 44 5C FC BE 1B 63 E8 19 71 99 C0 C9
> : . . . FD 25 A7 CC E3 35 4C C1 07 7D 57 7C 31 12 A6 CA
> : . . }
> : . }
>
> 0 warnings, 0 errors.
>
> $
>
> which is DSA-Params (p, q, g) per RFC-5480. But I couldn’t find this construction anywhere.
>
> Oddly, though, if I define:
>
> int i2d_DSAPublicKey_fp(FILE *fp, DSA *dsa)
> {
> return ASN1_i2d_fp_of_const(DSA,i2d_DSAPublicKey,fp,dsa);
> }
>
> and call that, it correctly writes out ‘y’ (dsa->pub_key) as:
>
> $ openssl asn1parse -in dsa4.der -inform DER -i
> 0:d=0 hl=2 l= 64 prim: INTEGER :18CF7F66E23221AEA14DB900DA06BE46A91DF113D490C3C6A0C57EEAEE56DF1E9059A541445CFCBE1B63E8197199C0C9FD25A7CCE3354CC1077D577C3112A6CA
> $
>
> which I’m happy about, but don’t quite understand.
>
> So, a few questions:
>
> (1) what’s the quick way to, given a DSA *, compute a hash (given an EVP_MD *) over dsa->pub_key as an ASN.1 primitive? I tried:
>
> ASN1_item_digest(ASN1_ITEM_ref(BIGNUM), mdtype, dsa->pub_key, md, mdlen);
>
> but it’s giving me highly dubious results.
>
>
> (2) where is the ASN.1 module definition which corresponds to the format used by i2d_DSA_PUBKEY_fp()?
>
>
> (3) is there a way to generate a pk-dsa serialization in the library or do I have to muster this by hand?
>
>
> (4) why does i2d_DSAPublicKey() give you its current results and not the DER representation of ‘y’ (dsa->pub_key)?
>
>
> Thanks,
>
> -Philip
>
> _______________________________________________
> openssl-dev mailing list
> openssl-dev at openssl.org
> https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
>
--
Douglas E. Engert <DEEngert at gmail.com>
More information about the openssl-dev
mailing list