> From: owner-openssl-us...@openssl.org On Behalf Of Dr. Stephen Henson
> Sent: Tuesday, 18 June, 2013 13:40
To add some more:
> On Tue, Jun 18, 2013, Aleix Ventayol wrote:
>
> > Hi everyone,
> >
> > I'm using a Diffie Hellman Agreemant on one app. I've been able to
generate
> > the DH without any problems, but now I should send the DH information to
> > the server.
> >
> > We've an example of the same process written in Java, what this app
> > generates to send to the client is:
> >
Your app sends to the server but the "same process" in Java sends to
the client? Is the Java process actually the server? For the DH
algorithm the two parties are symmetric, but when embedded in a
protocol who sends what and when to whom can matter.
> > SEQUENCE {
> > SEQUENCE {
> > OBJECTIDENTIFIER 1.2.840.113549.1.3.1
> > SEQUENCE { <snip: INTEGER p and g> }
> > }
> > BITSTRING <snip: DER of INTEGER y>
That format is the SubjectPublicKeyInfo format defined by X.509
and included in an X.509 cert, and also used locally by openssl.
It supports multiple algorithms so it has an OID to identify the
algorithm, conditionally parameters which for DH are integers p and g,
and wrapped in a bitstring the actual key value which for DH is y.
> > >From my c++ app I try to get the same information using
> > PEM_write_bio_DHparams. I get almost the same but without the BITSTRING
> > and the OBJECTIDENTIFIER. <snip>
> >
> > I've seen that Java version generates a X.509 certificate to send the
data,
> > maybe I should generate a X509 certificate from the DH on my c++
version?
> >
> >
>
> The DH_* functions don't support encoding of public and private keys,
> PEM_write_bio_DHparams just writes DH parameters instead.
>
Exactly. write__DHparams writes the parameters part of the PubKeyInfo.
> If you use the higher level EVP_PKEY API and something like
> i2d_PUBKEY it should produce that format.
If you need just the key value (in pretty-standard form) yes.
If the Java version is producing a cert is because the peer(?)
*wants* a cert, then you may need to produce a cert also.
If your peer is the "process ... in Java", or any Java process
you can work on, Java/JCE code can handle a DH public key in
PubKeyInfo format as well as cert, but using different routines:
(DHPublicKey extends PublicKey).getEncoded() on output and
KeyFactory.getInstance("DH").generatePublic (X509EncodedKeySpec
created from the data) on input. Of course if it is using the
other cert fields for anything, or relying on CA issuance of
the cert as a trust check, then you need the cert.
If you do need to create a cert yourself, look at the Java example
and/or any specs you have to see what you need for the issuer name
and signing key -- normally tied together by an issuer cert --
and what you need or can use for subject, validity, version, and
extensions (if any, only if version 3 but that is common today).
Generally each of these is pretty straightforward but together
they can be a bit of work. Alternatively if the Java example is
getting the cert from a CA (maybe an internal e.g. company one)
you may need to do the same by instead creating a CSR and
submitting that to the CA.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
