Vincular chaves criptográficas a identidades tem sido um problema desdea introdução da tecnologia. O desafio consiste em fornecer e manter um mapeamento publicamente disponível e consistente entre identidades e chaves públicas (para as quais essas identidades têm a chave privada). Sem tal mapeamento, mensagens destinadas a serem secretas podem correr mal - às vezes com resultados desastrosos. O mesmo desafio existe no web3.

Existem atualmente três soluções possíveis. As duas abordagens clássicas são um diretório de chave pública e criptografia baseada em identidade. O terceiro é a encriptação baseada em registos, que até há pouco tempo era inteiramente teórica. As três abordagens oferecem compensações diferentes entre anonimato, interatividade e eficiência, o que pode parecer claro no início, mas a configuração do blockchain introduz novas possibilidades e restrições. O objetivo deste post, então, é explorar esse espaço de design e comparar essas abordagens quando implantadas em um blockchain. Quando os usuários precisam de transparência e anonimato onchain, um esquema RBE prático é o vencedor claro — superando a forte suposição de confiança da criptografia baseada em identidade, mas a um custo.

As Três Abordagens em Breve

A abordagem clássica para vincular chaves criptográficas a identidades é uma infraestrutura de chave pública (PKI), com um diretório de chaves públicas no centro. Esta abordagem requer que um remetente em potencial interaja com uma terceira parte confiável (o mantenedor do diretório, ou autoridade de certificação) para enviar mensagens. Além disso, no ambiente web2, manter este diretório pode ser caro, tedioso e propenso a erros, e os utilizadores correm o risco de abuso pela autoridade de certificação.

Criptógrafos sugeriram alternativas para contornar os problemas com os PKIs. Em 1984, Adi Shamir sugeriuencriptação baseada em identidade (IBE), em que o identificador de uma parte - número de telefone, email, nome de domínio ENS - serve como chave pública. Isso elimina a necessidade de manter um diretório de chaves públicas, mas tem o custo de introduzir uma terceira parte confiável (o gerador de chaves). Dan Boneh e Matthew Franklin deram o primeira construção prática IBEem 2001, mas a IBE não recebeu uma adoção generalizada, exceto em ecossistemas fechados, como corporativos ouimplantações governamentais, talvez devido à forte suposição de confiança. (Como veremos abaixo, esta suposição pode ser parcialmente mitigada ao confiar em um quórum confiável de partes, o que uma blockchain pode facilmente facilitar).

Uma terceira opção, encriptação baseada em registro (RBE), foi propostoem 2018. RBE mantém a mesma arquitetura geral que IBE, mas substitui o gerador de chave confiável por um "curador de chave" transparente que realiza apenas cálculos em dados públicos (especificamente, acumula chaves públicas em uma espécie de "digest" publicamente disponível). A transparência deste curador de chaves torna o ambiente blockchain - onde um contrato inteligente pode desempenhar o papel de curador - uma correspondência natural para RBE. RBE era teórico até 2022, quando meus coautores e eu introduzimos o primeira construção RBE praticamente eficiente.

Avaliando as compensações

Este espaço de design é complexo e comparar esses esquemas requer levar em consideração muitas dimensões. Para simplificar, farei duas suposições:

1. Os usuários não atualizam ou revogam as suas chaves.
2. O contrato inteligente não utiliza nenhum serviço de disponibilidade de dados off-chain (DAS) ou dados de blob.

Vou discutir no final como cada uma dessas considerações adicionais pode afetar nossas três soluções potenciais.

Diretório de Chave Pública

Resumo: Qualquer pessoa pode adicionar uma entrada (id, pk) a uma tabela on-chain (o diretório) chamando o contrato inteligente, desde que o ID ainda não tenha sido reclamado.

