ECDSA (Algoritmo de Assinatura Digital de Curva Elíptica)

O que é ECDSA?

ECDSA é a sigla em inglês para Elliptic Curve Digital Signature Algorithm, ou Algoritmo de Assinatura Digital de Curva Elíptica.

É um algoritmo de criptografia de chave pública usado para criar e verificar assinaturas digitais com matemática de curvas elípticas.

As carteiras de criptomoedas usam ECDSA para comprovar que uma transação foi autorizada pelo detentor de determinada chave privada.

A chave privada cria a assinatura, enquanto a chave pública correspondente permite que os nós da blockchain a verifiquem.

A chave privada não precisa ser revelada durante a verificação.

Uma assinatura ECDSA válida também demonstra que os dados assinados da transação não foram alterados desde a criação da assinatura.

O atual NIST Digital Signature Standard inclui ECDSA como uma técnica de assinatura digital aprovada para aplicações criptográficas federais compatíveis.

ECDSA é um algoritmo, não uma blockchain, carteira, criptomoeda, método de criptografia de dados ou curva elíptica.

Uma implementação completa também precisa selecionar uma curva, parâmetros de domínio, função hash, método de geração de chave privada, codificação de assinatura e regras para o formato das mensagens.

Por que as criptomoedas usam ECDSA

Uma rede descentralizada de criptomoedas precisa verificar a autorização de gastos sem depender de um banco de dados centralizado de contas.

ECDSA permite que cada usuário controle uma conta ou uma saída que pode ser gasta por meio de uma chave privada secreta.

Quando o usuário deseja transferir criptoativos, a carteira cria uma transação e assina os dados necessários.

Os outros participantes da rede verificam a assinatura com a chave pública e as regras de validação do protocolo.

De acordo com as premissas atuais sobre computação clássica, é extremamente difícil falsificar uma assinatura gerada corretamente sem a chave privada.

Isso permite que os nós da blockchain rejeitem transferências não autorizadas e, ao mesmo tempo, aceitem transações válidas em uma rede pública.

Em níveis semelhantes de segurança clássica, ECDSA também gera chaves e assinaturas relativamente compactas em comparação com alguns sistemas antigos de chave pública.

Assinaturas compactas são importantes porque cada byte adicional pode aumentar a largura de banda da rede, o armazenamento da blockchain e os custos de transação.

ECDSA é um algoritmo de assinatura, não de criptografia de dados

ECDSA comprova autorização e integridade da mensagem, mas não oculta os dados assinados.

A maioria das transações públicas de criptomoedas continua visível aos participantes da blockchain, mesmo quando inclui assinaturas ECDSA.

Uma assinatura não criptografa o endereço de destino, o valor transferido, a taxa de transação nem as instruções de um contrato inteligente.

A criptografia transforma informações legíveis em texto cifrado, que exige uma chave de decifração.

Em vez disso, ECDSA produz evidências matemáticas de que uma chave privada autorizou uma mensagem específica.

A privacidade depende de técnicas criptográficas, arquiteturas de protocolo ou controles de aplicação separados.

Fundamentos das curvas elípticas

ECDSA opera em um grupo matemático formado por pontos de uma curva elíptica sobre um campo finito.

Uma forma comum de curva é escrita como

, com todos os cálculos de coordenadas realizados usando aritmética modular.

Os parâmetros de domínio da curva definem o campo, os coeficientes da curva, o ponto gerador, a ordem do gerador e o cofator.

O ponto gerador costuma ser representado por

.

A ordem do gerador costuma ser representada por

.

Implementações seguras usam parâmetros padronizados e cuidadosamente analisados, em vez de inventar uma nova curva para uma aplicação específica.

A recomendação do NIST sobre parâmetros de domínio de curvas elípticas documenta curvas aprovadas para as aplicações abrangidas por esse padrão.

Chaves privadas e chaves públicas

Uma chave privada ECDSA é um número inteiro secreto, geralmente representado por

.

O valor precisa ser escolhido dentro do intervalo válido entre 1 e

.

A chave pública é calculada por multiplicação escalar de curva elíptica.

A relação costuma ser escrita como

.

Calcular

a partir de e é eficiente.

Considera-se computacionalmente impraticável recuperar

a partir de quando se usa uma curva segura e uma chave gerada corretamente.

Essa relação unidirecional se baseia na dificuldade do problema do logaritmo discreto em curvas elípticas.

Qualquer pessoa que obtenha a chave privada pode gerar assinaturas válidas e, normalmente, controlar os criptoativos associados.

O que é secp256k1?

secp256k1 é a curva elíptica mais fortemente associada ao ECDSA no mercado de criptomoedas.

Ela é usada nas assinaturas tradicionais de transações do Bitcoin e nas assinaturas de contas de propriedade externa do Ethereum.

A equação da curva é

