Resumo

  • O CFRG publicou em 7 de setembro de 2026 a revisão 14 de draft-irtf-cfrg-pairing-friendly-curves. É um Internet-Draft ativo de grupo de pesquisa da IRTF, destinado à categoria Informational; não é RFC nem padrão do IETF.
  • A revisão define serialização e desserialização normativas de pontos BLS12-381 e BLS48-581 e de escalares dessas curvas e de BN462. O decodificador verifica coordenadas canônicas, curva e subgrupo antes de devolver um elemento de grupo ou INVALID.
  • A especificação que chama essas rotinas conserva três decisões: quais formas de ponto aceita, se aceita o elemento identidade e se aceita o escalar zero. As duas últimas não são a mesma política.
  • Em relação à revisão 13, o novo texto remove a recomendação universal de rejeitar a identidade, separa a regra do zero e acrescenta a escolha explícita da forma do ponto. A codificação de pontos BN462 fica deliberadamente sem definição normativa porque as práticas existentes não convergiram.
  • Daniel Kade propõe um perfil de aceitação com sete campos para tornar a fronteira verificável. A proposta é análise editorial, não uma exigência do CFRG ou do rascunho.

O objeto matemático não decide a mensagem

Em especificações criptográficas, “validar” costuma condensar duas perguntas. A primeira é matemática: o comprimento e os bits de controle estão corretos, a coordenada tem representação canônica, o ponto pertence à curva indicada e ao subgrupo exigido? A segunda é semântica: esse valor válido pode ocupar este campo do protocolo?

A revisão 14 detalha a primeira etapa. Suas rotinas de desserialização produzem um elemento do grupo ou INVALID. Uma coordenada igual ou superior ao módulo do corpo é recusada em vez de reduzida, preservando uma representação única. A rotina reconstrói o ponto, testa a equação da curva e verifica a pertinência ao subgrupo. Tipos de ponto que por acaso tenham o mesmo comprimento de entrada não se tornam intercambiáveis.

Para escalares, o inteiro codificado deve ser inferior à ordem do corpo escalar. O zero, portanto, tem uma codificação canônica. A existência dessa codificação não determina se o zero faz sentido como chave, desafio, coeficiente ou valor intermediário. Só o protocolo chamador conhece essa função.

Duas implementações podem então cumprir a rotina comum e falhar ao conversar. Uma aceita o resultado matemático e outra o rejeita; ou ambas aceitam o mesmo ponto, porém preservam representações recebidas diferentes como se fossem identidades distintas. A interoperabilidade depende da política aplicada após a decodificação.

Três escolhas não cabem em um único modo estrito

A primeira escolha é a forma do ponto. A revisão 14 orienta o protocolo chamador a declarar se aceita apenas pontos comprimidos, apenas não comprimidos ou ambos. Aceitar os dois formatos permite duas sequências de bytes válidas para o mesmo ponto. Se a aplicação assina, resume, compara ou indexa os bytes recebidos diretamente, a escolha altera o estado do sistema, não apenas o consumo de banda.

A segunda escolha é o elemento identidade. Certas construções têm motivo específico para recusá-lo. O rascunho de assinaturas BLS, por exemplo, exclui a identidade na validação de chaves, em conexão com a chave secreta zero inválida e a assinatura identidade. Em outra construção algébrica, a identidade pode ter função legítima. Por isso a revisão 14 deixa a decisão para a semântica e o modelo de ameaça, sem um padrão universal.

A terceira é o escalar zero, tratado separadamente. A revisão 13 chamava a rejeição da identidade de opção padrão recomendada e aproximava a política do zero da política da identidade. A revisão 14 desfaz essa ligação. O RFC 9591 mostra a independência na prática: sua desserialização de elementos rejeita a identidade, enquanto a de escalares não introduz uma rejeição equivalente do zero.

Um protocolo pode exigir compressão, rejeitar identidade e aceitar zero em determinado campo. Outro pode aceitar os dois formatos, usar a identidade em uma operação e proibir o escalar zero. Embutir as três escolhas em um único botão da biblioteca transfere para o código genérico uma decisão que pertence ao contrato do protocolo.

BN462 marca onde o formato comum termina

O texto define pontos BLS12-381 e BLS48-581, mas não pontos BN462. O módulo do corpo-base de BN462 ocupa 462 bits. Em 58 bytes há 464 bits, restando apenas dois, enquanto o formato comprimido comum precisa acomodar três informações de controle.

O apêndice informativo registra soluções incompatíveis em software existente: byte de tipo ao estilo SEC1, byte separado para flags e formatos compactados sem a mesma convenção de metadados. Segundo os autores, as especificações examinadas não exigem codificação de pontos BN462 e a prática não convergiu. A revisão 14 evita transformar uma dessas soluções em regra normativa por decreto.

Isso não significa que BN462 não tenha implementações, que as codificações citadas sejam vulneráveis ou que todos os sistemas devam mudar. Significa apenas que um protocolo que transporte pontos BN462 precisa indicar outra especificação de codificação ou definir integralmente a sua. A referência à revisão 14, sozinha, não fecha esse contrato.

Autonomia local requer registro local

O histórico de desenvolvimento esclarece a divisão. A issue 74 do repositório do CFRG pediu uma definição autorizada de serialização para evitar cópias divergentes. O pull request 108 levou à revisão 14 procedimentos nomeados, testes de pertinência, decisões do protocolo e trabalho com vetores. Mensagens na lista do CFRG avisaram autores de documentos dependentes. Os rascunhos de assinaturas BBS e de representação COSE de chaves BLS mostram que a dependência já existe.

Uma camada comum mínima pode estabilizar a matemática sem comandar a semântica de todas as aplicações. A decisão futura pode permanecer local, mas precisa ser visível. Uma escolha que reside apenas no valor padrão de uma biblioteca não é modularidade: na rede, ela funciona como uma bifurcação sem documentação.

Minha proposta é que cada especificação chamadora publique um perfil de aceitação com sete campos: revisão exata do documento de curvas, curva selecionada, formas de ponto admitidas, regra para identidade, regra para escalar zero, caminho da validação de subgrupo e, se houver pontos BN462, referência externa exata da codificação. O mesmo perfil pode ser exposto nos testes de interoperabilidade.

O nome e a estrutura do perfil são uma proposta de Daniel Kade; a revisão 14 não os determina. O objetivo não é uniformizar as escolhas locais, mas permitir que revisores comparem quem decidiu, sobre qual versão e com que consequência.

Fontes