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

Atualmente existem três soluções possíveis. As duas abordagens clássicas são um diretório de chaves públicas e criptografia baseada em identidade. A terceira é a criptografia baseada em registro, que até recentemente era totalmente teórica. As três abordagens oferecem diferentes compensações entre anonimato, interatividade e eficiência, o que pode parecer claro a princípio, mas o ambiente de blockchain introduz novas possibilidades e restrições. O objetivo deste post, então, é explorar esse espaço de design e comparar essas abordagens quando implementadas em um blockchain. Quando os usuários precisam de transparência e anonimato on-chain, um esquema prático de RBE é o grande vencedor, 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 seu núcleo. Esta abordagem requer que um remetente em potencial interaja com uma terceira parte confiável (o mantenedor do diretório, ou autoridade certificadora) para enviar mensagens. Além disso, no ambiente web2, manter este diretório pode ser custoso, tedioso e propenso a erros, e os usuários correm o risco de abuso pela autoridade certificadora.

Criptógrafos sugeriram alternativas para contornar os problemas dos PKIs. Em 1984,Adi Shamir sugeriucriptografia baseada em identidade (IBE), na qual o identificador de uma parte - número de telefone, e-mail, 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 aprimeira construção prática de IBEem 2001, mas a IBE não recebeu adoção generalizada, exceto em ecossistemas fechados, como corporativos ouimplantações do governo, talvez devido à forte suposição de confiança. (Como veremos abaixo, essa suposição pode ser parcialmente mitigada ao contar com um quórum confiável de partes, o que uma blockchain pode facilitar facilmente.)

Uma terceira opção, criptografia baseada em registro (RBE), foi propostoem 2018. RBE mantém a mesma arquitetura geral que IBE, mas substitui o gerador de chaves confiável por um "curador de chaves" transparente que apenas realiza cálculos em dados públicos (especificamente, acumula chaves públicas em uma espécie de "resumo" publicamente disponível). A transparência deste curador de chaves torna o ambiente de blockchain - onde um contrato inteligente pode desempenhar o papel do curador - uma combinação natural para RBE. RBE era teórico até 2022, quando meus co-autores 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 as coisas, farei duas suposições:

1. Os usuários não atualizam ou revogam 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 poderia 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 reivindicado.

Um PKI descentralizado é essencialmente um smart contract que mantém um diretório de identidades e suas chaves públicas correspondentes. Por exemplo, o Registro 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 eles se resolvem (a partir das transações das quais uma chave pública pode ser derivada). Um PKI descentralizado forneceria funcionalidade 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 previamente gerado) 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, caso não tenha sido, 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 já tiver criptografado algo para este usuário antes, não precisará perguntar ao 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 de chaves completo precisa ser armazenado on-chain para que esteja sempre disponível para todos (lembre-se, por enquanto estamos assumindo que não há DAS). Para o ~900K nomes de domínio únicos registrados no ENS no momento desta escrita, isso significa quase 90MB de armazenamento persistente. As partes registradas precisam pagar pelo armazenamento que sua entrada ocupa, cerca de 65K gas (atualmente aproximadamente $1 - veja a avaliação de desempenho abaixo).
• Criptografia um pouco interativa. O remetente precisa ler a cadeia para recuperar a chave pública do usuário, mas apenas se for a primeira vez que o remetente está criptografando uma mensagem para esse usuário específico. (Lembre-se de que estamos assumindo que os usuários não atualizam ou revogam suas chaves).
• Não é anônimo do remetente. Quando você recupera a chave pública de alguém, você se vincula ao destinatário, indicando que você tem algum tipo de relacionamento com eles. Imagine, por exemplo, que você recupera a chave pública do WikiLeaks: Isso poderia criar uma suspeita de que você está vazando documentos classificados. Esse problema pode ser mitigado com 'tráfego de cobertura' (recuperar um grande lote de chaves, a maioria das quais você não pretende usar) ou de forma semelhante executando um nó completo ou com recuperação de informações privadas (PIR).

No lado positivo:

• Descriptografia não interativa. Os usuários descriptografam mensagens com sua chave secreta armazenada localmente, portanto, não requer interação.
• Transparente. A lista de usuários e chaves é completamente pública, para que qualquer pessoa possa verificar se foram registrados corretamente.
• Conjunto de ID arbitrário. O domínio dos IDs não é limitado a priori pela construção; em teoria, o ID pode ser um.stringue arbitrário (até as restrições impostas pela implementação e armazenamento específicos do contrato).

Quando você pode querer usar um diretório de chaves públicas? Um diretório de chaves públicas descentralizado é fácil de configurar e gerenciar, portanto, é uma escolha básica boa. 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.

Criptografia de criptografia baseada em identidade (IBE) (Limite)

