Resumo

  • A revisão 12 do esquema BBS permite provar conhecimento de uma assinatura sobre várias mensagens, revelando apenas as escolhidas. A não vinculação vale para o proof value randomizado; header, presentation_header, valores expostos, número e índices de mensagens, chave do emissor, endereço de rede e dados da aplicação continuam disponíveis para correlação.
  • Um resultado válido é um recibo criptográfico delimitado. Não prova sozinho identidade civil, diligência da emissão, situação atual ou revogação, completude, autorização, privacidade ponta a ponta nem efeito da operação.

O relatório técnico dizia “unlinkable”. O sistema de risco, examinando o request inteiro, dizia “mesmo grupo”. O primeiro havia comparado duas provas randomizadas. O segundo havia combinado quatro sinais que a prova nunca prometeu ocultar. Não existe contradição: existe uma mudança silenciosa do objeto examinado.

draft-irtf-cfrg-bbs-signatures-12 merece atenção justamente porque evita esse atalho. O documento entrega uma primitiva de assinatura multimensagem e prova de conhecimento com divulgação seletiva. Depois limita a garantia à saída de prova e descreve como o restante da apresentação pode identificar. Para governança, essa segunda metade é parte da especificação de produto.

Vetores concretos deixam o algoritmo auditável, não a implantação anônima

A revisão 12 foi submetida em 28 de setembro de 2026 como Internet-Draft ativo do CFRG no fluxo IRTF, pretendendo status Informational. Não é RFC final, Standards Track, certificação ou comprovação de uso por qualquer carteira, emissor ou verifier.

Em relação à revisão 11, valores que ainda apareciam como placeholders passam a ser constantes, escalares, geradores, assinaturas e proof fixtures completos. Um implementador pode executar as entradas e comparar cada byte. É uma melhoria importante para interoperabilidade do código e detecção de erros matemáticos ou de serialização.

O teste, porém, escolhe previamente chave, mensagens, headers e aleatoriedade simulada. A produção precisa demonstrar quem publicou a chave, se todos receberam a mesma visão, quantas pessoas dividem o header, se o RNG repetiu estado depois de fork ou snapshot e quais identificadores foram acrescentados pela rede e pelo aplicativo. O vetor não observa nada disso.

Por isso, a evidência de release precisa de duas linhas. Uma mostra que o build corresponde aos fixtures da revisão 12. A outra mostra população das chaves, cardinalidade dos headers, forma das credenciais, saúde do RNG, retenção de metadados e testes de correlação. Aprovar a primeira não encerra a segunda.

Coloque um ponto final depois do significado de VALID

BBS assina uma lista ordenada de mensagens com uma assinatura de tamanho constante. O holder gera uma prova randomizada de que conhece essa assinatura e revela apenas um subconjunto. O Verifier recebe chave pública, proof, header ligado à assinatura, presentation_header ligado à prova, mensagens visíveis e índices originais.

Se a validação passa, sabe-se que o Prover conhece uma assinatura BBS válida sob aquela chave, que os valores revelados ocupavam aquelas posições e que os dois headers foram incorporados ao desafio. A prova não revela a assinatura oculta nem os valores que ficaram escondidos.

Ela não diz quem opera o dispositivo, como o Issuer verificou fatos do mundo, se a credencial foi suspensa, se algum dado relevante foi omitido, se a política local autoriza a ação ou se o resultado ocorreu. Cada conclusão exige outro dono e outro recibo.

O artigo já publicado sobre RFC 9901 conserva a fronteira entre divulgação SD-JWT válida e registro completo. Aqui a questão é outra: mesmo a não vinculação mais forte do proof BBS pode conviver com uma apresentação reconhecível.

O header do Signer pode virar um nome permanente

O draft define dois headers. header é escolhido pelo Signer, vinculado à assinatura e a todo proof derivado; sempre é mostrado ao Verifier. Serve para contexto comum — aplicativo, domínio, versão de baixa cardinalidade —, mas também pode carregar uma etiqueta impossível de remover pelo Holder.