Uma PKI descentralizada é essencialmente um contrato inteligente que mantém um diretório de identidades e suas respectivas chaves públicas. Por exemplo, o Registo de Serviço de Nomes Ethereum (ENS)mantém um mapeamento de nomes de domínio ("identidades") e seus metadados correspondentes, incluindo os endereços aos quais resolvem (a partir das transações das quais uma chave pública pode ser derivada). Um PKI descentralizado forneceria funcionalidades ainda mais simples: a lista mantida pelo contrato armazenaria apenas a chave pública correspondente a cada ID.

Para se registrar, um usuário gera um par de chaves (ou usa um par de chaves gerado anteriormente) e envia seu ID e chave pública para o contrato (talvez junto com algum pagamento). O contrato verifica se o ID ainda não foi reivindicado e, se não, adiciona o ID e a chave pública ao diretório. Neste ponto, qualquer pessoa pode criptografar uma mensagem para um usuário registrado, solicitando ao contrato a chave pública correspondente a um ID (se o remetente tiver criptografado algo para esse usuário antes, ele não precisa pedir o contrato novamente.) Com a chave pública, o remetente pode criptografar sua mensagem como de costume e enviar o texto cifrado para o destinatário, que pode usar a chave secreta correspondente para recuperar a mensagem.

Vamos dar uma olhada nas propriedades deste método.

No lado negativo do livro-razão:

• Não é sucinto. O diretório completo de chaves precisa ser armazenado na cadeia para que esteja sempre disponível para todos (lembre-se, por enquanto estamos assumindo que não há DAS). Para os ~900K nomes de domínio únicos registados no ENS no momento desta escrita, isso significa cerca de 90MB de armazenamento persistente. As partes registrantes precisam pagar pelo armazenamento que sua entrada ocupa, cerca de 65K gas (atualmente cerca de $1 - veja a avaliação de desempenho abaixo).
• Encriptação um pouco interativa. O remetente precisa ler a cadeia para recuperar a chave pública de um usuário, mas apenas se for a primeira vez que o remetente está a encriptar uma mensagem para esse usuário específico. (Lembre-se, estamos a assumir que os usuários não atualizam ou revogam as suas chaves.)
• Não anônimo do remetente. Quando recupera a chave pública de alguém, vincula-se ao destinatário, indicando que tem algum tipo de relacionamento com ele. Imagine, por exemplo, que recupere a chave pública do WikiLeaks: Isso poderia criar uma suspeita de que está vazando documentos classificados. Esse problema poderia ser mitigado com "tráfego de cobertura" (recuperar um grande lote de chaves, a maioria das quais não pretende usar) ou de forma semelhante executando um nó completo, ou com recuperação de informações privadas (RIP).

No lado positivo:

• Desencriptação não interativa. Os utilizadores desencriptam mensagens com a sua chave secreta armazenada localmente, por isso não requer interação.
• Transparente. A lista de usuários e chaves é completamente pública, então qualquer pessoa pode verificar se foram registrados corretamente ou não.
• Conjunto de ID arbitrário. O domínio dos IDs não é limitado a priori pela construção; teoricamente, o ID pode ser um cadeia de caracteres arbitrária (até às restrições impostas pela implementação específica do contrato e armazenamento).

Quando poderá querer utilizar um diretório de chaves públicas? Um diretório de chaves públicas descentralizado é fácil de configurar e gerir, por isso é uma boa escolha de referência. No entanto, se os custos de armazenamento ou a privacidade forem uma preocupação, uma das outras opções abaixo pode ser uma escolha melhor.

(Limiar) Encriptação Baseada em Identidade (IBE)

Resumo: A identidade de um usuário é a sua chave pública. É necessário um terceiro ou terceiros de confiança para emitir chaves e guardar um segredo mestre (porta de armadilha) durante toda a vida do sistema.

No IBE, um usuário não gera seu próprio par de chaves, mas se registra com um gerador de chaves confiável. O gerador de chaves tem um par de chaves "mestre" (msk, mpk na figura). Dado o ID de um usuário, o gerador de chaves usa a chave secreta mestra msk e o ID para calcular uma chave secreta para o usuário. Essa chave secreta tem de ser comunicada ao utilizador através de um canal seguro (que pode ser estabelecido com um protocolo de troca de chave).

