Com criptografia homomórfica (FHE), um servidor faz contas sobre dados cifrados e devolve o resultado ainda cifrado: só quem tem a chave lê. Separamos 20 usos reais e dissemos, para cada um, se já fecha hoje ou se fica na fronteira, com os custos medidos na nossa bancada.
A faixa de cada aplicação é leitura nossa, a partir dos custos que medimos (Apple M2, uma linha de execução, Lattigo v6.2.0, média de 3 repetições) e da regra das cinco condições. Só a votação foi implementada de ponta a ponta. Números de terceiros estão marcados.
Imagine uma caixa de vidro trancada, com luvas embutidas. O dono põe o ouro dentro e fica com a chave. O joalheiro monta a joia pelas luvas: trabalha no ouro sem nunca poder tirá-lo da caixa. No fim, só o dono abre e vê a joia pronta.
A criptografia homomórfica faz isso com dados. O hospital, o banco ou o eleitor cifra o dado com a própria chave e manda para o servidor. O servidor soma, multiplica, aplica um modelo, tudo sobre o dado cifrado, e devolve o resultado ainda cifrado. Quem calculou nunca viu o dado nem o resultado.
As novas fechaduras pós-quânticas e a criptografia homomórfica se apoiam no mesmo tipo de problema matemático, o reticulado. Por isso a homomórfica também resiste a computador quântico. O resto do stack está em o que quebra, o que fica, o que trocar.
O dado cifrado carrega um "ruído" proposital, que é o que o torna seguro. Cada conta aumenta esse ruído, e a multiplicação aumenta muito mais que a soma. Depois de umas 8 multiplicações seguidas, o ruído passa do limite e o resultado sai errado.
O pior: sai errado em silêncio. Na nossa bancada, com orçamento para quatro níveis, o BFV acertou até a sétima multiplicação e na oitava devolveu 28323 onde a resposta era 282, sem erro nem aviso. Por isso o circuito precisa ser conhecido antes de gerar as chaves.
Para ir além do orçamento existe a "faxina" (bootstrap), que limpa o ruído: 1 min 18 s por operação no parâmetro de segurança real, com 10,26 GB de chaves. Funciona, mas vira trabalho de lote, não resposta de aplicativo.
Da nossa medição de maturidade saiu uma regra simples. A criptografia homomórfica é uma decisão de engenharia tranquila quando as cinco condições abaixo valem ao mesmo tempo. Tire uma, e o custo muda de ordem de grandeza.
As três faixas, com o número medido de cada uma, estão em Maturidade do FHE em 2026.
Filtre por setor e por faixa. "Com condição" quer dizer que o uso fecha hoje se a decisão final for tomada por quem tem a chave; se a decisão precisar ser tomada sob cifra, ele muda de faixa.
20 aplicações mostradas
Calcula sem abrir: o risco de uma doença a partir de glicose, IMC, idade e pressão, com um modelo simples.
Modelo raso. Fecha se o score voltar cifrado e o paciente, que tem a chave, ler o resultado.
Calcula sem abrir: se os marcadores de risco (BRCA1, APOE4) aparecem na sequência do paciente.
Comparar trechos exige comparação sob cifra. Com poucos marcadores e em lote, dá; busca aberta no genoma, não.
Calcula sem abrir: soma, média e contagem de pacientes de vários hospitais, sem que um veja os dados do outro.
Agregação em lote: circuito raso, nenhuma decisão sob cifra.
Calcula sem abrir: o score do cliente com um modelo linear, sem o banco ver a renda.
Fecha se o score voltar cifrado e a decisão (aprova ou não) for tomada por quem tem a chave. Decidir sob cifra muda de faixa.
Calcula sem abrir: a nota de anomalia de cada transação, sem o modelo ver valores e destinos.
Modelos de fraude costumam passar de 8 multiplicações seguidas e pedir a "faxina" do ruído.
Calcula sem abrir: "este cliente está na lista?", sem o banco revelar quem consulta e sem a lista vazar.
Interseção de conjuntos cresce em linha reta, com constante boa.
Calcula sem abrir: que os ativos superam os passivos, sem mostrar o balanço.
Pede comparação sob cifra e uma prova de que a conta foi feita direito.
Calcula sem abrir: o imposto devido pela tabela progressiva.
Tabela por faixas é uma sequência de comparações: poucas faixas, dá; é preciso misturar conta e lógica.
Calcula sem abrir: o resultado de cada proposta, com o voto pesado pelas ações.
Multiplicar pelo peso e somar: raso.
Calcula sem abrir: a contagem dos votos, com a chave dividida para ninguém abrir sozinho.
Soma em lote. Dividir a chave é gestão, não custo de conta.
Calcula sem abrir: a média de cada departamento, sem saber quem deu cada nota.
Agregação em lote.
Calcula sem abrir: quem deu o maior lance, sem revelar os lances perdedores.
Achar o maior é uma cadeia de comparações: com dezenas de lances, dá; com milhares, não.
Calcula sem abrir: se a soma dos preços cabe no orçamento, com cada preço numa faixa válida.
Somar é fácil; provar que cada preço está na faixa pede uma prova à parte.
Calcula sem abrir: a média dos salários e se cada pessoa está acima ou abaixo.
Fecha se o servidor devolver a média cifrada e cada pessoa comparar do lado dela.
Calcula sem abrir: regras sobre valores cifrados numa blockchain.
Dado minúsculo e valor alto por transação. Já roda em produção, por terceiros.
Calcula sem abrir: um registro numa base, sem o servidor saber qual foi consultado.
Fecha até dezenas de milhares de registros. Em dezenas de milhões, o servidor precisa tocar a tabela inteira e o tráfego explode.
Calcula sem abrir: a distância entre a digital ou o rosto e o cadastro, sem guardar a biometria em claro.
Conferir uma pessoa (1 para 1) é uma distância, conta rasa. Identificar entre milhões (1 para N) exige achar o mais parecido sob cifra, e isso não dá.
Calcula sem abrir: contagem de carros e pessoas por região, sem imagens nem localização.
Somar contadores.
Calcula sem abrir: quantas preferências duas pessoas têm em comum, sem ver as de ninguém.
Um produto interno.
Calcula sem abrir: a nota de cada item para o cliente, sem o servidor ver o que ele comprou.
Fecha se o servidor devolver as notas cifradas e o aplicativo escolher os melhores. Escolher os melhores sob cifra muda de faixa.
Não existe um FHE só. Há três famílias principais, e cada aplicação pede uma. O CKKS trabalha com números com vírgula, aproximados: médias, modelos, distâncias. O BGV (e o BFV) trabalha com inteiros exatos: contagens e votos. O TFHE trabalha bit a bit: é o que sabe comparar e decidir "se isto, então aquilo".
A diferença de custo entre as famílias é estrutural. Na nossa bancada, uma comparação lógica leva 1,74 s com TFHE, e trocar de família no meio da conta custa 13,9 s por posição. Por isso a regra de devolver a nota e decidir do lado de quem tem a chave: do lado dele, a mesma decisão custa microssegundos.
A criptografia homomórfica esconde o dado, mas não impede o servidor de mexer no resultado. E há um ataque simples: o servidor soma um valor ao dado cifrado e observa se o aplicativo aceita ou recusa o resultado. Essa reação é um bit, e repetida algumas dezenas de vezes entrega o dado.
Medimos: cerca de 47 consultas e 79 ms para recuperar um valor de 16 bits, com sucesso em 24 de 24 segredos. Posições de controle ("canários") pegam 100% de quem adultera às cegas, mas só 0,37% de quem escolhe onde mexer. Se o servidor pode ser malicioso, é preciso prova da conta ou hardware atestado, com custo publicado de ~2% a mais de 1000%.
Calcular sobre o dado cifrado sem abri-lo. Quem calcula não vê nem o dado nem o resultado.
A operação que limpa o ruído acumulado nas contas. Permite contas longas, mas custa mais de um minuto por operação.
O servidor devolve a nota cifrada e quem tem a chave decide. É o que faz a maioria destes usos fechar hoje.
Classificamos cada uso pelos custos medidos e pela regra das cinco condições. Só a votação foi implementada de ponta a ponta; os outros 19 são projeção.
Apple M2, uma linha de execução, Lattigo v6.2.0. Entre sessões, o mesmo teste varia até ~1,8×; as proporções entre operações são estáveis.
O "blockchain confidencial em produção" e o custo das provas de integridade vêm de publicações de terceiros, não da nossa bancada.
Todas as faixas supõem um servidor curioso mas honesto. Se ele puder adulterar, some o custo de uma prova, que pode ir de desprezível a proibitivo.
← FHE: calcular sem abrir o dado · stickybit.com.br