A computação multipartidária assina com dois algoritmos de chave: ECDSA em secp256k1 e EdDSA em Ed25519 (em breve). Nesta página, abordamos o protocolo ECDSA de limite, o DKLS23 e as mudanças que o Google fez nele. Para ver os algoritmos compatíveis, consulte Blockchains compatíveis.
ECDSA de limite e DKLS23
Em contraste com outros esquemas de assinatura, o problema da assinatura de limite para o ECDSA é notoriamente difícil. Até 2017, a maioria das soluções envolvia compensações severas.
Em 2018, o DKLS apresentou a primeira solução para assinatura 2 de 2 para ECDSA que dependia apenas de suposições criptográficas baseadas em ECDSA (por exemplo, não exigia Paillier, RSA ou outra família diferente de suposições de dureza criptográfica). A ideia inovadora desse protocolo foi uma nova maneira de defender a segurança contra ataques maliciosos para uma abordagem baseada em MPC (tentativas anteriores de aplicar técnicas genéricas de MPC com segurança contra ataques maliciosos resultaram em protocolos que exigiam minutos para serem executados, em vez de milissegundos).
Melhorias subsequentes feitas pelos mesmos autores levaram a um protocolo k-out-of-n e, por fim, a melhoria DKLS23 levou a um framework genérico para ECDSA de limite k-out-of-n de 3 rodadas que capturou todas as abordagens anteriores e identificou a abordagem DKLS como a mais eficiente em métricas de performance notáveis. Em particular, essa versão do protocolo depende apenas de compromisso ideal e primitivas de multiplicação de duas partes. O protocolo resultante requer milissegundos de computação de um dígito por parte (resultando em uma ordem de magnitude de aceleração em relação às abordagens concorrentes) e, o mais importante, depende de primitivas criptográficas mais simples que usam apenas operações de curva elíptica (em contraste com as operações homomórficas e caras de Paillier, além de provas de intervalo de conhecimento zero e provas de boa formação de chaves criptográficas exigidas em outros trabalhos).
O protocolo foi avaliado internamente por vários auditores, incluindo especialistas contratados pela Coinbase e outros especialistas em criptografia. Doerner e Roy DR26 identificaram recentemente um erro de cálculo na análise de segurança do multiplicador DKLS que requer mais 22 invocações de OT para alcançar os 120 bits de segurança reivindicados. Essa mudança foi implementada. Da mesma forma, outros auditores externos apontaram detalhes ausentes na descrição do protocolo em relação às implicações da transmissão no modelo de canal ponto a ponto (em especial, é importante repetir alguns parâmetros de configuração para alcançar o conhecimento comum).
O trabalho subsequente do Google no protocolo fortaleceu substancialmente a implementação, reduziu os recursos necessários para operar o protocolo em escala e ampliou a funcionalidade do esquema. Por exemplo, a literatura acadêmica não especifica a seleção e a implementação do oráculo aleatório. Embora seja uma abstração acadêmica útil, a implementação do Random Oracle é uma tarefa sutil que levou a várias falhas documentadas por auditorias de segurança.
Um aspecto importante do nosso trabalho foi desenvolver um sistema de tipos (com base em duas operações de geração e bifurcação, além do uso rigoroso de sistemas de tipos para evitar a cópia, a movimentação e o aliasing de ponteiros para oráculos) para garantir que cada sessão e subsessão use um oráculo aleatório diferente.
Outra melhoria importante está relacionada à seleção de identificadores de sessão e subsessão. O modelo de UC e, portanto, todos os protocolos comprovadamente seguros nesse modelo, exigem que o ambiente forneça novos identificadores de sessão. Na prática, um sistema precisa garantir que o adversário não possa violar essa suposição, e isso geralmente exige que os participantes mantenham um estado ilimitado para essa finalidade. Aumentamos o protocolo DKLS original com rodadas extras para selecionar esse identificador de uma forma que requer apenas um estado de tamanho constante.
No geral, o protocolo atualizado e reforçado ainda conclui uma operação de assinatura em dezenas de milissegundos.
Em termos de funcionalidade, o artigo DKLS23 considera apenas a estrutura de acesso de limite k-out-of-n padrão. Na prática, os clientes podem exigir uma estrutura de acesso que imite as regras organizacionais. A literatura criptográfica contém muitas abordagens para projetar estruturas de acesso para compartilhamento de segredos. Aqui, estendemos o protocolo DKLS para oferecer suporte a estruturas de acesso mais gerais que podem ser compostas por portas de limite k-out-of-n. Isso permite políticas como "2 de 3 dos seguintes grupos: (a) o cliente, (b) 2 de 10 dos oficiais de controle de risco, (c) 2 de 3 dos líderes dos departamentos financeiro, jurídico e de contabilidade" etc.
Na API v1beta, essa estrutura de acesso é definida como a política de chave de um KeyRing, no campo keyPolicy. Todas as chaves criadas no KeyRing usam essa chave. Uma política de chave pode ter no máximo dois níveis: a regra de limite raiz e as regras de limite diretamente abaixo dela. Uma regra de limite na raiz não pode conter outra regra de limite.