IBE otimiza a experiência do remetente: baixa o mpk do gerador de chaves uma vez, após o que pode encriptar uma mensagem para qualquer ID usando o próprio ID. A desencriptação é igualmente simples: um usuário registado pode usar a chave secreta emitida pelo gerador de chaves para desencriptar o texto cifrado.

A chave secreta mestra do gerador de chaves é mais persistente do que a “resíduos tóxicos” gerados pelas cerimônias de configuração confiávelusado para alguns SNARKs. O gerador de chaves precisa disso para emitir novas chaves secretas, portanto, o gerador de chaves não pode apagá-lo depois de configurar a maneira como os participantes nas cerimônias SNARK fazem. Também é uma informação perigosa. Qualquer pessoa com o msk pode descriptografar todas as mensagens enviadas para qualquer usuário no sistema. Isso significa que há um risco constante de exfiltração com consequências catastróficas.

Mesmo que a msk seja mantida em segurança, todo usuário que se registra no sistema precisa confiar no gerador de chaves para não ler suas mensagens, já que o gerador de chaves pode manter uma cópia da chave secreta do usuário ou re-calcular a partir da msk a qualquer momento. Pode até ser possível para o gerador de chaves emitir uma chave secreta defeituosa ou "restrita" para o usuário que decifra todas as mensagens, exceto algumas proibidas determinadas pelo gerador de chaves.

Esta confiança pode, em vez disso, ser distribuída entre um quórum de geradores de chave, de modo que um usuário precise confiar apenas em um número limite deles. Nesse caso, um pequeno número de geradores de chave maliciosos não pode recuperar chaves secretas ou calcular chaves ruins, e um atacante teria que invadir vários sistemas para roubar o segredo mestre completo.

Se os usuários estiverem de acordo com essa suposição de confiança, o IBE (limite) vem com muitos benefícios:

• Armazenamento constante/mínimo na cadeia. Apenas a chave pública mestra (um único elemento de grupo) precisa ser armazenada na cadeia. Isso é muito menos do que o armazenamento necessário por um diretório de chave pública na cadeia. Para o IBE Boneh-Franklin sobre a curva BN254, isso significa adicionar 64 bytes de armazenamento persistente na cadeia uma vez durante a fase de configuração, exigindo que o serviço gaste apenas 40K de gás.
• Encriptação não interativa. Um remetente só precisa da chave pública mestra (que ele baixa uma vez no início) e do ID do destinatário para criptografar uma mensagem. Isso é diferente do diretório de chave pública, onde ele precisaria recuperar uma chave para cada novo usuário com quem deseja se comunicar.
• Descriptografia não interativa. Novamente, os usuários usam suas chaves secretas armazenadas localmente para descriptografar mensagens.
• Remetente-anônimo. O remetente não precisa recuperar informações específicas do destinatário da cadeia. Em comparação, no caso de um registro de chave pública, o remetente precisa interagir com o contrato de uma forma que depende do destinatário.
• Conjunto de IDs arbitrários. Tal como no registo de chave pública, os IDs podem ser cadeias de caracteres arbitrárias.

Mas!

• Forte pressuposto de confiança. Ao contrário do registo de chave pública, onde os utilizadores geram as suas próprias chaves, a IBE requer uma parte confiável ou um quórum de partes com um segredo mestre (porta dos fundos) para emitir chaves. O segredo mestre deve ser mantido durante toda a vida do sistema e pode comprometer todas as mensagens dos utilizadores registados se alguma vez for divulgado ou mal utilizado.

Quando é que poderá querer usar IBE (Identidade Baseada em Identidade)? Se uma terceira parte ou partes de confiança estiver disponível e os utilizadores estiverem dispostos a confiar neles, a IBE oferece uma opção muito mais eficiente em termos de espaço (e, portanto, mais barata) em comparação com um registo de chaves on-chain.

