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@openssl.org
https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
--
Douglas E. Engert <deeng...@gmail.com>
_______________________________________________
openssl-dev mailing list
openssl-dev@openssl.org
https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
