Jan 09, 2018  It’s using elliptic curve cryptography that offers a better security with faster performance compared to DSA or ECDSA. Today, the RSA is the most widely used public-key algorithm for SSH key. There is no way to generate a secure key-pair from the password 'puppies'. If you are using a 256-bit elliptic curve and want the full 128-bit security it can offer, any password from which you directly derive a key needs to have over 100 bits of entropy.

1. Ssh Generate Key Elliptic Curve Calculator
2. Elliptic Curve Key Length
3. Elliptic Curve Encryption Algorithm

OpenSSL provides two command line tools for working with keys suitable for Elliptic Curve (EC) algorithms:

The only Elliptic Curve algorithms that OpenSSL currently supports are Elliptic Curve Diffie Hellman (ECDH) for key agreement and Elliptic Curve Digital Signature Algorithm (ECDSA) for signing/verifying.

x25519, ed25519 and ed448 aren't standard EC curves so you can't use ecparams or ec subcommands to work with them. If you need to generate x25519 or ed25519 keys then see the genpkey subcommand.

EC Private Key File Formats[edit]

By default OpenSSL will work with PEM files for storing EC private keys. These are text files containing base-64 encoded data. A typical traditional format private key file in PEM format will look something like the following, in a file with a '.pem' extension:

Or, in an encrypted form like this:

You may also encounter PKCS8 format private keys in PEM files. These look like this:

Or, in an encrypted form like this:

PKCS8 private key files, like the above, are capable of holding many different types of private key - not just EC keys.

You can convert between these formats if you like. All of the conversion commands can read either the encrypted or unencrypted forms of the files however you must specify whether you want the output to be encrypted or not. To convert a PKCS8 file to a traditional encrypted EC format use:

You can replace the first argument 'aes-128-cbc' with any other valid openssl cipher name (see Manual:enc(1) for a list of valid cipher names). To convert a PKCS8 file to a traditional unencrypted EC format, just drop the first argument:

Or to convert from a traditional EC format to an encrypted PKCS8 format use:

Or to a non-encrypted PKCS8 format use:

Note that by default in the above traditional format EC Private Key files are not encrypted (you have to explicitly state that the file should be encrypted, and what cipher to use), whilst for PKCS8 files the opposite is true. The default is to encrypt - you have to explicitly state that you do not want encryption applied if appropriate using the '-nocrypt' option.

As well as PEM format all of the above types of key file can also be stored in DER format. This is a binary format and so is not directly human readable - unlike a PEM file. A PEM file is essentially just DER data encoded using base 64 encoding rules with a header and footer added. Often it is more convenient to work with PEM files for this reason.

The openssl commands typically have options '-inform DER' or '-outform DER' to specify that the input or output file is DER respectively. So for example the command to convert a PKCS8 file to a traditional encrypted EC format in DER is the same as above, but with the addition of '-outform DER':

Note that you cannot encrypt a traditional format EC Private Key in DER format (and in fact if you attempt to do so the argument is silently ignored!). The same is not true for PKCS8 files - these can still be encrypted even in DER format. So for example the following will convert a traditional format key file to an ecrypted PKCS8 format DER encoded key:

EC Public Key File Formats[edit]

EC Public Keys are also stored in PEM files. A typical EC public key looks as follows:

This format is used to store all types of public keys in OpenSSL not just EC keys.

It is possible to create a public key file from a private key file (although obviously not the other way around!):

As above a DER encoded version can be created using '-outform DER':

Generating EC Keys and Parameters[edit]

An EC Parameters file contains all of the information necessary to define an Elliptic Curve that can then be used for cryptographic operations (for OpenSSL this means ECDH and ECDSA). OpenSSL contains a large set of pre-defined curves that can be used. The full list of built-in curves can be obtained through the following command:

An EC parameters file can then be generated for any of the built-in named curves as follows:

Replace secp256k1 in the above with whichever curve you are interested in.

Keys can be generated from the ecparam command, either through a pre-existing parameters file or directly by selecting the name of the curve. To generate a private/public key pair from a pre-eixsting parameters file use the following:

Or to do the equivalent operation without a parameters file use the following:

Information on the parameters that have been used to generate the key are embedded in the key file itself.

By default, when creating a parameters file, or generating a key, openssl will only store the name of the curve in the generated parameters or key file, not the full set of explicit parameters associated with that name. For example:

This will simply confirm the name of the curve in the parameters file by printing out the following:

If you wish to examine the specific details of the parameters associated with a particular named curve then this can be achieved as follows:

The above command shows the details for a built-in named curve from a file, but this can also be done directly using the '-name' argument instead of '-in'. The output will look similar to the following:

The meaning of each of these parameters is discussed further on this page.

Parameters and key files can be generated to include the full explicit parameters instead of just the name of the curve if desired. This might be important if, for example, not all the target systems know the details of the named curve. In OpenSSL version 1.0.2 new named curves have been added such as brainpool512t1. Attempting to use a parameters file or key file in versions of OpenSSL less than 1.0.2 with this curve will result in an error:

This problem can be avoided if explicit parameters are used instead. So under OpenSSL 1.0.2 you could create a parameters file like this:

Looking at the parameters file you will notice that it is now much longer:

The full parameters are included rather than just the name. This can now be processed by versions of OpenSSL less than 1.0.2. So under 1.0.1:

This will correctly display the parameters, even though this version of OpenSSL does not know about this curve.

