# Cipher Suite Decoder

> Enter a TLS cipher suite, as an IANA name, an OpenSSL or GnuTLS name, or a hex code point, to break it into its key exchange, authentication, cipher, mode, and MAC, with a plain-language security read-out and the official IANA recommendation. Runs entirely in your browser against a bundled copy of the IANA registry.

- Tool: https://ronutz.com/en/tools/cipher
- Family: TLS & transport

---

## What it does

Enter a TLS cipher suite, whether as its IANA name, an OpenSSL or GnuTLS name, or a hex code point, and the tool breaks it into its parts, the key exchange, the authentication, the bulk cipher and mode, and the MAC, and gives a plain-language security read-out along with the suite's official IANA recommendation status. It runs in your browser against a bundled copy of the IANA registry.

## Reading a cipher suite name

A cipher suite is a named bundle of the algorithms a TLS connection will use, and the name is structured. In TLS 1.2 and earlier, a name like `TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256` reads as its parts: `ECDHE` is the key-exchange method, `RSA` is how the server is authenticated, `AES_128_GCM` is the bulk cipher with its key size and mode, and `SHA256` is the MAC and PRF hash. TLS 1.3 changed this: a 1.3 suite like `TLS_AES_128_GCM_SHA256` names only the symmetric cipher and the hash, because the key exchange is always ephemeral and is negotiated separately. The tool parses either form into its components.

## Names, code points, and the registry

The same suite has different names in different tools, with a numeric code point underneath them all. The authoritative source is the IANA TLS Cipher Suites registry, which maps each two-byte code point to its name and carries the **Recommended** flag (Y, N, or D for discouraged, per RFC 8447). The tool resolves whatever you type, an IANA name, an OpenSSL or GnuTLS name, or the raw hex code point, back to that registry record, so you can move between the spelling one tool shows and the one another expects.

## The security read-out

Knowing the parts, the tool can judge the suite, and it flags the known-bad and the weak on a standards basis rather than by opinion: RC4 suites are insecure (RFC 7465), 3DES suites are weak because of the Sweet32 attack (RFC 8429), and it reflects the registry's own not-recommended entries. It also recognizes modern choices, including the authenticated-encryption modes (GCM and ChaCha20-Poly1305) and the post-quantum hybrid key-exchange groups built on ML-KEM (NIST FIPS 203).

## Using it

Enter a cipher suite in any common form and read its decoded key exchange, authentication, cipher, mode, and MAC, its IANA recommendation status, and the security assessment. The decode is deterministic and entirely local.

## Standards and references

