[openssl-dev] Retrieving DSA public key (Y) in ASN.1 format

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

[openssl-dev] Retrieving DSA public key (Y) in ASN.1 format

Philip Prindeville
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.

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
$

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    
$

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
[hidden email]
https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: [openssl-dev] Retrieving DSA public key (Y) in ASN.1 format

Douglas E Engert


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
> [hidden email]
> https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
>

--

  Douglas E. Engert  <[hidden email]>

_______________________________________________
openssl-dev mailing list
[hidden email]
https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: [openssl-dev] Retrieving DSA public key (Y) in ASN.1 format

Dave Thompson-5
> From: openssl-dev On Behalf Of Douglas E Engert
> Sent: Tuesday, December 16, 2014 11:40

> 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: <snip>
> >     DSA-Params ::= <snip: p,q,g>
> >     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.
>
The OpenSSL implementation of DSAPublicKey has some arcana in it
that I haven't seen elsewhere. I suspect this may be because DSA was
the first parameterized (PK?) cipher and broke new territory. See below.

> PKCS#15 has ASN.1 definitions that might help, and it referes to ANSI X9
> documents. <snip>

> > If I run test/dsatest for instance and I write out the generated DSA
key,
> then parse it, I get <snip>

Note dsatest's main function is to test that the *parameter* generation
algorithm, specified by FIPS 186 to be reproducible and thus (provably?)
nothing-up-my-sleeve, works. For testing keys it would be simpler to just
use
some fixed (but valid) params.  But anyway:

> > $ 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
> :18CF7F66E23221AEA14DB900DA06BE46A91DF113D490C3C6A0C57EEAEE56
> DF1E9059A541445CFCBE1B63E8197199C0C9FD25A7CCE3354CC1077D577C3
> 112A6CA
> >     69:d=1  hl=2 l=  65 prim:  INTEGER
> :8DF2A494492276AA3D25759BB06869CBEAC0D83AFB8D0CF7CBB8324F0D7
> 882E5D0762FC5B7210EAFC2E9ADAC32AB7AAC49693DFBF83724C2EC0736E
> E31C80291
> >    136:d=1  hl=2 l=  21 prim:  INTEGER
> :C773218C737EC8EE993B4F2DED30F48EDACE915F
> >    159:d=1  hl=2 l=  64 prim:  INTEGER
> :626D027839EA0A13413163A55B4CB500299D5522956CEFCB3BFF10F399CE
> 2C2E71CB9DE5FA24BABF58E5B79521925C9CC42E9F6F464B088CC572AF53E
> 6D78802
> > $
>
> It is not clear to me where the above is defined.
>
> > is the result of calling i2d_DSAPublicKey() and writing that to a file.

HERE'S THE TRICKY BIT:

It's defined where you would expect, in dsa/dsa_asn1.c .
But it's defined as a "choice" that does either the standard INTEGER
(from internal BIGNUM) *OR* the above SEQUENCE which is named
'dsa_pub_internal' suggesting that it should be internal to OpenSSL
i.e. not interoperable or standard, but not explained that I can find.

Anyway, to get the standard form apparently you need to set
dsa->write_params to 0 (false) which is done *for the SPKI form*
in dsa_ameth.c dsa_pub_encode.

> > Calling i2d_DSA_PUBKEY_fp() results in something else: <snip>
> That appears to be a SubjectPublicKeyInfo (SPKI) , with algorithm ID,
> parameters, and the public key in the bit string.

Yes. PUBKEY is effectively the OpenSSL name for SPKI. There are also
RSA_PUBKEY,
EC_PUBKEY, and generic PUBKEY routines.

> But as you say below, the bit string looks like a SPKI!

No he doesn't and it doesn't.

> > 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
> >         : . . }
> >         : . }

See? Starting at 174 BITSTRING containing DER/BER for INTEGER.

> > 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: <snip
INTEGER>
> > which I'm happy about, but don't quite understand.
> >
For me that code writes the 'internal' SEQUENCE, consistent with others,
UNLESS I previously within the same program call i2d_DSA_PUBKEY
(perhaps indirectly such as PEM_write_PUBKEY) or clear write_params.
Did you maybe do the former of these?