sobre um campo primo grande.

O tamanho do campo e a ordem do grupo da curva são próximos de 256 bits.

Seu nível estimado de segurança clássica costuma ser descrito como aproximadamente 128 bits contra ataques genéricos de logaritmo discreto.

secp256k1 é diferente da NIST P-256, embora ambas sejam comumente descritas como curvas elípticas de 256 bits.

Chaves e assinaturas criadas para uma curva não podem ser simplesmente verificadas usando a outra.

O projeto mantido libsecp256k1 oferece funções otimizadas de assinatura e verificação ECDSA, geração e análise de chaves e recuperação de chave pública para secp256k1.

Como uma assinatura ECDSA é criada

O processo de assinatura começa com uma chave privada, uma mensagem, uma função hash criptográfica e os parâmetros da curva selecionada.

A mensagem é processada de acordo com as regras exatas de serialização do protocolo da criptomoeda.

A mensagem serializada passa por uma função hash, produzindo um resumo geralmente representado por

.

O signatário escolhe um valor secreto usado uma vez por assinatura, comumente chamado de nonce e representado por

.

O nonce precisa ser um número inteiro válido, diferente de zero e inferior à ordem da curva.

O signatário calcula o ponto da curva

.

O primeiro valor da assinatura,

, é derivado da coordenada x de e reduzido módulo .

Se

for igual a zero, o signatário precisa escolher outro nonce.

O segundo valor é calculado como

.

Se

for igual a zero, o signatário também precisará escolher outro nonce.

A assinatura ECDSA resultante é o par

, embora uma criptomoeda possa acrescentar informações de codificação ou recuperação.

Como uma assinatura ECDSA é verificada

O verificador começa com a mensagem, a assinatura, a chave pública, os parâmetros da curva e as regras de hash exigidas.

O verificador rejeita a assinatura quando

ou está fora do intervalo válido.

Em seguida, calcula

.

Depois, calcula

e .

O verificador calcula o ponto da curva

.

A assinatura é inválida se

for o ponto no infinito.

A assinatura é válida quando a coordenada x de

, reduzida módulo , é igual a .

Essa relação funciona porque a equação de assinatura conecta o resumo da mensagem, o nonce, a chave privada e a chave pública.

A verificação não revela a chave privada nem o nonce de assinatura.

O que uma assinatura ECDSA comprova

Uma assinatura ECDSA válida comprova que alguém com controle da chave privada correspondente assinou os dados especificados.

Ela também permite ao verificador detectar alterações na mensagem assinada.

A assinatura, por si só, não comprova a identidade jurídica do signatário.

Uma chave pública só é associada a uma pessoa ou organização por meio de evidências adicionais, registro, comunicação ou histórico de transações.

Assinaturas geradas com uma chave privada roubada são matematicamente indistinguíveis das criadas pelo titular original.

Os nós da blockchain validam a criptografia, não decidem se o signatário agiu voluntariamente.

Um usuário que assina uma transação maliciosa ainda cria uma assinatura válida.

O papel crítico do nonce ECDSA

O nonce de assinatura

é uma das partes mais sensíveis à segurança do ECDSA.

Ele nunca deve ser reutilizado em mensagens diferentes sob a mesma chave privada.

Se duas assinaturas usarem o mesmo nonce, as equações conterão informações relacionadas suficientes para calcular o nonce e recuperar a chave privada.

Nessa situação, o invasor não precisa resolver o problema do logaritmo discreto em curvas elípticas.

Nonces parcialmente previsíveis, enviesados ou vazados também podem expor uma chave após a observação de assinaturas suficientes.

Falhas de nonce já causaram comprometimentos reais de chaves criptográficas, mesmo quando a curva elíptica escolhida continuava matematicamente segura.

O termo nonce significa um valor usado uma vez, embora no ECDSA ele também precise permanecer secreto, além de ser único.

ECDSA determinístico

O ECDSA determinístico gera o nonce de assinatura a partir da chave privada e do resumo da mensagem, em vez de solicitar um novo valor aleatório para cada assinatura.

O procedimento de assinatura determinística da RFC 6979 define um método amplamente usado, baseado em uma construção de hash com chave.

Em geral, a mesma chave privada e a mesma mensagem produzem o mesmo nonce e a mesma assinatura com o mesmo procedimento determinístico.

Isso reduz a dependência da qualidade de um gerador aleatório separado em cada operação de assinatura.

A assinatura determinística não torna segura uma geração fraca de chave privada.

A chave privada original ainda exige alta entropia.

Implementações determinísticas também precisam resistir a ataques de temporização, falhas induzidas, vazamentos de memória e processamento incorreto de mensagens.

Algumas implementações acrescentam aleatoriedade extra à geração determinística de nonces para se proteger contra determinadas falhas ou ataques de canal lateral.

Por que o hashing é importante