Resumo: A identidade de um usuário é a sua chave pública. É necessário um terceiro confiável ou partes para emitir chaves e manter um segredo mestre (porta dos fundos) durante a vida útil do sistema.

No IBE, um usuário não gera seu próprio par de chaves, mas sim se registra em um gerador de chaves confiável. O gerador de chaves possui 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 deve ser comunicada ao usuário por meio de um canal seguro (que pode ser estabelecido com um protocolo de troca de chaves).

IBE otimiza a experiência do remetente: ele baixa o mpk do gerador de chaves uma vez, após o qual pode criptografar uma mensagem para qualquer ID usando o próprio ID. A descriptografia também é simples: um usuário registrado pode usar a chave secreta emitida pelo gerador de chaves para descriptografar o texto cifrado.

A chave secreta mestra do gerador de chaves é mais persistente que a “resíduos tóxicos” gerados pelas cerimônias de configuração confiávelusado para alguns SNARKs. O gerador de chaves precisa dele para emitir novas chaves secretas, então o gerador de chaves não pode apagá-lo após a configuração da maneira que os participantes das cerimônias SNARK fazem. Também é uma peça de 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 o msk seja mantido em segurança, todo usuário que se registra no sistema precisa confiar no gerador de chaves para não ler suas mensagens, pois o gerador de chaves pode manter uma cópia da chave secreta do usuário ou re-calcular a partir do msk a qualquer momento. Talvez até seja possível para o gerador de chaves emitir uma chave secreta defeituosa ou “restrita” para o usuário que descriptografa todas as mensagens, exceto algumas proibidas, conforme determinado pelo gerador de chaves.

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

Se os usuários estiverem OK com essa suposição de confiança, (limiar) IBE 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 chaves públicas 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.
• Criptografia 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 contrasta com o diretório de chaves públicas, 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 nenhuma informação por destinatário da cadeia. Em comparação, no caso de um registro de chave pública, o remetente tem que interagir com o contrato de uma maneira que depende do destinatário.
• Conjunto de ID arbitrário. Assim como no registro de chave pública, os IDs podem ser sequências arbitrárias de caracteres.

Mas!

• Forte pressuposto de confiança. Ao contrário do registro de chave pública, onde os usuários geram 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 útil do sistema e pode comprometer todas as mensagens dos usuários registrados se for vazado ou mal utilizado.

Quando você pode querer usar (threshold) IBE? Se uma terceira parte ou partes confiáveis estiver disponível e os usuários estiverem dispostos a confiar neles, o IBE oferece uma opção muito mais eficiente em termos de espaço (e, portanto, mais barata) em comparação com um registro de chaves on-chain.

Criptografia baseada em registro (RBE)

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

Nesta seção, discutirei a construção eficiente de RBE a partir demeu papel, pois ao contrário do que eu sei, apenas outra construção prática, atualmente ela pode ser implantada em uma blockchain (sendo baseada em pares em vez de baseada em grades). Sempre que eu digo "RBE", estou me referindo a esta construção específica, embora algumas afirmações possam ser verdadeiras em relação a 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 string de referência comum (CRS). Embora a presença de um CRS signifique que a configuração não é totalmente confiável, o CRS é uma powers-of-tau construção, que pode ser calculado em colaboração on-chaine é seguro desde que haja 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 pode ser pensado como um "resumo" sucinto das chaves públicas de todas as partes cadastradas no sistema. Quando ele 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 usuários registrados também precisam manter localmente algumas “informações auxiliares”, que são usadas para ajudar na decodificação e que são adicionadas sempre que um novo usuário se registra no mesmo grupo. Eles podem atualizar essas informações monitorando o blockchain para registros em seu grupo, ou o contrato inteligente pode ajudar mantendo uma lista dos valores de atualização que recebeu dos registros mais recentes (digamos, nos últimos sete dias), que os usuários podem buscar periodicamente (pelo menos uma vez por semana).