- [IANA TLS Cipher Suites registry](https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4) - authoritative code point ↔ name mapping, the Recommended and DTLS-OK flags, and references
- [RFC 8446 - The Transport Layer Security (TLS) Protocol Version 1.3](https://www.rfc-editor.org/rfc/rfc8446) - TLS 1.3 cipher-suite form (symmetric cipher + hash only); ephemeral key exchange
- [RFC 5246 - The Transport Layer Security (TLS) Protocol Version 1.2](https://www.rfc-editor.org/rfc/rfc5246) - the KX_AUTH_WITH_CIPHER_MAC suite structure for TLS 1.2 and earlier
- [RFC 8447 - IANA Registry Updates for TLS and DTLS](https://www.rfc-editor.org/rfc/rfc8447) - meaning of the "Recommended" column (Y / N / D); CCM_8 not recommended
- [RFC 7465 - Prohibiting RC4 Cipher Suites](https://www.rfc-editor.org/rfc/rfc7465) - basis for rating any RC4 suite insecure
- [RFC 8429 - Deprecate Triple-DES (3DES) and IDEA Cipher Suites for TLS](https://www.rfc-editor.org/rfc/rfc8429) - basis for rating 3DES (Sweet32) and IDEA suites weak
- [IANA TLS Supported Groups registry](https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-8) - authoritative code point ↔ name mapping for named groups, including the ML-KEM hybrids and the obsolete pre-standard groups
- [draft-ietf-tls-ecdhe-mlkem - Post-quantum hybrid ECDHE-MLKEM Key Agreement for TLS 1.3](https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-mlkem) - defines X25519MLKEM768, SecP256r1MLKEM768, SecP384r1MLKEM1024; their code points, share sizes, and Recommended flags
- [RFC 7919 - Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for TLS](https://www.rfc-editor.org/rfc/rfc7919) - the ffdhe2048..ffdhe8192 named groups and their code points
- [NIST FIPS 203 - Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM)](https://csrc.nist.gov/pubs/fips/203/final) - the ML-KEM standard (2024) that the hybrid groups embed; basis for the post-quantum status
- [ciphersuite.info - cipher suite catalogue](https://ciphersuite.info/) - OpenSSL and GnuTLS cross-names (the IANA registry lists neither)

## Related reading

- [AEAD vs CBC: Why the Mode Matters](https://ronutz.com/en/learn/aead-vs-cbc.md): The practical difference between an AEAD cipher like AES-GCM and an older CBC cipher with a separate HMAC, the padding-oracle attacks that killed MAC-then-encrypt, and the one tradeoff AEAD still asks you to make.
- [Anatomy of a TLS Cipher Suite](https://ronutz.com/en/learn/cipher-suite-anatomy.md): What a TLS cipher suite actually names, how to read a suite like TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 piece by piece, and how the same two-byte code point shows up under three different naming conventions.
- [Forward Secrecy and the Key Exchange](https://ronutz.com/en/learn/forward-secrecy.md): What forward secrecy buys you, why static RSA key transport does not provide it, how ECDHE and DHE do, and why authentication and key exchange are two separate jobs that a suite name keeps distinct.
- [Inbound TLS: Offload, Bridging, and Passthrough at the Reverse Proxy](https://ronutz.com/en/learn/tls-reverse-proxy-inbound.md): A reverse proxy handling inbound HTTPS has three choices for the TLS session: terminate it and send plaintext to the backend (offload), terminate and re-encrypt to the backend (bridging), or forward the encrypted bytes untouched (passthrough). Each trades visibility against confidentiality and cost differently. This explains all three, why the proxy holds the server's certificate, and what SNI and mutual TLS change.
- [Post-Quantum TLS on BIG-IP: ML-KEM Hybrids From 17.5 to 21.1](https://ronutz.com/en/learn/bigip-post-quantum-tls.md): BIG-IP's post-quantum story is a lineage: X25519MLKEM768 hybrid key exchange arrived in the 17.5.0 era, and 21.1.0 completes the NIST curve family with SecP256r1MLKEM768 and SecP384r1MLKEM1024, on both client-side and server-side TLS, per FIPS 203. Around it, 21.1 makes the classical side faster and stricter: X25519 hardware acceleration via Intel QAT on by default, parent SSL profiles defaulting to TLS 1.3 and DTLS 1.2, an OCSP request nonce, and C3D enhancements. Here is what each piece means and how to roll it out without breaking a single legacy client.
- [Reading Cipher Suite Names: IANA, OpenSSL, and GnuTLS](https://ronutz.com/en/learn/cipher-suite-naming.md): Why the same cipher suite has three different names and a two-byte code point, how to translate between the IANA, OpenSSL, and GnuTLS conventions, and what the IANA Recommended column of Y, N, and D actually means.
- [SSL Forward Proxy: How Outbound TLS Interception Works and What Breaks It](https://ronutz.com/en/learn/ssl-forward-proxy-interception.md): To inspect encrypted outbound traffic, a forward proxy performs a controlled man-in-the-middle: it terminates the user's TLS session, opens its own to the real server, and forges a certificate for that server signed by a private CA the organization's own devices trust. This explains the mechanics, the trust model that makes it safe (and dangerous), and why pinning, HSTS, and mutual TLS defeat it.
- [TLS 1.3 Cipher Suites: What Changed](https://ronutz.com/en/learn/tls13-cipher-suites.md): Why a TLS 1.3 suite names only a cipher and a hash, where the key exchange and authentication went, and why the list of suites shrank from hundreds to a handful.