Criptografia baseada em registro (RBE)

Resumo: Semelhante ao IBE, a identidade do utilizador serve como a sua chave pública, mas a terceira parte de confiança/quórum é substituída por um acumulador transparente (chamado de "curador de chaves").

Nesta seção, discutirei a construção eficiente da RBE a partir de O meu artigo, uma vez que ao contrário do (que eu saiba) apenas outra construção prática, atualmente pode ser implantada em uma blockchain (sendo baseada em pares em vez de baseada em retículas). Quando eu digo "RBE", me refiro a esta construção específica, embora algumas afirmações possam ser verdadeiras para RBE em geral.

No RBE, um usuário gera seu próprio par de chaves e calcula alguns "valores de atualização" (a na figura) derivados da chave secreta e da cadeia de referência comum (CRS). Embora a presença de um CRS signifique que a configuração não é completamente não confiável, o CRS é um potências-de-tauconstrução, que pode sercomputado colaborativamente na cadeiae é seguro desde que tenha uma única contribuição honesta.

O contrato inteligente é configurado para um número esperado de usuários N, agrupados em buckets. Quando um usuário se registra no sistema, ele envia sua ID, chave pública e valores de atualização para o contrato inteligente. O contrato inteligente mantém um conjunto de parâmetros públicos pp (distintos do CRS), que podem ser pensados como um "resumo" sucinto das chaves públicas de todas as partes registadas no sistema. Quando recebe uma solicitação de registro, ele executa uma verificação nos valores de atualização e multiplica a chave pública no bucket apropriado de pp.

Os utilizadores registados também precisam de manter alguma “informação auxiliar” localmente, que usam para ajudar na desencriptação e que é adicionada sempre que um novo utilizador se regista no mesmo grupo. Eles podem atualizar isto por si próprios monitorizando o blockchain para registos no seu grupo, ou o smart contract pode ajudar mantendo uma lista dos valores de atualização que recebeu dos registos mais recentes (digamos, dentro da última semana), que os utilizadores podem consultar periodicamente (pelo menos uma vez por semana).

Os remetentes deste sistema descarregam o SIR uma vez e, ocasionalmente, descarregam a versão mais recente dos parâmetros públicos. Para os parâmetros públicos, tudo o que importa do ponto de vista do remetente é que eles incluam a chave pública do destinatário pretendido; não precisa ser a versão mais atualizada. O remetente pode então usar o CRS e os parâmetros públicos, juntamente com o ID do destinatário, para criptografar uma mensagem para o destinatário.

Ao receber uma mensagem, o usuário verifica as informações auxiliares armazenadas localmente para um valor que atenda a algumas condições. (Se não encontrar nenhum, significa que precisa buscar uma atualização do contrato.) Usando esse valor e sua chave secreta, o usuário pode descriptografar o texto cifrado.

É evidente que este regime é mais complexo do que os outros dois. Mas requer menos armazenamento on-chain do que o diretório de chave pública, evitando a forte suposição de confiança do IBE.