Em geral, ECDSA assina um resumo criptográfico, em vez de processar diretamente uma mensagem de tamanho arbitrário.

O protocolo da blockchain define exatamente quais campos da transação são incluídos e como são serializados antes do hashing.

A alteração de um campo assinado deve gerar um resumo diferente e invalidar a assinatura anterior.

Criptomoedas diferentes podem usar funções hash e regras de compromisso da transação diferentes, mesmo quando usam a mesma curva ECDSA.

Por isso, a mesma mensagem legível por humanos pode gerar assinaturas diferentes em aplicações distintas.

Desenvolvedores não devem inventar regras informais de serialização, pois codificações ambíguas podem fazer dois sistemas interpretarem os mesmos bytes assinados de maneira diferente.

Protocolos seguros também usam separação de domínio para impedir que uma assinatura criada para uma finalidade autorize outra.

Codificação de assinaturas ECDSA

A assinatura ECDSA matemática contém dois números inteiros,

e .

O software precisa codificar esses números em bytes antes de transmitir ou armazenar a assinatura.

Um método comum usa as Distinguished Encoding Rules, geralmente chamadas de DER.

DER representa os valores como números inteiros codificados dentro de uma sequência estruturada.

O tamanho da assinatura resultante pode variar, pois números inteiros positivos às vezes precisam de um byte zero inicial.

Outros sistemas de criptomoedas usam codificações compactas de tamanho fixo, com 32 bytes para

e 32 bytes para .

Uma assinatura matematicamente válida ainda pode ser rejeitada se a codificação em bytes violar o formato canônico do protocolo.

Bitcoin e ECDSA

Tradicionalmente, o Bitcoin usa ECDSA sobre secp256k1 para autorizar o gasto de muitas saídas de transação.

A carteira assina um resumo específico da transação, determinado pelas regras de script aplicáveis e pelas regras de hash da assinatura.

Os nós do Bitcoin verificam a chave pública, a assinatura, as condições do script e todos os demais requisitos de consenso.

A assinatura, por si só, não comprova que a entrada contém valor suficiente nem que a transação cumpre todas as regras do protocolo.

A especificação BIP 66 do Bitcoin introduziu a codificação DER estrita como requisito de consenso para assinaturas ECDSA avaliadas pelas operações de script abrangidas.

Essa mudança reduziu as diferenças entre analisadores e impediu que o comportamento de consenso dependesse de regras variáveis de análise de terceiros.

O gasto Taproot do Bitcoin usa assinaturas Schnorr definidas pela BIP 340, e não ECDSA, em seu novo caminho de assinatura.

Os tipos de saída tradicionais baseados em ECDSA continuam existindo e podem ser gastos.

Por que a análise estrita de assinaturas é importante

O software de consenso precisa concordar não apenas com a equação da assinatura, mas também com quais sequências de bytes representam uma assinatura válida.

Se um nó aceitar uma codificação incomum e outro a rejeitar, os nós podem discordar sobre a validade de uma transação ou bloco.

Essa divergência pode dividir a visão da blockchain entre os participantes da rede.

A análise estrita remove codificações alternativas que representam os mesmos valores matemáticos.

Uma implementação de criptomoeda deve especificar com precisão sinais de números inteiros, zeros à esquerda, comprimentos, intervalos e dados finais.

A criptografia crítica para o consenso exige concordância byte a byte entre versões de software e linguagens de programação.

Ethereum e ECDSA

As contas de propriedade externa do Ethereum usam ECDSA sobre secp256k1 para autorizar transações.

O remetente assina um resumo da transação que inclui campos como nonce, destinatário, valor, dados, parâmetros de taxa e tipo de transação.

As assinaturas do Ethereum contêm os valores

e , além de informações para recuperação da chave pública.

Descrições mais antigas costumam chamar o valor de recuperação de

, enquanto transações tipadas mais recentes normalmente o representam como um valor de paridade y.

As informações de recuperação permitem que o software derive a chave pública candidata a partir da assinatura e do resumo da mensagem.

Em seguida, o endereço da conta pode ser derivado e comparado com o remetente declarado.

A alteração de protocolo EIP-2 rejeita assinaturas de transações comuns cujo valor

seja superior à metade da ordem da curva secp256k1.

Proteção contra replay no Ethereum

Uma assinatura válida pode se tornar perigosa quando a mesma transação assinada é aceita em mais de um ambiente de blockchain.

O modelo de proteção contra replay da EIP-155 do Ethereum inclui um identificador de cadeia no processo de assinatura da transação.

Isso vincula a autorização ao contexto de uma cadeia específica.

Transações tipadas modernas do Ethereum também incluem o tipo de transação e campos específicos da cadeia.

Aplicações que solicitam assinaturas off-chain ainda precisam de separação de domínio, nonces, regras de expiração e identificadores de contratos próprios.