The same is true of key files. So to generate a key with explicit parameters:

This key file can now be processed by versions of openssl that do not know about the brainpool curve.

It should be noted however that once the parameters have been converted from the curve name format into explicit parameters it is not possible to change them back again, i.e. there is no utility to take a set of explicit parameters and work out which named curve they are associated with.

See also[edit]

Elliptic-curve Diffie–Hellman (ECDH) is a key agreement protocol that allows two parties, each having an elliptic-curve public–private key pair, to establish a shared secret over an insecure channel.^[1][2][3] This shared secret may be directly used as a key, or to derive another key. The key, or the derived key, can then be used to encrypt subsequent communications using a symmetric-key cipher. It is a variant of the Diffie–Hellman protocol using elliptic-curve cryptography.

Key establishment protocol[edit]

Ssh Generate Key Elliptic Curve Calculator

The following example illustrates how a shared key is established. Suppose Alice wants to establish a shared key with Bob, but the only channel available for them may be eavesdropped by a third party. Initially, the domain parameters (that is, ${\displaystyle (p,a,b,G,n,h)}$ in the prime case or ${\displaystyle (m,f(x),a,b,G,n,h)}$ in the binary case) must be agreed upon. Also, each party must have a key pair suitable for elliptic curve cryptography, consisting of a private key ${\displaystyle d}$ (a randomly selected integer in the interval ${\displaystyle [1,n-1]}$) and a public key represented by a point ${\displaystyle Q}$ (where ${\displaystyle Q=d\cdot G}$, that is, the result of adding${\displaystyle G}$ to itself ${\displaystyle d}$ times). Let Alice's key pair be ${\displaystyle (d_{\text{A}},Q_{\text{A}})}$ and Bob's key pair be ${\displaystyle (d_{\text{B}},Q_{\text{B}})}$. Each party must know the other party's public key prior to execution of the protocol.

Alice computes point ${\displaystyle (x_k,y_k)=d_{\text{A}}\cdot Q_{\text{B}}}$. Bob computes point ${\displaystyle (x_k,y_k)=d_{\text{B}}\cdot Q_{\text{A}}}$. The shared secret is ${\displaystyle x_k}$ (the x coordinate of the point). Most standardized protocols based on ECDH derive a symmetric key from ${\displaystyle x_k}$ using some hash-based key derivation function.

The shared secret calculated by both parties is equal, because ${\displaystyle d_{\text{A}}\cdot Q_{\text{B}}=d_{\text{A}}\cdot d_{\text{B}}\cdot G=d_{\text{B}}\cdot d_{\text{A}}\cdot G=d_{\text{B}}\cdot Q_{\text{A}}}$.

The only information about her key that Alice initially exposes is her public key. So, no party including Alice can determine Alice's private key (Alice of course knows it by having selected it), unless that party can solve the elliptic curve discrete logarithm problem. Bob's private key is similarly secure. No party other than Alice or Bob can compute the shared secret, unless that party can solve the elliptic curve Diffie–Hellman problem.

The public keys are either static (and trusted, say via a certificate) or ephemeral (also known as ECDHE, where final 'E' stands for 'ephemeral'). Ephemeral keys are temporary and not necessarily authenticated, so if authentication is desired, authenticity assurances must be obtained by other means. Authentication is necessary to avoid man-in-the-middle attacks. If one of either Alice's or Bob's public keys is static, then man-in-the-middle attacks are thwarted. Static public keys provide neither forward secrecy nor key-compromise impersonation resilience, among other advanced security properties. Holders of static private keys should validate the other public key, and should apply a secure key derivation function to the raw Diffie–Hellman shared secret to avoid leaking information about the static private key. For schemes with other security properties, see MQV.

If Alice maliciously chooses invalid curve points for her key and Bob does not validate that Alice's points are part of the selected group, she can collect enough residues of Bob's key to derive his private key. Several TLS libraries were found to be vulnerable to this attack.^[4]

While the shared secret may be used directly as a key, it can be desirable to hash the secret to remove weak bits due to the Diffie–Hellman exchange.

Software[edit]

• Curve25519 is a popular set of elliptic curve parameters and reference implementation by Daniel J. Bernstein in C. Bindings and alternative implementations are also available.
• LINE messenger app has used the ECDH protocol for its 'Letter Sealing' end-to-end encryption of all messages sent through said app since October 2015.^[5]
• Signal Protocol uses ECDH to obtain post-compromise security. Implementations of this protocol are found in Signal, WhatsApp, Facebook Messenger and Skype.

See also[edit]

References[edit]

Elliptic Curve Key Length

1. ^NIST, Special Publication 800-56A, Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography, March, 2006.
2. ^Certicom Research, Standards for efficient cryptography, SEC 1: Elliptic Curve Cryptography, Version 2.0, May 21, 2009.
3. ^NSA Suite B Cryptography, Suite B Implementers' Guide to NIST SP 800-56AArchived 2016-03-06 at the Wayback Machine, July 28, 2009.
4. ^Tibor Jager; Jorg Schwenk; Juraj Somorovsky (2015-09-04). 'Practical Invalid Curve Attacks on TLS-ECDH'(PDF). European Symposium on Research in Computer Security (ESORICS'15).
5. ^JI (13 October 2015). 'New generation of safe messaging: 'Letter Sealing''. LINE Engineers' Blog. LINE Corporation. Retrieved 5 February 2018.

Elliptic Curve Encryption Algorithm