Se o emissor inserir um credential ID aleatório, e-mail, número de terminal ou validade com precisão excessiva, o valor se repetirá em toda apresentação. A randomização do proof fica irrelevante para correlação. Daí a exigência de um header de baixa entropia compartilhado por muita gente.

Cardinalidade é circunstancial. Um país pode agrupar milhões num serviço global e apenas duas pessoas num programa restrito. Uma versão comum hoje pode identificar três equipamentos amanhã. Header, chave, região e forma, quando combinados, podem reduzir o conjunto a um titular.

O recibo do Issuer deve preservar bytes, regra de geração, população prevista e observada, chave associada e exceções. Como o Holder não pode alterar esse valor assinado, quem escolhe o campo precisa responder pela sua reavaliação depois de cada migração.

Presentation header protege o desafio, não cria contexto correto

presentation_header é escolhido para uma apresentação. Pode incluir nonce do Verifier, audiência, domínio, período ou mensagem assinada pelo Prover. Um proof válido mostra que o valor está ligado àquela prova.

Frescor depende de estado externo. É preciso saber quem gerou o nonce, para qual sessão e audiência, quando expira, se já foi consumido e como o replay é recusado. Em apresentação não interativa, outra regra de unicidade deve existir. Um valor novo pode ainda pertencer à transação errada.

Valor de alta entropia pode ser adequado se for único a cada proof e não contiver identidade. Reutilização cria uma alça estável. Conta, localização precisa ou build raro pode identificar em uma única passagem. Integridade criptográfica não é minimização.

Registre origem, sessão, audiência, criação, expiração e consumo por prazo definido. Guardar apenas “nonce válido” destrói explicabilidade; guardar todos os desafios para sempre constrói o próprio banco de rastreamento que o protocolo pretendia evitar.

A forma dos dados ocultos continua visível

O tamanho da prova e a lista divulgada permitem inferir o total de mensagens; os índices revelam posição no schema. Cinco campos para funcionários, nove para terceiros e treze para um programa protegido já classificam sem recuperar nenhum segredo.

Uma combinação incomum de posições funciona como impressão digital. Cruzar registros de Verifiers diferentes reduz ainda mais o conjunto. Por isso o draft recomenda padding para comprimento comum e ordem consistente quando possível. São controles de população, não estética de encoding.

A evidência deve mostrar versão do schema, distribuição real de comprimentos, regra de preenchimento, mapa de índices e testes sobre campos opcionais. Padding aumenta bytes e complexidade; uma regra rara também identifica. A decisão começa pela população que deve permanecer indistinguível e termina medindo a menor classe gerada.

A chave pública pode fragmentar os titulares antes da prova

Todo proof é validado sob uma chave de Signer. Se uma chave atende uma pessoa ou pequena coorte, qualquer apresentação sob ela revela a coorte, embora dois proof values não denunciem uma assinatura comum.

Isso acontece sem malícia em rotações regionais, canaries, isolamento de incidentes ou hierarquias herdadas. Também pode ser intencional: um emissor entrega uma key view diferente a titulares escolhidos e cria uma marca silenciosa.

O recibo precisa de bytes e ID da chave, canal de publicação, ativação e retirada, população esperada, população real e evidência de consistência. A pesquisa de key consistency mencionada no draft é uma abordagem; a obrigação é impedir que Holder e Verifier recebam visões seletivamente fragmentadas.

Uma chave global aumenta o conjunto anônimo e o raio de comprometimento. Hierarquia melhora isolamento e diminui grupos. Não há topologia universal: deve existir uma população explicitamente protegida e um teste que confirme seu tamanho depois de cada rotação.

Verdade divulgada pode ser o identificador mais forte

Nome, documento, e-mail e telefone podem estar corretamente assinados e ser voluntariamente mostrados. Repetidos, ligam apresentações diretamente. Profissão, cidade pequena e data exata também podem formar combinação única.

