I have a list of cipher suites in this format:


Is there a fast, easy way of translating it to more human readable/management readable format? :)


3 Answers 3


No, afaik.

Also, if it is supposed to be readable and helpful for non-tech people, each translation might be a book for itself, explaining each part of those strings, their up- and down sides in painful detail.

Just in case you didn't know, rfc 5246 currently covers this format and includes a table with cipher suites that might send you down a helpful track.

Your example


means "TLS using ECDHE_ECDSA with the elliptic curve P384 for key exchange, encrypting the connection using AES_256 in GCM while using SHA384 as PRF."

As you can see from following the links, there is no 'easy' understanding of the used acronyms themselves. Yet the general syntax is


As you see from my edit, the inference sometimes fails horribly, too;)


The IANA maintains the official registry for defined cipher suites. Each cipher suite is a 16-bit identifier; the "symbolic name" is not nominally standard; most implementations use the names indicated in the registry, but sometimes not, like OpenSSL. OpenSSL has its own naming scheme.

With the IANA registry, you can look up the cipher suite name, which will point you to the RFC that defines that specific cipher suite. It is still up to you to read that RFC to get the actual details.

Now the puzzler is that the string you give is not one of these semi-standard names. It has an extra "_P384" at the end. If you understand the underlying crypto, then you can infer that the "P384" suffix probably relates to NIST standard elliptic curve P-384, defined in FIPS 186-4. So your example, "TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384_P384", would be "TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384" as defined in RFC 5289, used with that elliptic curve.

Inferences can only get you so far. The "TLS_ECDHE_ECDSA" prefix means that the key exchange will use ECDHE (Elliptic-Curve Diffie-Hellman, Ephemeral) and the server will sign its half of ECDHE with its permanent private key (the one corresponding to the public key in the server certificate), and that signature will use ECDSA, a signature algorithm that operates in an elliptic curve. It is unclear whether the "P384" suffix designates the elliptic curve for ECDHE, for ECDSA, or for both (I suspect it is only for ECDHE, but that's just a hunch). This is the problem with non-standard terminology.

Thus, the source of information for understanding your cipher suite names should be the documentation for the tool that produces or consumes these names. Failing that, you are back to making your own conclusions.


There is no way of translating it to more human readable/management readable format but there is a cipher suite “translator”.

There is a simple way to convert any OpenSSL (or GnuTLS, NSS, etc.) cipher name into IANA/standard/RFC cipher names or hexadecimal codepoints or teh other way around by using tls-map library in ruby:

require 'tls_map'

tm = TLSmap::App.new

# OpenSSL -> IANA
tm.search(:openssl, 'AES128-SHA', :iana) #=> {:iana=>"TLS_RSA_WITH_AES_128_CBC_SHA"}
# Hexadecimal codepoint to all (including OpenSSL & IANA)
tm.search(:codepoint, '1303') #=> {:codepoint=>"1303", :iana=>"TLS_CHACHA20_POLY1305_SHA256", :openssl=>"TLS_CHACHA20_POLY1305_SHA256", :gnutls=>"CHACHA20_POLY1305_SHA256", :nss=>"TLS_CHACHA20_POLY1305_SHA256"}

It's also available as a CLI tool:

$ tls-map search openssl AES128-SHA -o iana

So basically a more human readable/management readable format could be to use hexadecimal codepoint for humans (much shorter and easy to remember) and translate it back to IANA name for programming usage.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .