Resumo

  • O RFC 3526 registra o grupo 5 de 1536 bits e define os grupos MODP 14 a 18, de 2048 a 8192 bits, para IKE. O próprio documento não converte cada tamanho em força AES garantida e exige que o expoente não se torne o elo fraco.
  • A prova operacional precisa incluir política, entropia e frescor privados, teste do valor público recebido, autenticação, suite inteira, rotação, destruição e entrega observada. O número do grupo confirma parâmetros, não toda a execução.

Tamanho é uma especificação que cabe numa linha. Entropia é uma propriedade de um acontecimento. A primeira pode ser conferida no RFC; a segunda depende de como uma máquina produziu um segredo num instante que não se repete.

Misturar as duas cria uma forma elegante de falsa segurança. O fornecedor mostra o maior módulo, o controle marca conformidade e ninguém pergunta qual gerador funcionou, se o valor remoto foi validado ou quem foi autenticado.

Publicado em maio de 2003 no Standards Track e hoje registrado como Proposed Standard, o RFC 3526 organiza parâmetros compartilhados. Não certifica uma máquina.

O catálogo torna a matemática comum

O documento formaliza o grupo 5 de 1536 bits, já usado, e atribui 14, 15, 16, 17 e 18 aos tamanhos 2048, 3072, 4096, 6144 e 8192. Os primos são publicados e o gerador é 2.

Isso impede divergência silenciosa sobre o significado do número. Duas implementações podem selecionar o mesmo objeto e um auditor pode recompor os parâmetros a partir de uma referência estável.

Mas o catálogo não contém expoente, gerador aleatório local, autorização, validação de entrada, identidade, PRF, armazenamento de chave ou resultado da aplicação.

Seu recibo legítimo é “estes parâmetros públicos foram escolhidos”. Usá-lo como “a sessão era segura” exige fatos que não estão nele.

O RFC preserva a incerteza das estimativas

A introdução compara estimativas diferentes para relacionar grupos finitos a chaves AES de 128, 192 e 256 bits. As diferenças, sobretudo nos níveis maiores, não são pequenas.

Em vez de escolher uma tabela conveniente, os autores definem opções e não dizem qual grupo deve acompanhar cada tamanho de AES. Também limitam a coleção a 8192 bits por custo prático no hardware da época.

Logo, alinhar “8192” a “256” em um relatório cria uma promessa ausente da especificação. Bits de módulo e bits de chave simétrica não são equivalentes sem modelo e horizonte.

A escolha continua sujeita a pesquisa, custo, prazo de confidencialidade e força dos demais componentes. Uma política possui data; o número do grupo não congela o conhecimento.

Um campo largo pode carregar pouco acaso

O RFC 3526 manda selecionar o expoente para acompanhar o sistema e não ser o elo mais fraco. Ele deve ter mais que o dobro da aleatoriedade da força pretendida; o exemplo pede mais de 256 bits de randomness para 128 bits de força.

Um buffer de 512 bits não atesta 512 bits de entropia. Uma fonte repetida, enviesada ou mal inicializada pode produzir uma saída longa e previsível. Preencher e formatar não substitui geração segura.

Guardar o expoente para auditoria seria pior: a evidência exporia o segredo. O recibo registra de modo não secreto fonte aprovada, versão, health tests, política de tamanho, exigência de frescor e uma ligação protegida ao evento.

O grupo maior melhora um problema matemático. Não cura uma ação privada fraca.

O valor público do outro lado não vem pré-validado

O RFC 6989 descreve testes do receptor IKEv2. Para grupos MODP com primo de Sophie Germain, entre eles os do RFC 3526, cada receptor verifica o intervalo estrito 1 < r < p-1.

O Transform ID escolhe a regra, não comprova sua execução. Um payload pode declarar grupo 14 e ainda conter valor que deve ser descartado.

Grupos com subgrupos pequenos e reutilização de valores privados seguem decisões adicionais. Gerar novo segredo e reusar segredo não produzem o mesmo risco nem exigem exatamente o mesmo recibo.

Telemetria útil conserva hash do valor recebido, perfil do teste, versão do código e resultado. “DH aceito” não explica se a aceitação foi sintática, matemática ou política.

Obrigatório no produto não é obrigatório na implantação

O RFC 7296 exige controles de gestão para suites aceitáveis. A implementação compara Transform IDs recebidos à configuração local e rejeita propostas não autorizadas. Algo MUST implement pode permanecer fora da política ativa.

Essa fronteira mantém o registro como coordenador, e não como autoridade remota de cada rede.

O RFC 8247 alterou requisitos: na sua publicação, o grupo 14 passou a MUST e o grupo 5 a SHOULD NOT. Também observou que grupos extremos impõem carga a gateways e dispositivos restritos.

Registre a proposta completa, sua ordem, a seleção, a versão da política e os rejeitados. “Suporta 8192” é inventário; “autorizou para este uso” é decisão; nenhum é ainda o resultado.

A matemática não autentica o nome

Diffie-Hellman sem autenticação cria valor compartilhado com o participante efetivo. O IKE usa métodos adicionais para provar identidade. O RFC 3526 apenas fornece grupos.

Tamanho não valida certificado, identidade de PSK, fluxo EAP nem correspondência entre nome e direito. Um handshake com grupo grande não autoriza um sistema a rotular empresa, pessoa ou dispositivo sem o recibo da autenticação.

Método, caminho de confiança, política, identidade alegada, identidade aceita e binding permanecem campos próprios.

Eles se correlacionam com o grupo na mesma troca, mas não herdam sua prova.

A suite ainda é limitada pelo conjunto

O RFC 8247 explica que segurança depende de algoritmos, chaves e engenharia contra bypass. Grupo forte não conserta PRF fraca, autenticação errada, armazenamento exposto ou tráfego fora do túnel.

Há custo operacional. Exponenciação maior consome recursos e, antes da autenticação, pode ampliar pressão de negação de serviço. Isso não justifica grupo fraco; exige ordem, limites e decisão auditável.

Avalie a suite como grafo de dependências. O maior número não eleva sozinho o teto imposto pelos demais nós.

O RFC 7919 adotou outros grupos FFDHE em TLS e outro contexto de negociação. É comparação posterior, não regra retroativa nem prova de IKE.

O registro conhece nomes, não execução

O registro IANA IKEv2 mantém grupo 5 e grupos 14–18, aponta o RFC 3526 e referencia os testes do RFC 6989. Ele resolve o significado público.

Não sabe se um equipamento gerou segredo fresco, testou o par, aplicou política, autenticou identidade, destruiu a chave ou entregou tráfego.

O RFC 9395 depreciou IKEv1 e fechou seus registros. Sua lista de algoritmos então depreciados não adicionou grupos Diffie-Hellman. Isso não transforma todo grupo restante em escolha ideal.

Status de documento, linha de registro, requisito de produto e decisão local são recibos diferentes. Fundi-los dá autoridade operacional a uma base que não observou o sistema.

Uma cadeia que não precise revelar o segredo

Comece com versão, RFC, Transform ID e hash de primo e gerador. Acrescente proposta ordenada, suite, contexto contra downgrade, política e decisão.

Na geração privada, guarde evidência não secreta de fonte, saúde, regra e frescor. Na entrada remota, hash, teste e ramo. Nunca coloque o expoente no log comum.

Associe método de autenticação, credencial, caminho de confiança e principal aceito. Registre PRF, algoritmos, criação da SA, rekey, reutilização e apagamento.

Por fim, observe pacotes protegidos, falhas de integridade, selectors, par esperado e transação da aplicação. A negociação não pode encerrar uma promessa futura.

Limite das evidências

Este Artigo não identifica implementação, fornecedor, operadora, VPN, gateway, par, usuário, fluxo, incidente, ataque ou comprometimento. Não mede adoção, entropia, validação, desempenho, nível de segurança ou impacto empresarial atual.

O RFC 3526 é tratado como documento Standards Track de maio de 2003, hoje registrado como Proposed Standard. RFC 6989, RFC 7296, RFC 8247 e RFC 9395 mantêm seus períodos e escopos. Nenhum prova execução em sistema nomeado.

Os textos de Heng Lu são lentes editoriais declaradas para separar coordenação pública e running code. Não são fontes de intenção da IETF.

A conclusão é estreita: o grupo maior pode reforçar um componente, mas não recebe autoridade para certificar atos privados e resultados externos.

Fontes