> 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