"Carro elétrico já está pronto?" Depende do trajeto.
Para quem roda 40 km por dia na cidade e tem tomada na garagem, o carro elétrico está pronto há anos. Para quem cruza o país puxando um reboque, ainda não. A pergunta "está pronto?" não tem resposta única; tem uma resposta por trajeto.
Com a criptografia homomórfica (FHE: calcular sobre o dado cifrado sem nunca abri-lo) é igual. Há usos em que ela é uma decisão de engenharia sóbria, e usos em que o orçamento muda de ordem de grandeza. A diferença não está na maturidade da biblioteca: está na forma do cálculo.
Os custos abaixo saíram da mesma bancada que produziu a fronteira do FHE (dezesseis testes na mesma máquina). Esta página é a camada seguinte: não onde a criptografia para, mas o que dá para colocar em produção hoje.
Lote grande, poucas multiplicações, decisão no cliente.
Existe um conjunto real de usos em que FHE é uma decisão sóbria, não uma aposta. Todos têm a mesma forma: muitos registros de uma vez, poucas multiplicações seguidas e toda decisão tomada do lado de quem tem a chave.
| Uso | Por que fecha | Custo medido |
|---|---|---|
| Agregação em lote: soma, média, contagem, votação | nenhuma decisão sob cifra; somar não gasta orçamento | produto interno de 2.048 números: 115 ms |
| Última camada de um modelo de IA | o pesado roda em claro no aparelho; só o resumo vai cifrado | idem |
| Busca privada em tabela de até 10⁴–10⁵ linhas | o padrão que Apple e Microsoft já usam em produto | 10⁴: 1,2 s / 20 MB (proj.) · 10⁵: 14,1 s / 196 MB |
| Cruzar listas (PSI) | custo linear, com constante boa | medido em universos de 10⁶ e 10⁷ |
| Lógica pequena com ramificações (TFHE) | sem limite de profundidade, ~54 ms por porta | 1 comparação: 1,74 s |
| Blockchain confidencial | dado minúsculo, valor alto por transação | fora da bancada · em produção (mainnet) desde dez/2025, segundo o fornecedor |
Funciona, com condição.
Muitas multiplicações seguidas
Cada multiplicação gasta um pedaço de um orçamento fixo. Com parâmetros de segurança real (128 bits), o orçamento é curto: a nossa própria bancada descobriu que as "8 multiplicações" que ela citava usavam parâmetros mais fracos, e que no teto real cabem 2 níveis. Passou disso, entra a "faxina" (bootstrapping): 1 min 18 s por vez e 10,26 GB de chaves enviadas antes de começar.
Um atalho novo muda a conta: devolver o pacote ao cliente, que abre e recifra, custa 1,04 s e dispensa as chaves de faxina. O preço é o cliente ficar online e ver os valores do meio da conta. Sem isso, é tarefa em lote, não resposta de API.
Misturar aritmética e lógica
A troca de dialeto no meio do cálculo existe e foi medida: 13,9 s por posição. Compensa para pouquíssimas decisões, e nada além disso.
Consulta pontual
Um número cifrado sozinho ocupa um pacote 229.428 vezes maior que ele. FHE recompensa lote e pune consulta pontual: o inverso da intuição de quem vem de banco de dados, e a origem da maior parte das arquiteturas mal dimensionadas.
E não é questão de esperar a próxima versão.
O padrão correto para decidir é sempre o mesmo: devolva as notas cifradas e decida no cliente. Do lado de quem já tem a chave, a mesma decisão custa microssegundos e não custa privacidade nenhuma, porque quem decide já é quem pode abrir.
Um ponto que material de fornecedor costuma embaçar: os dois grandes dialetos do FHE (um para contas em lote, CKKS e BGV; outro bit a bit, TFHE) diferem por ~6 milhões de vezes num sentido e ~170 no outro. A diferença é estrutural, não de maturidade. Acelerar a máquina desloca os dois; não os aproxima.
| Operação | Custo medido | O problema |
|---|---|---|
| Escolher o maior entre 1.000 sob cifra | 130 h (ancorado) | a 128 bits reais; e a precisão caiu para 3 bits em algum slot: é lento e errado |
| Buscar por posição cifrada em 10⁷ linhas | 19 GB (projetado) | se o servidor pular para a linha certa, o pulo revela qual era: a tabela inteira precisa ser tocada |
| Comparar cifrados muito próximos | diferença < 2⁻³⁰ | zona cega: a operação não tem resultado definido |
| Rede neural profunda inteira sob cifra | — | a ativação comum (ReLU) custa uma comparação; por isso se retreina a rede com x² |
Onde a fronteira pode se mover.
Hardware: a promessa ainda não é silício
Números de terceiros
O programa DPRIVE, da agência de pesquisa militar dos EUA (DARPA), gerou uma leva de chips dedicados: a Niobium fechou com a Semifive para fabricar em Samsung 8 nm, a Fabric Cryptography levantou US$ 33 milhões, a Optalysys cerca de US$ 30 milhões numa abordagem fotônica, a Intel segue com o Heracles. É investimento real e a direção está certa. Mas os 5.000× a 17.000× citados nessa geração são simulação e projeção, não chip embarcado e medido.
Na prática: ao receber um número de fornecedor, pergunte o tamanho do parâmetro (logN). Nesta bancada, o de "brinquedo" (logN=13) é ~40 vezes mais rápido que o de segurança real (logN=16), e quase nenhum material publicado diz qual dos dois está citando.
A banda, que o silício não resolve
Nos usos de busca, o limite medido não é o processador: é a rede. Uma tabela de 1 milhão de linhas custou 1,91 GB de tráfego por consulta; 10 milhões projetam 19 GB. Chip acelera a conta e não move um byte a menos. A linha de pesquisa que ataca a metade certa (transcifragem: enviar cifrado com AES e converter dentro do FHE) ainda não está madura, e nós não a medimos.
Integridade: o custo que ninguém orça
FHE dá sigilo, não integridade. A mesma propriedade que permite calcular sobre o cifrado impede perceber um resultado adulterado. O ataque não precisa de nada exótico: a aplicação abre o resultado e confere ("tem de estar nesta faixa"); se não estiver, reage (erro, nova tentativa, log). Essa reação é um bit que o servidor observa. Somando valores escolhidos e lendo o "aceitou ou recusou", o servidor recupera o dado em claro em 47 perguntas, sem atacar a chave.
A defesa barata, o "canário" (posições de valor conhecido), pega 100% de quem adultera às cegas e só 0,37% de quem escolhe onde mexer. Canário é higiene, não integridade. A correção de verdade (prova sobre o cálculo ou hardware atestado) custa, segundo a literatura, de ~2% a mais de 1.000%: três ordens de grandeza de incerteza.
Quando o resultado aberto é compartilhado
Literatura
Para o dialeto aproximado (CKKS), a segurança clássica não basta se o resultado aberto for mostrado a terceiros. Li e Micciancio (EUROCRYPT 2021) mostraram que o resultado aberto permite recuperar a chave; Guo e coautores (USENIX Security 2024) mostraram a recuperação a partir de um único resultado compartilhado, numa biblioteca aberta muito usada. A boa notícia, de 2025: cerca de 2 bits a menos de precisão restauram a segurança nos parâmetros padrão.
Na prática: "o resultado aberto vai para terceiros?" é uma pergunta de triagem por si só. Se sim, o parâmetro muda, e o custo é pequeno desde que a pergunta seja feita antes de gerar as chaves.
Padronização, e o erro silencioso
O campo saiu do vazio normativo: a norma ISO/IEC 28033 está em curso (partes geral e CKKS em rascunho final, BGV/BFV em votação até abril de 2026, busca em tabela e troca de dialeto em elaboração), e o NIST acompanha. O que ainda falta é o que evitaria o modo de falha mais perigoso que medimos: com o orçamento de 4 níveis, o modo BFV acerta até a 7ª multiplicação e erra na 8ª em silêncio, devolvendo 28.323 onde a resposta é 282.
Um bit por pergunta basta.
O ataque de reação, medido em 24 segredos de 16 bits: 46,7 ± 1,3 perguntas em média, 24 de 24 recuperados, 79 ms por valor. O servidor nunca abre nada; só observa se o cliente aceitou.
O que isso muda: todo projeto em que o servidor pode ser malicioso, e não só curioso, tem um custo cujo tamanho plausível vai de desprezível a proibitivo. Enquanto esse preço não fechar, ele precisa entrar no orçamento como incerteza declarada.
FHE fecha quando as cinco valem juntas.
- Lote grandeMuitos registros de uma vez. Consulta pontual paga o pacote inteiro.
- Poucas multiplicações seguidasCabe no orçamento sem faxina. A 128 bits reais, o orçamento é curto.
- Decisão no clienteComparar, escolher o maior e ramificar ficam do lado de quem tem a chave.
- Tabela pequena para buscarAté 10⁴–10⁵ linhas. Acima disso, a banda manda.
- Servidor honesto, mas curiosoEle segue o protocolo, só não deve ver o dado. Se pode trapacear, o custo é desconhecido.
Tire uma, e o custo muda de ordem de grandeza. Tire a última, e o custo é desconhecido. Por isso a resposta para "FHE já está pronto?" é: depende de qual das cinco você não tem. É uma conversa de uma hora, com números, não de seis meses de prova de conceito.
A operação que limpa o ruído das contas cifradas e devolve orçamento. Possível, e cara: 1 min 18 s e 10,26 GB de chaves a 128 bits reais.
O servidor segue o protocolo à risca, mas gostaria de ver o dado. É o cenário em que FHE protege bem. O servidor que trapaceia é outro problema.
Quanto maior, mais seguro e mais lento. logN=16 é segurança real de 128 bits; logN=13 é "de brinquedo" e ~40× mais rápido. Pergunte sempre qual.
Onde isso pode estar errado.
Uma bancada, uma máquina
Os custos são de um laptop Apple M-series, num único núcleo, com a biblioteca Lattigo. As razões entre operações viajam; os tempos absolutos, não. Em servidor com acelerador, os números mudam, e a forma da fronteira, não.
A integridade veio de outra bancada
O ataque de reação e o canário foram medidos numa bancada de integridade separada da de custo. A faixa de ~2% a mais de 1.000% para a correção é da literatura, não nossa.
Números de terceiros
Chips, rodadas de investimento, os 5.000× a 17.000× e a data do blockchain em produção são declarações de terceiros, marcadas como tal. Não medimos silício.
A regra das cinco é simplificação
Ela acerta a ordem de grandeza, não o número. Um caso com quatro condições pode fechar com um atalho de protocolo; um caso com as cinco pode falhar por banda. O laudo existe para isso.
← FHE: calcular sem abrir o dado · stickybit.com.br
- Medições próprias: bancada de custo (repositório FHE,
12_reality_check, Lattigo v6.2.0, média de 3 repetições, agosto de 2026) e bancada de integridade (ataque de reação, canários). - Viand, Knabenhans e Hithnawi, Verifiable Fully Homomorphic Encryption (arXiv:2301.07041).
- Li e Micciancio, segurança IND-CPA-D de esquemas aproximados (EUROCRYPT 2021) · Guo et al., USENIX Security 2024 · IND-CPA-D com HintLWE (2025) · OpenFHE: segurança do CKKS.
- Norma: ISO/IEC 28033-1, parte 2, parte 3 · NIST, criptografia de preservação de privacidade (FHE).
- Hardware e mercado: DARPA DPRIVE · Niobium e Semifive · Intel Heracles (IEEE Spectrum) · Zama fhEVM.