Os remetentes neste sistema baixam o CRS uma vez e ocasionalmente baixam 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 suas informações auxiliares armazenadas localmente para um valor que passe em alguma verificação. (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.

Claramente, este esquema é 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 sucintos. 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 chave pública (linear em relação ao número de usuários), mas ainda não é constante e, portanto, pior em comparação com o IBE.
• Criptografia 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 precisa atualizar os parâmetros em algum momento após o registro de um destinatário pretendido, mas não necessariamente para cada destinatário pretendido que se registra, já que uma atualização pode incluir as 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 'corresponde' à versão dos parâmetros públicos usados ​​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 registra naquele bucket, e o valor capaz de descriptografar um texto cifrado é aquele correspondente à versão do pp usado para criptografar. Assim como as atualizações dos parâmetros públicos, um usuário pode decidir recuperar as atualizações auxiliares apenas periodicamente, exceto quando a descriptografia falha. Ao contrário das atualizações dos parâmetros públicos, recuperar as atualizações auxiliares com mais frequência não vaza informações inherentemente.
• Remetente-anônimo. Assim como no caso de 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 da cadeia, quando necessário, são independentes do destinatário pretendido. (Para reduzir a comunicação, o remetente pode solicitar apenas um determinado pp bucket, 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) emitindo um CRS furado, ele não depende de nenhuma parte confiável ou quórum depois que a configuração foi concluída: embora dependa de um terceiro coordenador (o contrato), é completamente transparente e qualquer pessoa pode ser um coordenador ou verificar se está 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 um comprovante sucinto de (não-)adesão para verificar se eles (ou qualquer outra pessoa) estão registrados/não cadastrados no sistema. Isso contrasta com o caso do IBE, onde é difícil para a parte/partes confiáveis realmente provar que não revelaram secretamente uma chave de descriptografia (para si mesmos 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 transparentemente em qual balde um ID se encaixa, os IDs devem ter uma ordem pública e determinística. Os números de telefone podem ser simplesmente colocados em ordem, mas ordenar strings arbitrárias é difícil se não impossível, já que o número de baldes pode ser extremamente grande ou ilimitado. Isso pode ser mitigado ao oferecer um contrato separado que calcule tal mapeamento ou adotando a abordagem de hash de cuco proposta em Gate.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 RBE? RBE usa menos armazenamento on-chain do que um registro on-chain, ao mesmo tempo em que evita as fortes suposições de confiança requeridas por IBE. Em comparação com um registro, RBE também oferece garantias de privacidade mais fortes para o remetente. No entanto, como RBE acabou de se tornar uma opção viável para gerenciamento de chaves, ainda não temos certeza de quais cenários se beneficiariam mais dessa combinação de propriedades. me avisese você tiver alguma ideia.

Comparação de Desempenho

Eu estimei os custos (em 30 de julho de 2024) de implantar cada uma dessas três abordagens on-chain emeste bloco de notas do Colab. Os resultados para uma capacidade do sistema de ~900K usuários (o número de nomes de domínio únicos registrados no ENS no momento desta 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 praticamente um registro gratuito por usuário. RBE tem um custo de configuração mais alto e também um custo de registro inesperadamente alto, apesar do baixo armazenamento em cadeia necessário.

A maior parte do custo de registro (assumindo que o cálculo seja 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 RBE seja mais caro do que as alternativas, esta análise mostra que ele pode ser implantado de forma viável na rede principal Ethereum hoje - sem os potencialmente arriscados pressupostos de confiança do PKI ou do IBE. E isso é antes das otimizações, como implantar várias instâncias menores (e, portanto, mais baratas) ou usar dados de blob. Dado que o RBE tem vantagens sobre o diretório de chave pública e o IBE na forma de anonimato mais forte e pressupostos de confiança reduzidos, ele poderia ser atraente para aqueles que valorizam a privacidade e configurações sem confiança.

Noemi Glaeseré uma candidata a PhD em Ciência da Computação na Universidade de Maryland e no Instituto Max Planck de Segurança e Privacidade e foi estagiária de pesquisa na a16z crypto durante o verão de '23. Ela é bolsista de pesquisa de pós-graduação da NSF e foi estagiária de pesquisa anteriormente na NTT Research.

Apêndice: Considerações adicionais

Lidando com atualizações/revoações de chaves

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) é sobrescrita com uma nova chave para (id, pk’).

Para revogação no IBE, Boneh e Franklin sugeriram que os usuários atualizassem periodicamente suas chaves (por exemplo, toda semana) 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 eficiente com base em IBE "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 da RBE não considerou atualizações e revogações, uma trabalho de acompanhamentofornece um compilador que pode "atualizar" nosso esquema para adicionar essas funcionalidades.

Movendo dados off-chain com DAS

Usar uma solução de disponibilidade de dados (DAS) para mover o armazenamento na cadeia para fora da cadeia só afetaria o cálculo para o diretório de chaves públicas e RBE, reduzindo ambos para a mesma quantidade de armazenamento na cadeia. RBE manteria a vantagem de ser mais privado para o remetente, pois ainda evita vazamento da identidade do destinatário por meio de padrões de acesso. IBE já tinha armazenamento mínimo na cadeia e não se beneficiaria do DAS.

Disclaimer:

1. Este artigo é reproduzido de [ a16zcrypto], Todos os direitos autorais pertencem ao autor original [Noemi Glaeser ]. Se houver objeções a esta reimpressão, entre em contato com o Gate Aprendaequipe e eles vão cuidar disso prontamente.
2. Isenção de responsabilidade: Os pontos de vista e opiniões expressos 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. A menos que seja mencionado, copiar, distribuir ou plagiar os artigos traduzidos é proibido.