# Decodificador de suítes de cifra

> Informe uma suíte de cifra TLS, como nome IANA, nome OpenSSL ou GnuTLS, ou um ponto de código hexadecimal, para destrinchá-la em troca de chaves, autenticação, cifra, modo e MAC, com uma leitura de segurança em linguagem clara e a recomendação oficial da IANA. Roda inteiramente no seu navegador contra uma cópia embutida do registro da IANA.

- Tool: https://ronutz.com/pt-BR/tools/cipher
- Family: TLS e transporte

---

## O que faz

Informe uma suíte de cifra TLS, seja como seu nome IANA, um nome OpenSSL ou GnuTLS, ou um ponto de código hexadecimal, e a ferramenta a divide em suas partes, a troca de chaves, a autenticação, a cifra e o modo, e o MAC, e dá uma leitura de segurança em linguagem clara junto com o status de recomendação oficial da IANA da suíte. Ela roda no seu navegador contra uma cópia embutida do registro da IANA.

## Lendo o nome de uma suíte de cifra

Uma suíte de cifra é um pacote nomeado dos algoritmos que uma conexão TLS vai usar, e o nome é estruturado. No TLS 1.2 e anteriores, um nome como `TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256` se lê por suas partes: `ECDHE` é o método de troca de chaves, `RSA` é como o servidor é autenticado, `AES_128_GCM` é a cifra com seu tamanho de chave e modo, e `SHA256` é o MAC e o hash da PRF. O TLS 1.3 mudou isso: uma suíte 1.3 como `TLS_AES_128_GCM_SHA256` nomeia apenas a cifra simétrica e o hash, porque a troca de chaves é sempre efêmera e é negociada separadamente. A ferramenta analisa qualquer uma das duas formas em seus componentes.

## Nomes, pontos de código e o registro

A mesma suíte tem nomes diferentes em ferramentas diferentes, com um ponto de código numérico por baixo de todos eles. A fonte autoritativa é o registro IANA TLS Cipher Suites, que mapeia cada ponto de código de dois bytes para seu nome e carrega o sinalizador **Recommended** (Y, N ou D para discouraged, conforme a RFC 8447). A ferramenta resolve o que você digitar, um nome IANA, um nome OpenSSL ou GnuTLS, ou o ponto de código hexadecimal bruto, de volta para aquele registro, para que você possa transitar entre a grafia que uma ferramenta mostra e a que outra espera.

## A leitura de segurança

Conhecendo as partes, a ferramenta consegue julgar a suíte, e sinaliza as sabidamente ruins e as fracas com base em padrões, e não em opinião: suítes RC4 são inseguras (RFC 7465), suítes 3DES são fracas por causa do ataque Sweet32 (RFC 8429), e ela reflete as próprias entradas não recomendadas do registro. Ela também reconhece escolhas modernas, incluindo os modos de criptografia autenticada (GCM e ChaCha20-Poly1305) e os grupos de troca de chaves híbridos pós-quânticos construídos sobre o ML-KEM (NIST FIPS 203).

## Como usar

Informe uma suíte de cifra em qualquer forma comum e leia sua troca de chaves, autenticação, cifra, modo e MAC decodificados, seu status de recomendação da IANA e a avaliação de segurança. A decodificação é determinística e inteiramente 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: por que o modo importa](https://ronutz.com/pt-BR/learn/aead-vs-cbc.md): A diferença prática entre uma cifra AEAD como o AES-GCM e uma cifra CBC mais antiga com um HMAC separado, os ataques de oráculo de preenchimento que mataram o MAC-then-encrypt, e a única troca que o AEAD ainda pede.
- [Anatomia de uma suíte de cifra TLS](https://ronutz.com/pt-BR/learn/cipher-suite-anatomy.md): O que uma suíte de cifra TLS realmente nomeia, como ler uma suíte como TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 parte por parte, e como o mesmo ponto de código de dois bytes aparece sob três convenções de nomes diferentes.
- [Lendo nomes de suítes de cifra: IANA, OpenSSL e GnuTLS](https://ronutz.com/pt-BR/learn/cipher-suite-naming.md): Por que a mesma suíte de cifra tem três nomes diferentes e um ponto de código de dois bytes, como traduzir entre as convenções da IANA, do OpenSSL e do GnuTLS, e o que a coluna Recommended da IANA, com Y, N e D, realmente significa.
- [Sigilo de encaminhamento e a troca de chaves](https://ronutz.com/pt-BR/learn/forward-secrecy.md): O que o sigilo de encaminhamento garante, por que o transporte de chave RSA estático não o oferece, como ECDHE e DHE oferecem, e por que autenticação e troca de chaves são duas tarefas distintas que o nome de uma suíte mantém separadas.
- [SSL Forward Proxy: Como Funciona a Interceptação de TLS de Saída e o Que a Quebra](https://ronutz.com/pt-BR/learn/ssl-forward-proxy-interception.md): Para inspecionar tráfego de saída criptografado, um forward proxy realiza um man-in-the-middle controlado: ele termina a sessão TLS do usuário, abre a sua própria para o servidor real, e forja um certificado para aquele servidor assinado por uma CA privada em que os próprios dispositivos da organização confiam. Este artigo explica a mecânica, o modelo de confiança que o torna seguro (e perigoso), e por que pinning, HSTS e TLS mútuo o derrotam.
- [Suítes de cifra do TLS 1.3: o que mudou](https://ronutz.com/pt-BR/learn/tls13-cipher-suites.md): Por que uma suíte de TLS 1.3 nomeia apenas uma cifra e um hash, para onde foram a troca de chaves e a autenticação, e por que a lista de suítes encolheu de centenas para um punhado.
- [TLS de Entrada: Offload, Bridging e Passthrough no Reverse Proxy](https://ronutz.com/pt-BR/learn/tls-reverse-proxy-inbound.md): Um reverse proxy que trata HTTPS de entrada tem três escolhas para a sessão TLS: terminá-la e enviar texto claro ao backend (offload), terminar e recriptografar até o backend (bridging), ou encaminhar os bytes criptografados intocados (passthrough). Cada uma equilibra visibilidade contra confidencialidade e custo de forma diferente. Este artigo explica as três, por que o proxy detém o certificado do servidor, e o que o SNI e o TLS mútuo mudam.
- [TLS pós-quântico no BIG-IP: híbridos ML-KEM do 17.5 ao 21.1](https://ronutz.com/pt-BR/learn/bigip-post-quantum-tls.md): A história pós-quântica do BIG-IP é uma linhagem: a troca de chaves híbrida X25519MLKEM768 chegou na era do 17.5.0, e o 21.1.0 completa a família de curvas NIST com SecP256r1MLKEM768 e SecP384r1MLKEM1024, no TLS do lado do cliente e do lado do servidor, conforme o FIPS 203. Ao redor, o 21.1 torna o lado clássico mais rápido e mais estrito: aceleração de hardware do X25519 via Intel QAT ligada por padrão, perfis SSL pai com padrão TLS 1.3 e DTLS 1.2, nonce em requisições OCSP e melhorias no C3D. Aqui está o que cada peça significa e como implantar sem quebrar um único cliente legado.