Criptografia homomórfica · Medição
A pergunta "FHE já está pronto?" não tem resposta única — tem uma resposta por carga de trabalho. Aqui estão as três faixas, com o número medido de cada uma, e os cinco pontos que precisam evoluir para a fronteira se mover.
Existe um conjunto real de cargas de trabalho em que FHE é uma decisão de engenharia sóbria, não uma aposta. Todas elas compartilham a mesma forma: lote grande, circuito raso, decisão no cliente.
| Caso | Por que fecha | Custo medido |
|---|---|---|
| Agregação em lote soma, média, contagem, votação |
circuito raso, nenhuma decisão sob cifra | produto interno 2048-dim: 115 ms |
| Camada linear final de ML | o pesado roda em claro no dispositivo; só a densa final vai cifrada | idem |
| Lookup privado até 10⁴–10⁵ | é o padrão de PIR que Apple e Microsoft já usam em produto | 10⁴: 1,2 s / 20 MB 10⁵: 14,1 s / 196 MB |
| PSI · interseção de conjuntos | linear, com constante boa | medido até 10⁶–10⁷ |
| Lógica pequena e ramificada TFHE | profundidade ilimitada, ~54 ms por porta | 1 comparação: 1,74 s |
| Blockchain confidencial | dado minúsculo e valor alto por transação | fora da bancada — mainnet desde dez/2025 |
Fora dessa forma, o orçamento não muda em percentual: muda em ordem de grandeza.
Profundidade acima de 8 multiplicações. Passou do orçamento, entra bootstrapping: 1 min 18 s por operação a 128 bits reais, com 10,26 GB de chaves de avaliação. Funciona — mas isso define "job em lote", não "latência de API".
Misturar aritmético e lógico no mesmo circuito. A troca de esquema existe e foi medida: 13,9 s por slot. Compensa para pouquíssimas decisões, e não mais que isso.
Consulta pontual. Um único valor cifrado tem expansão de 229.428×. FHE recompensa lote e pune consulta — o inverso da intuição de quem vem de banco de dados, e a origem da maior parte das arquiteturas mal dimensionadas.
| Operação | Custo medido | O problema |
|---|---|---|
| Argmax de 1.000 sob cifra | 130 h | a 128 bits reais. E a precisão colapsou para 3 bits em algum slot do lote: é lento e errado |
| Índice cifrado em 10⁷ | 19 GB | se o servidor saltar para a linha certa, o padrão de acesso vaza o índice — toda a tabela precisa ser tocada |
| Comparar cifrados muito próximos | < 2⁻³⁰ | zona cega: operação sem resultado definido |
| Rede profunda fim a fim | — | ReLU custa um sign; por isso se retreina a rede com x² |
O padrão correto para decisão é sempre o mesmo: devolva os scores cifrados e decida em claro 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 decifrar.
Há um ponto aqui que o material de fornecedor costuma embaçar: a diferença entre os dois grandes ramos — CKKS/BGV para aritmética em lote, TFHE para lógica — é de 6×10⁶ num sentido e 170× no outro. Essa diferença é estrutural, não de maturidade. Aceleração de hardware desloca os dois; não os aproxima.
O programa DPRIVE da DARPA gerou uma leva de ASICs 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 para uma abordagem fotônica; a Intel segue com o Heracles. É investimento real e a direção está certa.
Os 5.000× a 17.000× citados nessa geração são simulação e
projeção, não silício embarcado e medido. Ao receber um benchmark de fornecedor,
pergunte o logN: nesta bancada, a diferença entre
logN=13 (parâmetro de brinquedo) e logN=16 (128 bits reais) é de
~40× — e quase nenhum material publicado diz qual dos dois está citando.
Nos casos de lookup, o limite medido não é CPU — é banda. Um universo de 10⁶ registros custou 1,91 GB de tráfego; 10⁷ projeta 19 GB. Acelerador de criptografia melhora o tempo de computação e não move um byte a menos pela rede.
Ou seja: para uma parte relevante dos casos de uso, o silício em desenvolvimento está atacando a metade errada do problema. A linha que ataca a metade certa é o transciphering, e ela ainda não está madura.
Aqui está a medição nova, e é a que mais muda decisão de arquitetura. FHE dá confidencialidade, não integridade. A mesma maleabilidade que permite computar sobre o cifrado impede detectar um resultado adulterado.
O ataque não precisa de nada exótico. A aplicação decifra e valida ("o resultado tem que estar nesta faixa"). Se não estiver, ela reage — erro na tela, retry, log, código HTTP, latência diferente. Essa reação é um bit, e o servidor a observa. Somando um valor público ao cifrado e lendo o aceita/rejeita, o servidor recupera o dado em claro:
| Medição | Valor |
|---|---|
| Consultas para recuperar um valor de 16 bits | 46,7 ± 1,3 |
| Taxa de sucesso | 24/24 segredos |
| Tempo total do ataque, por valor | 79 ms |
| Detecção por slots-canário — adversário cego | 100% |
| Detecção por slots-canário — adversário dirigido a 1 slot | 0,37% |
47 requisições. Nenhuma chave é atacada; o servidor nunca decifra nada. E a defesa barata resolve o adversário errado: o canário custa 0,39% dos slots e pega 100% de quem adultera às cegas, mas só 0,37% de quem escolhe onde mexer — que é exatamente c/n, como a teoria prevê. Canário é higiene, não integridade.
Integridade de verdade exige prova (ZKP sobre a computação homomórfica) ou hardware atestado. O preço publicado varia de ~2% a mais de 1000% conforme a primitiva — três ordens de grandeza. Enquanto isso não fechar, todo projeto com servidor potencialmente malicioso carrega um custo cujo tamanho plausível vai de desprezível a proibitivo.
Um ponto de segurança que raramente aparece em material comercial: para esquemas aproximados como o CKKS, a segurança IND-CPA clássica não basta se o resultado decifrado for compartilhado com terceiros.
É uma pergunta de triagem por si só: o resultado decifrado é compartilhado com terceiros? Se for, o parâmetro muda — e o custo é pequeno, desde que a pergunta seja feita antes de gerar as chaves.
O campo saiu do vácuo normativo: a ISO/IEC 28033 está em curso com a Parte 1 (geral) e a Parte 3 (CKKS) em Draft International Standard, a Parte 2 (BGV/BFV) com votação até abril de 2026, e as Partes 4 (tabelas de lookup) e 5 (troca de esquema) em elaboração. O NIST acompanha pelo projeto de criptografia com preservação de privacidade.
O que ainda falta é o que evitaria o modo de falha mais perigoso que medimos:
Com orçamento de 4 níveis, o BFV acerta até a 7ª multiplicação e erra na 8ª — em
silêncio. Nenhum erro, nenhuma exceção: devolve 28323 onde a resposta é
282. É a combinação mais perigosa que existe em produção, e a razão pela qual
o circuito precisa ser conhecido antes das chaves.
FHE fecha quando cinco condições valem juntas: lote grande · circuito raso (≤ 8 multiplicações) · decisão no cliente · universo de índice pequeno · servidor honesto-mas-curioso.
Tire uma, e o custo muda de ordem de grandeza. Tire a última, e o custo é desconhecido.
É por isso que a resposta para "FHE já está pronto?" nunca é sim ou não. Ela é: depende de qual das cinco você não tem — e essa é uma conversa de uma hora, com números, não de seis meses de prova de conceito.