Uma assinatura ECDSA válida nunca deve ser considerada segura sem entender a mensagem exata e o domínio que ela abrange.

Recuperação de chave pública

A verificação ECDSA padrão pressupõe que o verificador já conhece a chave pública.

O ECDSA recuperável acrescenta uma pequena quantidade de informação que ajuda a identificar a chave pública associada à assinatura e à mensagem.

Vários pontos da curva candidatos podem satisfazer parte da equação da assinatura, por isso o identificador de recuperação indica o candidato pretendido.

Esse recurso pode reduzir a necessidade de transmitir a chave pública completa em alguns formatos de transação.

A recuperação da chave pública não revela a chave privada.

O módulo opcional de recuperação do libsecp256k1 oferece suporte a assinaturas recuperáveis secp256k1 para aplicações adequadas.

As aplicações ainda precisam validar a chave recuperada, os intervalos da assinatura, o formato da mensagem e o domínio.

Maleabilidade de assinaturas ECDSA

ECDSA possui uma forma matemática inerente de maleabilidade de assinatura.

Se

for válido para uma mensagem e uma chave pública, também será válido segundo a equação básica de verificação.

Um terceiro pode criar a assinatura alternativa sem conhecer a chave privada.

Isso não permite que o invasor assine uma mensagem diferente nem gaste ativos adicionais.

Pode, porém, alterar o identificador de uma transação quando esse identificador inclui os bytes da assinatura.

Os protocolos reduzem esse problema aceitando apenas uma forma canônica, geralmente a assinatura com o valor

mais baixo.

A canonicalização também facilita a comparação e o armazenamento consistente das assinaturas.

Assinaturas low-s

Uma regra low-

exige que não seja superior à metade da ordem da curva.

Quando o signatário calcula um valor mais alto, ele pode substituí-lo por

.

O valor transformado continua matematicamente válido e se enquadra no intervalo inferior aceito.

O Ethereum aplica essa regra a assinaturas de transações comuns por meio da EIP-2.

O software do Bitcoin costuma gerar assinaturas ECDSA normalizadas low-

, enquanto o tratamento exato em nível de consenso e política depende do contexto de gasto.

Os desenvolvedores devem seguir as regras precisas do protocolo de destino, em vez de presumir que todos os sistemas ECDSA aceitam a mesma forma.

ECDSA vs. assinaturas Schnorr

ECDSA e Schnorr são algoritmos de assinatura diferentes que podem usar a mesma curva elíptica secp256k1.

As assinaturas Schnorr têm uma estrutura linear mais simples, que oferece suporte a construções eficientes de multisignature e agregação.

O ECDSA básico não oferece as mesmas propriedades simples de agregação linear.

A especificação BIP 340 do Bitcoin define assinaturas Schnorr de 64 bytes em secp256k1.

A BIP 340 também explica a maleabilidade inerente do ECDSA e as premissas de segurança mais complexas usadas na análise formal do algoritmo.

A introdução de Schnorr não significa que as assinaturas ECDSA existentes tenham se tornado inválidas ou possam ser falsificadas na prática.

Ela oferece outro projeto de assinatura com propriedades úteis para recursos de protocolo mais recentes.

ECDSA vs. EdDSA

EdDSA é uma família diferente de assinaturas, baseada na matemática de curvas de Edwards.

Ed25519 é uma implementação comum de EdDSA.

EdDSA foi projetado tendo como objetivos importantes a assinatura determinística e um comportamento de implementação simplificado.

Uma chave Ed25519 não pode ser usada como chave ECDSA secp256k1 sem um projeto de conversão separado, e uma conversão improvisada não é segura.

Os tamanhos de assinatura, formatos de chave pública, aritmética de curvas, procedimentos de hashing e regras de validação são diferentes.

Um sistema que ofereça suporte aos dois algoritmos precisa identificar claramente qual esquema se aplica a cada chave e assinatura.

ECDSA vs. assinaturas BLS

As assinaturas BLS usam curvas elípticas compatíveis com emparelhamento e têm propriedades matemáticas diferentes das do ECDSA.

Elas podem permitir a agregação compacta de várias assinaturas segundo regras de segurança definidas.

Os validadores do Ethereum usam assinaturas BLS para tarefas de consenso Proof of Stake, enquanto as contas comuns de propriedade externa do Ethereum usam ECDSA secp256k1.

Uma chave de validador, portanto, não é intercambiável com uma chave de conta de execução.

A agregação BLS pode reduzir o volume de dados quando muitos participantes assinam mensagens relacionadas, mas envolve operações de emparelhamento e requisitos de validação diferentes.

ECDSA e carteiras multisig

Um script de blockchain pode exigir várias assinaturas ECDSA independentes antes que os ativos possam ser gastos.

Esse é um modelo tradicional de multisig, pois cada signatário necessário cria uma assinatura separada.

