Uma caixa trancada com luvas por fora.
Pense numa caixa de vidro trancada, com luvas de borracha presas na parede. Você põe as peças lá dentro, tranca e entrega a caixa a um joalheiro. Ele monta o anel pelas luvas, sem nunca pegar as peças na mão, e devolve a caixa ainda trancada. Só você tem a chave.
É isso que a criptografia homomórfica (FHE, na sigla em inglês) faz com dados: o servidor calcula sobre o dado cifrado, sem nunca abri-lo, e devolve um resultado que só o dono da chave consegue ler. Serve para processar dado de saúde, financeiro ou pessoal numa nuvem em que você não precisa confiar.
O limite também aparece na analogia. Pelas luvas dá para somar e multiplicar. Olhar não dá: o joalheiro não consegue ver qual pedra é maior. Toda decisão ("qual é o maior?", "passou do limite?") é difícil sob cifra, e a saída mais barata quase sempre é devolver ao cliente para ele decidir.
Três documentos dizem que ficou prático. Nenhum publica os números lado a lado.
O anúncio do Google apresenta o HEIR e quatro demonstrações (recomendação, fraude de cartão, detecção de intrusão e palavra de ativação de voz), todas num único núcleo de processador e sem tempos publicados. O HEIR é o código. O artigo HE-LRM faz busca privada numa tabela de recomendação e declara de 24 s a 489 s.
A observação que organiza tudo: o HEIR não é um esquema novo nem um acelerador. É um compilador que gera código para as mesmas bibliotecas que usamos, a Lattigo inclusive. O teto de desempenho dele é, literalmente, o que esta bancada mede. Ele automatiza reescritas chatas e valiosas; não muda a física. Por isso as quatro demonstrações escolhidas são modelos rasos sobre dados já resumidos: exatamente a primeira coluna do quadro abaixo.
Somar, pontuar, agregar
- somar e multiplicar em lote
- produto interno, camada densa
- curvas suaves num intervalo garantido
- votação, contagens, gradientes federados
Profundo, dividido, grande
- muitas multiplicações seguidas
- dividir por valor cifrado
- a faxina (bootstrapping)
- banda e chaves do servidor
Decidir sob cifra
- comparar, achar o maior, ordenar
- ativação exata de rede neural (ReLU)
- buscar por posição cifrada em tabela grande
- qualquer "se" que dependa do dado cifrado
Em uma frase: FHE funciona hoje quando o cálculo é uma sequência fixa e rasa de somas e multiplicações, aplicada a um lote grande, com toda comparação e decisão empurradas para o cliente, que tem a chave.
Multiplicar é barato. Mover é caro.
A frase "FHE é lento porque multiplicar cifrado é caro" está errada. Multiplicar leva 2,7 ms. O caro é mover dados entre as posições de um pacote cifrado: somar um vetor de 2.048 números exige 12 movimentos e leva 112,8 ms, cerca de 40 vezes a multiplicação.
Daí vem o maior ganho da bancada. Arrumar os números nas posições certas antes de calcular (empacotar) deixou o placar de um catálogo 251 vezes mais rápido e uma camada densa de rede neural ~126 vezes, com a mesma biblioteca, os mesmos parâmetros e a mesma máquina.
"É só paralelizar" compra bem menos: com 4 núcleos, multiplicar escala 3,92 vezes, mas mover dados, que depende de memória, fica em 2,59. Com 8 núcleos, o rendimento cai.
Na prática: otimizar FHE é, antes de tudo, minimizar movimentos. É o que o HEIR automatiza, e é onde ele vale mais.
O penhasco da decisão.
Sob cifra existem só dois operadores: soma e produto. Comparar dois valores vira uma cadeia de nove polinômios que gasta 40 níveis do orçamento, contra os 4 a 8 de um conjunto de parâmetros normal. Sem faxina, não é lento: é impossível. E há uma zona cega medida: valores que diferem menos de 2⁻³⁰ (um bilionésimo) não têm comparação definida.
Com a faxina de verdade, a 128 bits reais, escolher o maior entre 4 levou 23 min 31 s e devolveu uma posição com só 3 bits de precisão. Entre 1.000 candidatos, a conta ancorada dá 130 horas. É lento e errado.
O outro dialeto, o TFHE, trabalha bit a bit e compara naturalmente (1,74 s por comparação de 8 bits), mas fica milhões de vezes mais lento em conta de lote. Existe uma ponte entre os dois: 13,9 s por posição. A escolha do dialeto é a decisão mais cara do projeto.
Na prática: devolva as notas cifradas e deixe o cliente decidir. Do lado de quem tem a chave, a mesma decisão custa microssegundos e não custa privacidade nenhuma.
A faxina, a banda e o tamanho da tabela.
A faxina custa 1 min 18 s a 128 bits reais, depois de o cliente enviar 10,26 GB de chaves. Gasta 15 níveis para devolver 10. E o conjunto de parâmetros "de brinquedo", que aparece em muito material publicado, é ~40 vezes mais rápido que o de segurança real.
A banda aparece antes da CPU. Em lote cheio, o dado cifrado ocupa 12 a 36 vezes o original; para um número sozinho, 229 mil vezes. Buscar uma linha numa tabela sem revelar qual exige tocar a tabela inteira: em 1 milhão de linhas, o cliente envia 1,91 GB para receber 16 números.
Cruzar listas de três bancos em sigilo custa em função do universo de identificadores, não do tamanho das listas: no universo dos CPFs, ~9 GB por banco, por rodada. Para cruzamento puro, a ferramenta certa é outra.
Na prática: FHE recompensa lote grande e pune consulta pontual. Dimensione pela banda, não só pelo tempo.
Atacar o preço, e publicar o que cada atalho cobra.
"Funciona, mas custa" não quer dizer impossível: quer dizer caro, e preço se ataca. Os quatro testes novos atacam os quatro itens caros mudando o cálculo, o protocolo ou o que viaja pelo fio. Cada um publica o ganho e o que ele cobra, porque um atalho que mostra só o ganho é propaganda.
O resultado tem um padrão: nenhum ganho veio de fazer FHE mais rápido; vieram de fazer menos FHE. O maior deles é não fazer a faxina: devolver o pacote ao cliente, que recifra em 1,04 s sem nenhuma chave de faxina, contra 1 min 18 s e 10,26 GB.
E o custo que sobra também tem padrão: os três atalhos mais baratos falham em silêncio. Barato e silencioso é a combinação que mais custa em produção.
Antes dos ataques, uma correção nesta bancada
Confrontamos os parâmetros com o teto de segurança da própria documentação da Lattigo. Dois números antigos não eram de 128 bits: as "8 multiplicações seguidas" (T2) e os 89 ms da divisão (T3). As medições estavam certas para aqueles parâmetros, mas mais fracos que o rótulo. No teto real, logN=13 comporta 2 níveis, não 8; e a divisão com a faixa real dos dados do SUS custa 2 min 36 s. A faxina (T4) e a escolha do maior (T9) já usavam 128 bits reais e não mudam.
| Teste | Atalho | Ganho medido | O que cobra |
|---|---|---|---|
| T13 | árvore em vez de fila | 28,4× mais fatores | 128× de memória |
| T14 | dividir no cliente | 57.690× | o quociente tem de ser final |
| T15 | devolver em vez da faxina | 75× · −10,26 GB | cliente online, e vê o meio da conta |
| T15 | faxina só quando precisa | 19,7× | profundidade conhecida antes |
| T16 | chave viaja como semente | 2,0000× | 3,7 s de preparo |
| T16 | cortar a resposta final | 10× | quebra acima de 2¹⁶ sem aviso |
Projete para caber, sem faxina.
Nenhuma das três fontes está errada: o HEIR é um projeto sério e o HE-LRM resolve um problema real. O que a bancada acrescenta é a escala, medida na mesma máquina, com a biblioteca que o próprio HEIR usa. A conclusão prática é chata e útil: dimensione o orçamento para caber o cálculo inteiro, empacote em lotes grandes, minimize movimentos e mande toda decisão para o cliente. Tudo que exige faxina frequente sai de "resposta de API" e entra em "tarefa em lote".
Antes de assinar um piloto de FHE
A pergunta que separa projeto viável de projeto caro é sempre a mesma: quantas multiplicações seguidas o cálculo tem, e onde acontece a decisão? Se a resposta envolve comparar no servidor, o orçamento está errado por uma ordem de grandeza. Fazemos esse laudo antes de você comprometer engenharia.
A operação que limpa o ruído acumulado nas contas cifradas e devolve orçamento. Possível, e cara: 1 min 18 s a 128 bits reais.
Quantas multiplicações seguidas cabem antes de o resultado virar ruído. É fixado junto com as chaves, antes de começar.
Um pacote cifrado carrega milhares de números lado a lado. Cheio, o custo se divide; com um número só, o custo inteiro cai sobre ele.
Onde isso pode estar errado.
Uma máquina, um laptop
Tudo foi medido num laptop Apple M-series. Entre sessões a mesma máquina varia até ~1,8×; dentro de uma sessão, menos de 10%. As razões entre operações viajam para outra máquina; os tempos absolutos, não.
Projeções declaradas
A escolha do maior entre 10, 100 e 1.000, a tabela de 10⁷ linhas e o universo de CPFs são projeções ancoradas numa medição real, e estão marcadas como tal. Nenhuma foi feita sem base.
Parâmetros abaixo do rótulo
Dois números antigos (T2 e a divisão do T3) usavam parâmetros mais fracos que 128 bits. Estão corrigidos acima; qualquer número de FHE publicado por terceiros merece a mesma pergunta: qual logN?
O que não medimos
Transcifragem (cifrar com AES e decifrar dentro do FHE), que mataria boa parte do problema de banda, não tem implementação na nossa biblioteca. Não medimos e não citamos número.
← FHE: calcular sem abrir o dado · stickybit.com.br
- Google: How Google is making private AI practical with homomorphic encryption · google/heir · arXiv:2506.18150, HE-LRM.
- Bancada própria (repositório FHE,
12_reality_check): Lattigo v6.2.0 (BGV/BFV/CKKS) e go-tfhe v0.2.2 (TFHE), média ± σ de 3 repetições, baseline de agosto de 2026. Cada número publicado tem um marcador de lastro conferido pelo próprio repositório. - Teto de segurança de 128 bits: documentação de parâmetros da Lattigo, seguindo o padrão da HomomorphicEncryption.org. Dados reais do T14: SIH/DATASUS, São Paulo, janeiro de 2024.