• Parâmetros concisos. O tamanho dos parâmetros a serem armazenados na cadeia é sublinear em relação ao número de usuários. Isso é muito menor do que o armazenamento total necessário para um diretório de chaves públicas (linear em relação ao número de usuários), mas ainda não é constante e, portanto, pior em comparação com IBE.
• Encriptação um pouco interativa. Para enviar uma mensagem, o remetente precisa de uma cópia dos parâmetros públicos que contém o destinatário pretendido. Isso significa que ele precisa atualizar os parâmetros em algum momento depois que um destinatário pretendido se registra, mas não necessariamente para cada destinatário pretendido que se registra, uma vez que uma atualização pode incluir chaves de vários destinatários. No geral, o envio de mensagens é mais interativo do que IBE, mas menos interativo do que um diretório.
• Descriptografia um tanto interativa. Semelhante ao caso de criptografia, o destinatário precisa de uma cópia das informações auxiliares que "correspondem" à versão dos parâmetros públicos utilizados para a criptografia. Mais especificamente, tanto o parâmetro público quanto os buckets auxiliares são atualizados sempre que um novo usuário se cadastra nesse bucket, e o valor capaz de descriptografar um texto cifrado é aquele correspondente à versão dos pp utilizada para criptografar. Assim como as atualizações dos parâmetros públicos, um usuário pode optar por recuperar as atualizações dos auxiliares apenas periodicamente, exceto quando a descriptografia falha. Ao contrário das atualizações dos parâmetros públicos, recuperar as atualizações dos auxiliares com mais frequência não revela informações inerentemente.
• Remetente-anônimo. Como no caso do diretório, o remetente pode criptografar uma mensagem completamente por conta própria (desde que tenha parâmetros atualizados) sem consultar informações específicas do destinatário. As informações lidas a partir da cadeia, quando necessário, são independentes do destinatário pretendido. (Para reduzir a comunicação, o remetente poderia solicitar apenas um bucket pp específico, vazando informações parciais.)
• Transparente. Embora o sistema precise ser configurado usando uma cerimônia de configuração confiável (potencialmente distribuída e/ou administrada externamente) que produz uma CRS perfurada, ele não depende de nenhuma parte confiável ou quórum depois que a configuração foi concluída: embora dependa de uma terceira parte coordenadora (o contrato), é completamente transparente e qualquer pessoa pode ser um coordenador ou verificar se estão se comportando honestamente, confirmando suas transições de estado (é por isso que pode ser implementado como um contrato inteligente). Além disso, os usuários podem solicitar uma prova concisa de adesão (não) para verificar se eles (ou qualquer outra pessoa) estão registrados/não registrados no sistema. Isso difere do caso IBE, onde é difícil para a parte/partes confiáveis realmente provar que não revelaram secretamente uma chave de descriptografia (para si próprios fazendo uma cópia secreta ou para outra pessoa). O diretório de chave pública, por outro lado, é totalmente transparente.
• Conjunto de ID restrito. Eu descrevi uma versão "básica" da construção RBE. Para determinar de forma transparente em qual bucket um ID se enquadra, os IDs devem ter uma ordem pública e determinística. Os números de telefone podem simplesmente ser colocados em ordem, mas ordenar cadeias arbitrárias é pesado, se não impossível, uma vez que o número de buckets pode ser extremamente grande ou ilimitado. Isso poderia ser mitiGated oferecendo um contrato separado que calcula tal mapeamento ou adotando a abordagem de cuckoo-hashing proposta em este trabalho de acompanhamento.

Com extensões:

• Destinatário-anônimo. o esquema pode ser estendido para que os textos cifrados não revelem a identidade do destinatário.

Quando você pode querer usar o RBE? O RBE usa menos armazenamento on-chain do que um registro on-chain e, ao mesmo tempo, evita as fortes suposições de confiança exigidas pelo IBE. Em comparação com um registro, o RBE também oferece garantias de privacidade mais fortes para o remetente. No entanto, como o RBE apenas se tornou uma opção viável para o gerenciamento de chaves, ainda não temos certeza de quais cenários se beneficiariam mais dessa combinação de propriedades. Por favor deixe-me saber se você tiver alguma idéia.

Comparação de desempenho

Estimei os custos (em 30 de julho de 2024) da implantação de cada uma dessas três abordagens on-chain em este notebook Colab. Os resultados para uma capacidade do sistema de ~900K usuários (o número de nomes de domínio exclusivos registados na ENS no momento da escrita) são mostrados na tabela abaixo.

PKI não tem custo de configuração e um baixo custo de registro por usuário, enquanto IBE tem um pequeno custo de configuração e registro praticamente gratuito por usuário. O RBE tem um custo de configuração mais alto e também um custo de registro inesperadamente alto, apesar do baixo armazenamento on-chain necessário.