ECDSA threshold usa um protocolo interativo mais complexo, no qual vários participantes criam em conjunto uma única assinatura ECDSA convencional.

Durante uma operação correta, nenhum participante precisa reconstruir a chave privada completa.

ECDSA threshold é difícil de projetar porque os participantes precisam coordenar a geração de nonces e resistir a comportamentos maliciosos.

Um protocolo threshold defeituoso pode expor a chave privada compartilhada mesmo quando o algoritmo ECDSA básico é seguro.

Sistemas de produção devem usar protocolos bem revisados, em vez de inventar equações personalizadas de assinatura multiparticipante.

Carteiras de hardware e ECDSA

Uma carteira de hardware pode gerar e armazenar uma chave privada ECDSA dentro de um dispositivo dedicado.

O dispositivo recebe os dados da transação, exibe os detalhes disponíveis e cria a assinatura internamente após a aprovação do usuário.

A chave privada deve permanecer no ambiente protegido.

Esse isolamento reduz a exposição direta a malware em um celular ou computador conectado.

Uma carteira de hardware não torna segura uma transação maliciosa quando o usuário aprova detalhes enganosos.

A exibição segura da transação, a integridade do firmware, a proteção da frase de recuperação e a segurança da cadeia de suprimentos continuam essenciais.

A resistência a ataques de canal lateral e falhas também é importante, pois medições físicas ou erros induzidos podem expor valores secretos de assinatura.

Ataques de canal lateral

Um ataque de canal lateral extrai informações do comportamento físico de uma implementação ECDSA.

Os sinais possíveis incluem tempo de execução, consumo de energia, emissões eletromagnéticas, acesso ao cache e padrões de memória.

Desvios condicionais ou consultas a tabelas que dependem de valores secretos podem revelar informações sobre a chave privada ou o nonce.

Implementações de tempo constante tentam fazer com que os padrões de operação observáveis não dependam de valores secretos.

O projeto atual libsecp256k1 documenta comportamento de tempo constante e acesso constante à memória para assinatura e geração de chaves públicas.

Código de tempo constante reduz riscos importantes, mas não trata todos os ataques físicos, de compilador, hardware ou sistema operacional.

Ataques por falha

Um ataque por falha provoca deliberadamente um erro durante a geração de uma assinatura ECDSA pelo dispositivo.

O invasor pode manipular tensão, temporização do clock, temperatura, memória ou fluxo de cálculo.

Em algumas implementações, uma assinatura defeituosa pode revelar informações matemáticas suficientes para recuperar uma chave privada.

Dispositivos de assinatura de alta segurança podem verificar internamente a assinatura gerada antes de liberá-la.

Também podem usar cálculos redundantes, sensores de falha, chips reforçados e mensagens de erro restritas.

A posse física de um dispositivo de assinatura deve sempre ser tratada como um evento de segurança relevante.

Chaves públicas e pontos de curva inválidos

Um verificador ECDSA não deve aceitar cegamente qualquer sequência de bytes como chave pública.

A implementação pode precisar confirmar se a codificação é válida e se o ponto pertence à curva esperada.

Deve rejeitar o ponto no infinito e realizar as verificações de subgrupo necessárias.

O uso de um ponto inválido controlado por um invasor em operações com uma chave secreta pode viabilizar ataques de curva inválida ou de subgrupo pequeno.

Os requisitos exatos de validação dependem da curva, do protocolo e da operação.

Bibliotecas criptográficas revisadas tratam esses detalhes com mais segurança do que implementações personalizadas informais.

Geração de chaves privadas

Uma chave privada ECDSA precisa ser gerada a partir de uma fonte de entropia criptograficamente segura.

Frases escolhidas por pessoas, datas de nascimento, citações, dígitos repetidos e funções aleatórias comuns não são seguros.

A chave também precisa estar dentro do intervalo válido do escalar para a curva escolhida.

Um valor que pareça ter 256 bits não é automaticamente uma chave privada gerada com segurança.

As carteiras costumam derivar muitas chaves ECDSA de uma semente mestra por meio de um processo determinístico hierárquico de derivação.

Quem obtiver essa semente mestra poderá recriar todas as contas derivadas.

A segurança do ECDSA não compensa uma frase de recuperação exposta ou previsível.

ECDSA e endereços de carteira

Uma chave pública nem sempre é igual a um endereço de criptomoeda.

Os endereços Bitcoin geralmente codificam um hash ou uma condição de script relacionada a informações da chave pública.

Os endereços Ethereum são derivados de parte do hash de uma chave pública secp256k1 não compactada.

A formatação do endereço pode acrescentar identificadores de rede e informações de detecção de erros.

Uma carteira pode exibir vários endereços derivados de uma semente mestra por diferentes caminhos de derivação.