BBS confirma autenticidade do valor, não necessidade. Finalidade, proporcionalidade, retenção e alternativas são decisões do serviço. Pedir data de nascimento quando bastava provar maioridade consome privacidade sem violar o algoritmo.

Range proofs ou set membership podem ajudar, mas são construções adicionais. BBS base não transforma idade em limiar, nem prova não revogação só porque o identificador ficou oculto. Cada extensão traz novos parâmetros e uma nova fronteira de verificação.

A aleatoriedade faz parte do segredo

ProofGen precisa de vários escalares independentes, uniformes e únicos por chamada. Reuso, previsão ou relação conhecida pode expor mensagens não reveladas ou a assinatura. Um proof ainda pode parecer válido depois da falha de privacidade.

O documento descreve ainda um canal de exfiltração por manipulação de bits aleatórios. Um gerador determinístico, alimentado por uma seed única e uniforme, pode limitar esse canal em alguns sistemas; não elimina a necessidade de entropia confiável e custódia da seed.

Evidência de produção identifica RNG, build, origem da seed, health checks, limites de processo/dispositivo, fork, snapshot e reação a falhas. “RNG do sistema” é descrição de desenho, não receipt de execução.

Também permanecem separados validação da chave, subgroup checks, domain separation, operações resistentes a side channel e regras comuns de transformação de mensagens. Passar fixtures não prova automaticamente nenhum deles.

Não empreste do draft vizinho

Blind BBS Signatures é uma extensão separada para o Signer assinar mensagens do Holder que ficam escondidas por um commitment. A divulgação seletiva base esconde do Verifier na apresentação; não demonstra que o Issuer desconhecia o dado na emissão.

BBS per Verifier Linkability adiciona pseudônimo dependente do contexto, permitindo reconhecimento dentro de um Verifier e buscando não vinculação entre contextos. BBS base não cria esse pseudônimo estável.

W3C bbs-2023 é perfil de Verifiable Credentials, com pointers obrigatórios e seletivos, transformação e opções de holder binding ou pseudônimo. Compras e integrações devem listar revisão, ciphersuite, interface, extensão e perfil. “Suporta BBS” não resolve compatibilidade.

O risco quântico separa autenticidade de confidencialidade

A autenticidade BBS depende do logaritmo discreto e não é pós-quântica. Um computador criptograficamente relevante pode obter a chave secreta, fabricar assinaturas e criar proofs válidos para mensagens escolhidas.

O draft trata diferente o sigilo de proofs já gerados. O ocultamento de mensagens não reveladas e assinatura é informacional; nem computação ilimitada com o segredo do Signer extrai esses valores do proof. É everlasting privacy do proof, não rótulo quantum safe do sistema.

A migração precisa de dois relógios. Autenticidade deve mudar antes que a ameaça alcance a vida da decisão. Os transcripts podem manter ocultação, enquanto headers, dados expostos, IP e logs continuam correlacionáveis. Rotação de chave não apaga cópias.

O receipt deve cobrir a conversa inteira

A cadeia mínima separa versão e ciphersuite; origem e consistência da chave; emissão blind ou não; header e coorte; schema, ordem e padding; valores e índices revelados; presentation header, nonce, audiência e frescor; proof e resultado; RNG; parser, subgrupo e domain separation; metadados de rede/dispositivo; estado/revogação; política; autorização; ação; efeito; retenção; migração.

Não é preciso um centro único. Issuer, wallet, Verifier, aplicação, segurança e privacidade guardam a decisão que controlam e ligam os recibos por identificador limitado. A especificação inicial mínima de Lu Heng mantém a camada comum enxuta. A disciplina das camadas impede que zero knowledge tome o poder da autorização. Running-Code Primacy pergunta qual chave, schema, RNG, binário e caminho de logs realmente rodaram.

A lição não é que BBS promete pouco. Promete algo forte, com objeto explícito. O problema nasce quando a organização acrescenta “toda a implantação” sem acrescentar evidência.

Fontes