Acha que implementar nonces é simples? Pense de novo. Esteja você criando protocolos onchain ou infraestrutura offchain, a implementação adequada do nonce é uma das partes mais complicadas da segurança criptográfica. Vamos nos aprofundar no motivo pelo qual a proteção contra replay é mais difícil do que parece 👇

2/ Primeiro, vamos entender as assinaturas digitais. Na criptografia de chave pública (como BLS), você tem uma chave privada que assina mensagens e uma chave pública que as verifica. No Ethereum: endereço = hash de chave pública mensagem = hash da transação assinatura = 64 bytes de prova criptográfica

3/ Aqui está o problema: a matemática na maioria dos protocolos de criptografia de chave pública não limita quantas vezes uma assinatura pode ser verificada em relação à mesma mensagem. Depois de ter uma assinatura válida, você pode reproduzi-la infinitamente. Isso abre a porta para ataques de repetição.

4/ Digite o nonce: um "número usado uma vez" que impede ataques de repetição. Quando um consumidor recebe uma mensagem com um nonce, ele verifica se esse nonce foi usado antes. Se sim, → rejeitar. As transações Ethereum usam esse padrão.

5/ Mas a implementação do nonce é enganosamente complexa. Requisitos principais: - Nonces NUNCA devem ser reutilizáveis (nesta cadeia ou em outras) - Deve evitar ataques de repetição permanentemente - Precisam de mecanismos para lidar com o crescimento do armazenamento - Deve ser resistente a ataques de front-running

6/ A solução ingênua: armazene todos os nonces em um banco de dados para sempre. Isso tem dois problemas principais: a) Crescimento ilimitado do armazenamento (especialmente com ataques de spam) b) Vulnerabilidade a ataques front-running O problema (a) é mais fácil de resolver do que (b). Vamos abordar o armazenamento primeiro...

7/ Nonces baseados em carimbo de data/hora resolvem o crescimento do armazenamento! Use carimbo de data/hora + período de expiração. Nonces com mais de 5 minutos são excluídos do banco de dados. Mas e as mensagens simultâneas da mesma conta? Eles compartilham um carimbo de data/hora. Solução: carimbo de data/hora + random_bytes para exclusividade granular.

8/ Front-running é a parte complicada. Agentes mal-intencionados podem interceptar assinaturas válidas, executá-las antecipadamente para marcar nonces como usados e, em seguida, a chamada do usuário legítimo é rejeitada. Isso é problemático onchain com operações em lote se uma assinatura incorreta rejeitar um lote inteiro. Para offchain: use criptografia TLS! Não permita que nenhum agente mal-intencionado veja o nonce ou a assinatura.

9/ Não se esqueça da persistência! Se o cache nonce estiver apenas na memória, os invasores poderão reproduzir nonces antigos após a reinicialização do sistema. Sempre persista o estado nonce no armazenamento durável e recarregue na inicialização. Caches somente de memória = janela de vulnerabilidade de repetição.

10/ Nonces únicos por consumidor! Ao transmitir para vários usuários, cada um deve receber uma mensagem/assinatura diferente. Caso contrário, você estará vulnerável a ataques Man-in-the-Middle em que um receptor encaminha a mensagem, fazendo-se passar pelo remetente original.

11/ Nonces incrementais (como Ethereum, nonce = prev nonce + 1) têm seu lugar, mas cuidado! Eles criam enormes desafios para a infraestrutura offchain: mensagens fora de ordem, problemas de sincronização e cenários complexos de recuperação. Use apenas se tiver certeza de que as mensagens chegarão (ou devem) chegar em sequência.

Resumo - Lista de verificação de implementação do Nonce: ✅ Use nonces para evitar ataques de repetição ✅ Manter o estado nonce entre reinicializações ✅ Implementar mecanismos de expiração (carimbo de data/hora + limpeza) ✅ Torne os nonces exclusivos por receptor ✅ Proteja-se contra front-running com canais criptografados ✅ Evite nonces incrementais, a menos que o pedido seja garantido A segurança está nos detalhes! 🛡️