Os usuários não devem presumir que conhecer um endereço revela a chave pública completa em todas as situações do protocolo.

Mesmo conhecer a chave pública não torna prática, com computação clássica, a recuperação de uma chave privada quando a chave e a curva são seguras.

Assinatura de transações vs. assinatura de mensagens

Uma assinatura de transação autoriza uma operação na blockchain conforme regras definidas pelo protocolo.

Uma assinatura de mensagem pode comprovar o controle de uma chave sem enviar diretamente uma transação na blockchain.

Solicitações de login em carteiras, aprovações de tokens, ordens, votos de governança e mensagens de permissão podem usar assinaturas ECDSA.

Assinaturas off-chain ainda podem autorizar ações de valor quando um contrato inteligente ou serviço as envia posteriormente.

Uma solicitação descrita como login pode ser perigosa se os dados efetivamente assinados concederem permissão para transferir ativos.

Quando possível, as carteiras devem exibir o domínio de assinatura, contrato, cadeia, nonce, expiração e ação em linguagem compreensível.

Os usuários devem rejeitar assinaturas com dados não explicados ou permissões inesperadas.

Ataques de replay

Um ataque de replay reutiliza uma assinatura válida em outro contexto no qual o signatário não pretendia que ela se aplicasse.

O invasor não falsifica a assinatura.

Ele se aproveita de uma vinculação incompleta da mensagem.

Mensagens assinadas com segurança incluem dados como identificador da cadeia, nonce da conta, endereço do contrato, domínio da aplicação, tipo de operação e horário de expiração.

Um nonce de uso único impede que a mesma autorização seja reutilizada na mesma aplicação.

Os desenvolvedores devem verificar se o nonce só é consumido após uma ação autorizada bem-sucedida.

Erros de implementação

Em geral, as falhas de ECDSA decorrem de erros de implementação ou de gestão de chaves, não da solução direta do problema do logaritmo discreto em curvas elípticas.

Entre as falhas comuns estão reutilização de nonces, números aleatórios enviesados, aceitação de chaves inválidas, hashing incorreto, serialização ambígua, ausência de verificações de intervalo e análise insegura de assinaturas.

Outras falhas envolvem canais laterais, ataques por falha, registros de depuração expostos, dependências comprometidas e vazamento de memória.

Os desenvolvedores devem usar bibliotecas mantidas, com testes extensos e um modelo de segurança claro.

O código criptográfico deve ser revisado separadamente do código comum da aplicação, pois pequenos erros podem expor todos os ativos protegidos por uma chave.

Por que escrever código ECDSA próprio é perigoso

As fórmulas do ECDSA podem parecer simples o bastante para serem implementadas em um programa curto.

A segurança de produção exige muito mais do que reproduzir as equações de assinatura e verificação.

A implementação precisa realizar operações de escalar em tempo constante, inversão segura, redução modular correta, análise estrita, validação de pontos e gerenciamento seguro de memória.

Também precisa tratar corretamente casos raros, como valores zero e pontos inválidos.

Um programa que passe em alguns testes normais de assinatura ainda pode vazar a chave privada por meio de temporização ou viés de nonce.

Os desenvolvedores devem usar bibliotecas consolidadas e vetores de teste oficiais, em vez de adaptar código de tutoriais para a custódia de criptomoedas.

Nível de segurança do ECDSA

A segurança do ECDSA depende da força da curva e da função hash, da entropia da chave privada, da geração de nonces e da implementação.

Uma curva elíptica segura de 256 bits costuma ser associada a aproximadamente 128 bits de segurança clássica.

Isso não significa que um invasor tenha uma chance em 128 de adivinhar a chave.

O valor descreve um fator de trabalho computacional aproximado segundo modelos de ataque relevantes.

A função hash também precisa oferecer resistência adequada a colisões e pré-imagens para os objetivos de segurança do protocolo.

Controles operacionais fracos podem reduzir a segurança prática muito abaixo do nível matemático.

ECDSA e computação quântica

ECDSA não é considerado seguro contra um computador quântico tolerante a falhas suficientemente poderoso.

O algoritmo de Shor poderia resolver o problema do logaritmo discreto em curvas elípticas e recuperar uma chave privada a partir da chave pública.

Nenhum computador quântico conhecido publicamente consegue atualmente quebrar o ECDSA secp256k1 de tamanho completo em escala prática para criptomoedas.

Sistemas de blockchain com vida útil longa ainda precisam de planos de migração, pois atualizações de protocolo, mudanças em carteiras e movimentação de fundos inativos podem levar anos.

Chaves públicas já expostas on-chain podem se tornar alvos prioritários caso seja desenvolvido hardware quântico criptograficamente relevante.

Afirmações sem fundamento de que o ECDSA atual já foi quebrado devem ser avaliadas com cautela.

Alternativas de assinatura pós-quântica

