Privacy Pass pós-quântico: Cloudflare pesquisa tokens anônimos
Neste artigo
- Privacy Pass pós-quântico busca proteger a validade dos tokens
- Como o Privacy Pass separa emissão e acesso
- MOLE acrescenta confiança sem identificar quem a concedeu
- VOLE-ACT trabalha com um saldo oculto
- O que os números de desempenho realmente medem
- Da pesquisa anterior aos novos rascunhos
- Disponibilidade e limites para adoção
- Aplicações atuais ajudam a entender a proposta
- Fontes
- Perguntas frequentes
Comprovar o direito de acessar um serviço sem entregar um identificador persistente é o objetivo do Privacy Pass pós-quântico em pesquisa na Cloudflare. O projeto experimental `vole-mole` reúne construções para preservar essa separação e resistir à falsificação por adversários quânticos, mas ainda não está pronto para produção.
Privacy Pass pós-quântico busca proteger a validade dos tokens
O Privacy Pass usa tokens para comprovar autorização de acesso sem criar uma ligação criptográfica entre sua emissão e sua apresentação ao site. Essa comprovação dispensa identificadores persistentes, como cookies, conforme a arquitetura padronizada pela IETF.
A ameaça quântica exige distinguir duas propriedades: manter o usuário anônimo e impedir a criação de autorizações falsas. Uma apresentação técnica de Christopher Patton à IETF explica que computadores quânticos poderiam falsificar tokens clássicos sem necessariamente conseguir associar seus resgates às emissões anteriores. A proteção dessa associação pode ter garantia pela teoria da informação. (IETF)
O desafio, portanto, inclui preservar a resistência à falsificação. Os novos protocolos procuram atender a essa necessidade sem abandonar as propriedades de privacidade que tornam as credenciais anônimas úteis no controle de acesso.
Como o Privacy Pass separa emissão e acesso
A arquitetura começa quando um site envia ao cliente um desafio que identifica o emissor aceito. Se já houver um token adequado, o cliente pode apresentá-lo; caso contrário, precisa cumprir a atestação exigida, como resolver um CAPTCHA ou comprovar a validade de um dispositivo.
Depois dessa verificação, o cliente solicita a emissão e calcula o token com a resposta recebida. Em uma nova solicitação, apresenta a credencial ao site, que verifica o emissor e se ela já foi resgatada. O mesmo token não deve ser apresentado novamente. (RFC 9576, seção 3.1)
O padrão oferece emissão com verificação privada, baseada em OPRF, e com verificação pública, baseada em assinatura RSA cega. A primeira exige a chave privada do emissor para validar o token; a segunda usa sua chave pública. O processo de atestação fica fora do protocolo de emissão, portanto não existe uma exigência universal de celular, conta ou mecanismo de verificação. (RFC 9578)
MOLE acrescenta confiança sem identificar quem a concedeu
A proposta MOLE, abreviação de *Moderation of unLinkable Endorsements*, combina controle de acesso, credenciais anônimas e limites de uso. Organizações independentes podem atestar confiança em alguém sem revelar sua identidade aos serviços acessados. (Arquitetura MOLE)
Nesse modelo, esconder o emissor também importa. Saber de qual organização veio uma credencial pode revelar vínculos do usuário; a combinação de vários emissores conhecidos pode formar uma impressão digital identificável, como explica a Mozilla.
O VOLE-IHAT procura ocultar essa informação. O cliente demonstra que recebeu uma assinatura de algum integrante do conjunto de emissores aceitos, sem indicar qual deles assinou. A construção emprega assinaturas UOV, provas de conhecimento zero VOLE-in-the-Head e um compromisso criptográfico baseado em Keccak. (Rascunho VOLE-IHAT)
VOLE significa *Vector Oblivious Linear Evaluation*. Sua aplicação em VOLE-in-the-Head ajuda a provar cálculos sem expor os valores secretos utilizados; o tamanho das provas cresce linearmente com o circuito demonstrado. (Cloudflare)
VOLE-ACT trabalha com um saldo oculto
O VOLE-ACT trata de outra necessidade: autorizar consumo anônimo com limites. A credencial carrega um saldo oculto, atualizado durante os gastos, e a apresentação comprova que o débito foi subtraído corretamente e que o saldo continua no intervalo permitido.
O emissor assina o compromisso atualizado, uma representação criptográfica desse novo estado. Assim, a construção procura conciliar a verificação do gasto com a preservação do valor secreto. (Rascunho VOLE-ACT)
Impedir reutilizações também exige trabalho da aplicação. Ela precisa registrar e verificar o *nullifier*, identificador destinado a detectar apresentações repetidas: a biblioteca `vole-mole` não impede gasto duplo sozinha. (Cloudflare Research)
O que os números de desempenho realmente medem
Nos testes publicados do `vole-mole`, executados em compilação de produção em um Apple M4 Pro, gerar uma solicitação de gasto VOLE-ACT levou 1,45 milissegundo e produziu 17.383 bytes. No VOLE-IHAT com 64 emissores, gerar o resgate levou 6,87 milissegundos, e a validação correspondente levou 6,55 milissegundos.
Esses tempos medem operações locais, sem representar a latência completa de uma conexão web. Parâmetros alternativos reduziram as provas entre 23% e 31%, mas tornaram geração e verificação aproximadamente 1,3 a 7 vezes mais lentas. Há uma escolha concreta entre economizar banda e consumir processamento. (Resultados de desempenho)
O custo de comunicação continua relevante. Para conjuntos de até 64 emissores, o rascunho VOLE-IHAT informa chave pública de 45,5 KB por emissor, envio de 7,1 KB na emissão e 8,6 KB no resgate, exigindo mais banda que a construção equivalente com curvas elípticas. (VOLE-IHAT)
Da pesquisa anterior aos novos rascunhos
A busca por credenciais anônimas pós-quânticas já produziu abordagens diferentes. Em 2023, uma construção com zkDilithium apresentou tokens de 85 a 175 KB, geração entre 0,3 e 5 segundos e verificação entre 20 e 30 milissegundos, com segurança de prova de 115 bits. (Cloudflare Research)
O trabalho PoMFRIT, publicado no USENIX Security 2026, combinou MAYO e VOLE-in-the-Head. Relatou assinaturas cegas de 6,7 KB, comunicação de emissão de 0,45 KB e apresentação em menos de 76 milissegundos em uma construção conservadora de 128 bits. Seus números pertencem a uma construção diferente: o `vole-mole` e os novos rascunhos usam UOV. (USENIX)
Os rascunhos VOLE-IHAT e VOLE-ACT têm data de 3 de novembro de 2026. Ambos são assinados por Tianyu Zhang, da University of Illinois at Urbana-Champaign, e Christopher Patton, da Cloudflare; Samuel Schlesinger, do Google, também assina VOLE-ACT.
O NIST publicou ML-KEM, ML-DSA e SLH-DSA em agosto de 2024, mas esses padrões cobrem estabelecimento de chaves e assinaturas digitais. Credenciais anônimas exigem construções adicionais. (NIST)
Disponibilidade e limites para adoção
Até 6 de novembro de 2026, o `vole-mole` estava marcado como experimental e não auditado, com orientação expressa para não usar em produção. APIs e formatos de comunicação podem mudar. A disponibilidade específica de VOLE-IHAT e VOLE-ACT no Brasil não estava confirmada.
O código tem licença BSD de três cláusulas. Para compilá-lo, o repositório exige Meson 1.4 ou posterior, Ninja, Python 3 e Clang 21 ou posterior, ou GCC 16 ou posterior. Trata-se de material para desenvolvimento e pesquisa. (Repositório oficial)
A análise de segurança também permanece em andamento. O VOLE-IHAT é descrito como plausivelmente pós-quântico, ainda dependente de análise significativa; a variante MQ de VOLE-ACT recebe uma advertência adicional sobre compromissos pouco estudados e incerteza quanto à suficiência dos parâmetros escolhidos.
A privacidade exige cuidados além da criptografia do token. Horários, endereços IP e características da implementação podem permitir correlação, segundo a arquitetura MOLE. Conjuntos de anonimato precisam ser suficientemente grandes: com apenas um emissor, não há como ocultar qual deles concedeu a credencial. (Arquitetura MOLE)
Aplicações atuais ajudam a entender a proposta
Tokens anônimos já aparecem em serviços voltados ao usuário. A Verificação Automática da Apple usa tokens de acesso privado para evitar CAPTCHAs em sites e aplicativos participantes. Se as verificações continuarem aparecendo, a orientação inclui conferir a sessão na Conta Apple e atualizar o sistema; o serviço acessado também precisa aceitar o recurso. (Suporte Apple Brasil)
O Kagi anunciou em fevereiro de 2025 o uso de Privacy Pass para comprovar o direito de pesquisar sem vincular buscas à conta. Essas aplicações ilustram a utilidade das credenciais anônimas, mas seus anúncios não estabelecem adoção dos novos protocolos VOLE. (Kagi)
Fontes
- Cloudflare Research: implementação experimental vole-mole
- IETF: arquitetura do Privacy Pass, RFC 9576
- MOLE: arquitetura e propriedades de privacidade
- Mozilla: credenciais anônimas e ocultação do emissor
- USENIX: pesquisa PoMFRIT
Perguntas frequentes
Preciso de um computador quântico para usar criptografia pós-quântica?
Não. Esses algoritmos são feitos para sistemas convencionais, com o objetivo de resistir a ataques de futuros computadores quânticos.
Os créditos do VOLE-ACT são uma criptomoeda?
Eles representam uma autorização de consumo que pode ser debitada de um saldo. A proposta não exige blockchain.
Por que não substituir as assinaturas atuais diretamente por ML-DSA?
Credenciais anônimas exigem operações e provas adicionais às assinaturas digitais comuns. Essa combinação traz custos que precisam ser resolvidos na construção do protocolo.
A extensão antiga do Privacy Pass confirma suporte aos novos protocolos?
Não. Os registros de extensões para Chrome e Firefox fazem parte do histórico do projeto e não comprovam compatibilidade atual com VOLE-IHAT ou VOLE-ACT.
