> From: owner-openssl-...@openssl.org On Behalf Of redpath
> Sent: Monday, 03 September, 2012 07:45
> Well thats what I thought it seems to have its own keys but I
> saw functions
> such as setting the points and BIGNUM and thought maybe the
> PEM could be
> used which uses 2048 RSA.
>
PEM is a format used for many kinds of data in OpenSSL.
An RSA key, in PEM or DER format, can be used for RSA.
An EC key, in PEM or DER format, can be used for ECDSA/ECDH.
> So essentially I would have a set of ECKEYS just for the
> ECDSA. There is a
> public eckey and private eckey
> and those are written to a file I assume but with what
> functions and also
> how to use the functions when reading from a file of the keys (Best
> Practices).
>
Yes. Or more specifically, one keypair.
> I see there is this output/input function as an Octet just for public
>
> int i2o_ECPublicKey ( EC_KEY * key,
> unsigned char ** out
> )
>
> EC_KEY* o2i_ECPublicKey ( EC_KEY ** key,
> const unsigned char ** in,
> long len
> )
>
As a series of octets (aka bytes). This actually formats or parses
only the public point, with the curve known. This is used in SSL
(or rather TLS) for online ECDH, because that transmits the curve
separately and only in one direction. For signing, where
verification is expected to be a different system and often later,
it is usually better to have the complete public key: parameters
(usually just identifier of standard curve) plus public point.
For RSA and DSA, OpenSSL supports public keys in (original)
per-algorithm formats named like {i2d,d2i}_RSAPublicKey_* and
PEM_{write,read}_*_RSAPublicKey, and in the generic PublicKeyInfo
format defined by X.509 named like {i2d,d2i}_RSA_PUBKEY_* and
PEM_{write,read}_*_RSA_PUBKEY, or that format using a generic
internal struct (EVP_PKEY) named just PUBKEY. For EC it does
only PUBKEY format, which is the more general and now preferred.
Note some of these names are not directly visible/searchable
in the *.h files because they are declared by C macros like
DECLARE_PEM_rw_cb(ECPrivateKey, EC_KEY)
> And the private keys seems to indicate a DER
>
> EC_KEY* d2i_ECPrivateKey ( EC_KEY ** key,
> const unsigned char ** in,
> long len
> )
>
> I assume the output here is DER though it does not say it.
>
> int i2d_ECPrivateKey ( EC_KEY * key,
> unsigned char ** out
> )
>
Yes. i2d means internal-to-DER, and d2i means DER-to-internal.
Similarly, OpenSSL supports both per-algorithm formats using
names like RSAPrivateKey, and a generic format defined by PKCS#8
using the generic EVP_PKEY struct named PKCS8PrivateKey .
Since 1.0.0 the PKCS#8 format is considered preferred, but
the per-algorithm formats are still supported.
> (1) So what is the Best Practices then after a key has been
> generated I can
> save to a file (Best Practices, private and public files?)
> and then I can
> read from a file a public or a private key (Best Practices?)
> Basically I am
> interested in saving the private key for generation and
> handing out the
> public for verifying.
>
For all of RSA, DSA/DH, and EC, OpenSSL uses a privatekey (or
keypair) format that includes the publickey information, so you
don't usually need to store a publickey by itself in a file
unless you distribute it that way. But it is more common to
distribute a publickey in an X.509 certificate which provides
integrity and (some) authenticity for it. Thus you typically
have a privatekey (or keypair) file, preferably encrypted if
there is any risk of an adversary seeing the file or a backup;
a Certificate Signing Request CSR which is generated from the
privatekey among other things and includes the publickey among
other things; and a certificate which is generated from the CSR
and contains the publickey among other things. Once you have the
cert you no longer need and can delete the CSR. Or if your reliers
trust your files enough, OpenSSL can generate a selfsigned cert
(containing publickey) in one step, with no CSR. A selfsigned cert
provides no authenticity in itself, but it does prevent tampering
and it piggybacks on the ability of most software to read certs.
> By the way this is where I go for doc on ECKEY
>
> http://openssl.sourcearchive.com/documentation/1.0.0e-2/crypto
> _2ec_2ec_8h_a1a93f5739c093586ef83517b52b44a0c.html#a1a93f5739c
093586ef83517b52b44a0c
>
That appears to be derived from the source (presumably 1.0.0e).
I just use the source, and the man pages -- but the man page
coverage is not complete, and relatively newer parts like EC
seem on average to have poorer man page coverage.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