Assinaturas digitais pós-quânticas se baseiam em problemas matemáticos considerados resistentes tanto a computadores clássicos quanto a computadores quânticos de grande porte.

Em agosto de 2024, o NIST finalizou a FIPS 204 para ML-DSA e a FIPS 205 para SLH-DSA.

Esses sistemas de assinatura diferem do ECDSA em tamanho das chaves e assinaturas, custos computacionais e requisitos de implementação.

Substituir ECDSA em uma blockchain não é tão simples quanto trocar uma biblioteca de carteira.

A migração pode afetar formatos de endereço, tamanho das transações, carteiras de hardware, contratos inteligentes, validação da rede, recuperação de contas e fundos inativos.

Durante a transição, alguns protocolos podem usar autorização híbrida, exigindo tanto uma assinatura ECDSA existente quanto uma assinatura pós-quântica.

Como os desenvolvedores devem usar ECDSA com segurança

Os desenvolvedores devem usar exatamente a curva, a função hash, o formato da mensagem e a codificação de assinatura exigidos pelo protocolo de destino.

As chaves privadas devem vir de um processo de geração ou derivação criptograficamente seguro.

Os nonces de assinatura devem usar um método determinístico revisado ou um projeto de geração aleatória com proteções equivalentes.

As bibliotecas devem realizar análise estrita de assinaturas, verificações de intervalo dos escalares, validação de chaves públicas e canonicalização exigidas pelo protocolo.

Operações com chaves secretas devem usar implementações de tempo constante.

As aplicações precisam incluir separação de domínio, proteção contra replay, exibição clara de transações e gerenciamento apropriado de nonces.

As suítes de testes devem incluir assinaturas inválidas, formas com

alto, codificações malformadas, valores zero, mensagens alteradas, redes incorretas e tentativas de reutilizar autorizações.

Sistemas de alto valor devem passar por auditorias criptográficas e de implementação independentes.

Como usuários de cripto podem proteger chaves ECDSA

Os usuários devem criar carteiras com softwares confiáveis ou dispositivos dedicados para assinatura.

Frases de recuperação e chaves privadas devem permanecer off-line e nunca ser compartilhadas com atendentes de suporte ou sites.

Os detalhes da transação devem ser verificados em uma tela confiável antes da assinatura.

Os usuários devem confirmar o endereço de destino, a rede, o valor, a taxa, o contrato e o escopo das permissões.

Ativos de alto valor podem ser protegidos com políticas multisig, backups distribuídos, isolamento por hardware e carteiras separadas para gastos.

Uma mesma frase de recuperação não deve ser importada em aplicações desnecessárias.

Em muitos sistemas de blockchain, uma assinatura válida é uma evidência irreversível de autorização, portanto a prevenção é mais confiável do que a recuperação.

Erros comuns sobre ECDSA

Um erro comum é presumir que ECDSA criptografa transações de criptomoedas.

Outro é tratar a chave pública como se fosse sempre idêntica ao endereço da carteira.

Um terceiro erro é reutilizar o mesmo nonce de assinatura em duas mensagens.

Um quarto é gerar chaves privadas ou nonces com uma função aleatória comum.

Um quinto é aceitar assinaturas não canônicas ou malformadas sem análise estrita.

Um sexto é esquecer que tanto

quanto podem satisfazer a equação básica do ECDSA.

Um sétimo é assinar dados sem verificar a rede, o domínio, o nonce e a expiração.

Um oitavo é usar a mesma chave privada em aplicações e blockchains sem relação entre si.

Um nono é escrever código próprio de curva elíptica para carteiras de produção sem revisão especializada.

Um décimo é presumir que uma assinatura válida comprova que uma transação é segura, justa ou desejada pelo titular original da chave.

Perguntas frequentes

O que significa ECDSA?

ECDSA é a sigla em inglês para Elliptic Curve Digital Signature Algorithm, ou Algoritmo de Assinatura Digital de Curva Elíptica.

Para que ECDSA é usado em criptomoedas?

Ele é usado para gerar e verificar assinaturas que autorizam transações na blockchain e outras ações de carteira.

ECDSA criptografa transações?

Não. ECDSA comprova autorização e integridade, mas não oculta os dados comuns de uma blockchain pública.

O que é uma chave privada ECDSA?

É um número inteiro secreto usado para criar assinaturas e derivar a chave pública correspondente.

O que é uma chave pública ECDSA?

É um ponto de curva elíptica derivado da chave privada e usado para verificar assinaturas.

Qual curva o Bitcoin usa para ECDSA?

O Bitcoin usa a curva elíptica secp256k1 para suas assinaturas tradicionais de transações ECDSA.

Qual curva o Ethereum usa para assinaturas de contas?

As contas de propriedade externa do Ethereum usam ECDSA sobre secp256k1.

O que são r e s no ECDSA?

São os dois componentes inteiros de uma assinatura ECDSA.

O que é o nonce ECDSA?

É um escalar secreto, usado uma vez por assinatura, durante a geração da assinatura.

Por que o nonce ECDSA nunca deve ser reutilizado?

A reutilização de um nonce em mensagens diferentes pode permitir que um observador calcule a chave privada.

O que é ECDSA determinístico?

É um método de assinatura que deriva o nonce a partir da chave privada e do resumo da mensagem por um processo definido, como o da RFC 6979.

ECDSA determinístico elimina a necessidade de aleatoriedade?

Não. A chave privada original ainda precisa de alta entropia, e as implementações precisam continuar protegidas contra falhas e ataques de canal lateral.

O que é maleabilidade de assinatura ECDSA?

É a propriedade pela qual tanto

quanto podem ser válidos para a mesma mensagem e chave pública.

O que é uma assinatura low-s?

É uma assinatura ECDSA canônica cujo valor

não é superior à metade da ordem da curva.

O que é codificação DER?

DER é uma codificação binária estruturada usada com frequência para representar os números inteiros

e de uma assinatura ECDSA.

Uma assinatura ECDSA pode revelar a chave privada?

Uma assinatura gerada corretamente não deve revelá-la, mas reutilização de nonces, nonces enviesados, canais laterais e erros de implementação podem expor a chave.

ECDSA pode recuperar uma chave privada perdida?

Não. Assinaturas e chaves públicas não oferecem um método prático de recuperação de uma chave privada perdida e gerada com segurança.

Alguém pode falsificar uma assinatura ECDSA?

A falsificação é considerada computacionalmente impraticável quando são usados parâmetros, chaves, nonces, hashes e implementações seguros.

ECDSA é igual a ECC?

Não. ECC é a família mais ampla da criptografia de curvas elípticas, enquanto ECDSA é um algoritmo de assinatura digital dessa família.

ECDSA é igual a Schnorr?

Não. São algoritmos de assinatura diferentes, mesmo quando ambos operam sobre secp256k1.

Taproot usa ECDSA?

O novo caminho de assinatura do Taproot usa assinaturas Schnorr BIP 340, em vez de ECDSA.

Contratos inteligentes podem verificar assinaturas ECDSA?

Sim. Muitos ambientes de blockchain oferecem operações nativas ou bibliotecas para verificar assinaturas ECDSA secp256k1.

Uma assinatura ECDSA válida comprova identidade jurídica?

Não. Ela comprova o controle de uma chave privada, a menos que evidências separadas associem essa chave a uma identidade jurídica.

Uma assinatura válida garante que uma transação é segura?

Não. Um usuário pode assinar validamente uma transferência maliciosa, uma autorização ilimitada, uma ordem enganosa ou uma ação insegura de contrato inteligente.

Um computador quântico pode quebrar ECDSA?

Um computador quântico tolerante a falhas suficientemente poderoso poderia quebrar ECDSA, mas nenhum sistema conhecido publicamente consegue fazê-lo atualmente em escala de criptomoedas.

ECDSA continua seguro hoje?

ECDSA implementado corretamente, com chaves e nonces seguros, continua resistente a ataques clássicos práticos conhecidos.

Conclusão

ECDSA é um algoritmo fundamental de assinatura digital usado para autorizar transações de criptomoedas sem expor chaves privadas.

Ele combina um escalar privado, uma chave pública de curva elíptica, um resumo de mensagem e um nonce secreto de assinatura para criar os valores

e .

Os nós da blockchain verificam matematicamente esses valores antes de aceitar uma ação assinada.

Tradicionalmente, o Bitcoin usa ECDSA sobre secp256k1, enquanto as contas de propriedade externa do Ethereum usam a mesma curva com informações para recuperação de assinatura.

Codificação estrita, regras low-

, identificadores de cadeia, domínios de mensagem e proteção contra replay ajudam a tornar o ECDSA mais seguro nos protocolos de criptomoedas.

A maior fraqueza prática do algoritmo não é o problema central de curva elíptica, mas erros de implementação e gerenciamento de chaves.

Nonces reutilizados, aleatoriedade fraca, frases de recuperação expostas, canais laterais, tratamento de pontos inválidos e solicitações de assinatura pouco claras podem comprometer uma matemática robusta.

Os desenvolvedores devem usar bibliotecas revisadas, procedimentos determinísticos para nonces, operações de tempo constante, validação estrita e especificações exatas do protocolo.

Os usuários devem proteger os dados de recuperação e verificar cada transação ou mensagem em uma tela de assinatura confiável.

Quando implementado corretamente, ECDSA permanece seguro contra ataques clássicos práticos conhecidos, embora os sistemas de criptomoedas de longo prazo precisem se preparar para a migração a tecnologias de assinatura pós-quântica.