A maior parte do custo de registro (assumindo que o cálculo é feito em um L2) vem do fato de que as partes devem atualizar um pedaço dos parâmetros públicos no armazenamento persistente, o que resulta em um alto custo de registro.

Embora a RBE seja mais cara do que as alternativas, esta análise mostra que ela pode ser implantada de forma viável na Ethereum mainnet hoje, sem as suposições de confiança potencialmente arriscadas do PKI ou IBE. E isso é antes de otimizações como implantar várias instâncias menores (e, portanto, mais baratas) ou usar dados de blob. Dado que a RBE possui vantagens sobre o diretório de chaves públicas e IBE na forma de anonimato mais forte e suposições de confiança reduzidas, ela pode ser atraente para aqueles que valorizam a privacidade e configurações sem confiança.

Noemi Glaeseré candidata a doutoramento em Ciência da Computação na Universidade de Maryland e no Instituto Max Planck para a Segurança & Privacidade e foi estagiária de pesquisa na criptografia a16z durante o verão de ‘23. Ela é beneficiária da Bolsa de Investigação de Pós-Graduação da NSF e foi anteriormente estagiária de pesquisa na NTT Research.

Apêndice: Considerações adicionais

Lidar com atualizações/anulações de chave

No caso de um diretório de chave pública, lidar com atualizações de chave e revogações é simples: para revogar uma chave, uma parte pede ao contrato para apagá-la do diretório. Para atualizar uma chave, a entrada (id, pk) é substituída por uma nova chave (id, pk’).

Para revogação no IBE, Boneh e Franklin sugeriram que os usuários atualizassem periodicamente suas chaves (por exemplo, todas as semanas) e que os remetentes incluíssem o período de tempo atual na cadeia de caracteres de identidade ao criptografar (por exemplo, "Bob "). Devido à natureza não interativa da criptografia, os remetentes não têm como saber quando um usuário revoga sua chave, portanto, algumas atualizações de período são inerentes. Boldyreva, Goyal e Kumar deram um Mecanismo de revogação mais eficientebaseado emIBE “Fuzzy”que requer duas chaves para descriptografia: uma chave de 'identidade' e uma chave adicional de 'tempo'. Dessa forma, apenas a chave de tempo precisa ser atualizada regularmente. As chaves de tempo dos usuários são acumuladas em uma árvore binária, e um usuário pode usar qualquer nó ao longo do caminho (no caso básico, apenas a raiz é necessária e é a única parte que é publicada pelo gerador de chaves). A revogação da chave é alcançada ao não publicar mais atualizações para um usuário específico (excluindo nós ao longo do caminho desse usuário na árvore), nesse caso o tamanho da atualização aumenta, mas nunca é maior que logarítmico no número de usuários.

Nossa eficiente construção RBE não considerou atualizações e revogações, um trabalho de acompanhamento dá um compilador que pode "atualizar" nosso esquema para adicionar essas funcionalidades.

Mover dados off-chain com DAS

Usar uma solução de disponibilidade de dados (DAS) para mover o armazenamento on-chain off-chain afetaria apenas o cálculo do diretório de chave pública e RBE, reduzindo ambos para a mesma quantidade de armazenamento on-chain. RBE manteria a vantagem de ser mais privado para o remetente, já que ainda evita vazar a identidade do destinatário por meio de padrões de acesso. IBE já tinha armazenamento mínimo on-chain e não se beneficiaria do DAS.

Aviso Legal:

1. Este artigo é republicado a partir de [a16zcrypto], Todos os direitos autorais pertencem ao autor original [Noemi Glaeser]. Se houver objeções a esta reimpressão, entre em contato com oGate Aprender equipe, e eles vão lidar com isso prontamente.
2. Aviso de responsabilidade: As opiniões expressas neste artigo são exclusivamente do autor e não constituem qualquer conselho de investimento.
3. As traduções do artigo para outros idiomas são feitas pela equipe Gate Learn. Salvo indicação em contrário, copiar, distribuir ou plagiar os artigos traduzidos é proibido.