> > 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.
> >
I wouldn't poke around in internals like that, I would just i2d to a buffer
and hash the buffer. 32 bytes of memory costs about $.000001 .
I'm not sure even bitcoin divides small enough to make that detectable.

(Alternatively one could get a cert for the key from a CA that uses SKId
which is conventionally the hash of the "raw" pubkey. <G><G><G>)

> > (2) where is the ASN.1 module definition which corresponds to the format
> used by i2d_DSA_PUBKEY_fp()?
> >
If you mean the ASN.1 source, RFC 5280 augmented by IIRC 3279,
which got them from (CCITT) X.509 and (ANSI) X9.something,
in addition to Douglas's answer of PKCS#15.

If you mean the data the OpenSSL code uses to do ASN.1,
generic PUBKEY=X509_PUBKEY=SPKI is in asn1/x_pubkey.c,
and the DSA-specific part is in dsa/dsa_asn1.c .

> > (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)?
> >
See above.


_______________________________________________
openssl-dev mailing list
[hidden email]
https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: [openssl-dev] Retrieving DSA public key (Y) in ASN.1 format

Dave Thompson-5
> [DSAPublicKey] defined where you would expect, in dsa/dsa_asn1.c .
> But it's defined as a "choice" that does either the standard INTEGER
> (from internal BIGNUM) *OR* the above SEQUENCE which is named
> 'dsa_pub_internal' suggesting that it should be internal to OpenSSL
> i.e. not interoperable or standard, but not explained that I can find.
>
> Anyway, to get the standard form apparently you need to set
> dsa->write_params to 0 (false) which is done *for the SPKI form*
> in dsa_ameth.c dsa_pub_encode.
>
Argh! Too obvious! It's in the manpage for i2d_DSAPublicKey
although IMO slightly overstated; the 0 format is standard AFAICT.


_______________________________________________
openssl-dev mailing list
[hidden email]
https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: [openssl-dev] Retrieving DSA public key (Y) in ASN.1 format

Philip Prindeville

On Dec 16, 2014, at 4:14 PM, Dave Thompson <[hidden email]> wrote:

>> [DSAPublicKey] defined where you would expect, in dsa/dsa_asn1.c .
>> But it's defined as a "choice" that does either the standard INTEGER
>> (from internal BIGNUM) *OR* the above SEQUENCE which is named
>> 'dsa_pub_internal' suggesting that it should be internal to OpenSSL
>> i.e. not interoperable or standard, but not explained that I can find.
>>
>> Anyway, to get the standard form apparently you need to set
>> dsa->write_params to 0 (false) which is done *for the SPKI form*
>> in dsa_ameth.c dsa_pub_encode.
>>
> Argh! Too obvious! It's in the manpage for i2d_DSAPublicKey
> although IMO slightly overstated; the 0 format is standard AFAICT.


Okay, so why does DSA_new_method() set write_params to 1?

-Philip

_______________________________________________
openssl-dev mailing list
[hidden email]
https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: [openssl-dev] Retrieving DSA public key (Y) in ASN.1 format

Philip Prindeville
In reply to this post by Dave Thompson-5

On Dec 16, 2014, at 3:34 PM, Dave Thompson <[hidden email]> wrote:

>
>>> 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.
>>>
> I wouldn't poke around in internals like that, I would just i2d to a buffer
> and hash the buffer. 32 bytes of memory costs about $.000001 .
> I'm not sure even bitcoin divides small enough to make that detectable.
>
> (Alternatively one could get a cert for the key from a CA that uses SKId
> which is conventionally the hash of the "raw" pubkey. <G><G><G>)


Well, I was hoping to upstream it into library so that if it uses the internals it shouldn’t be a bad thing.

I was likewise hoping to avoid any unnecessary copies, since I can think of at least one scenario where a large database of keys is loaded up at startup and then indexed by hash, so I don’t want to take longer than necessary generating those hashes.

-Philip

_______________________________________________
openssl-dev mailing list
[hidden email]
https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev