Tror du att det är enkelt att implementera nonces? Tänk om. Oavsett om du bygger onchain-protokoll eller offchain-infrastruktur är korrekt nonce-implementering en av de svåraste delarna av kryptografisk säkerhet. Låt oss dyka in i varför omspelningsskydd är svårare än det ser ut 👇

2/ Låt oss först förstå digitala signaturer. I krypto med offentlig nyckel (som BLS) har du en privat nyckel som signerar meddelanden och en offentlig nyckel som verifierar dem. I Ethereum: adress = hash för offentlig nyckel meddelande = transaktionshash signatur = 64 byte kryptografiska bevis

3/ Här är problemet: matematiken i de flesta kryptoprotokoll med offentlig nyckel begränsar inte hur många gånger en signatur kan verifieras mot samma meddelande. När du har en giltig signatur kan du spela upp den oändligt. Detta öppnar dörren för att spela upp attacker igen.

4/ Ange nonce: ett "nummer som används en gång" som förhindrar replay-attacker. När en konsument tar emot ett meddelande med en nonce kontrollerar den om den nonce har använts tidigare. Om ja, → avvisa. Ethereum-transaktioner använder detta mönster.

5/ Men nonce-implementeringen är bedrägligt komplex. Viktiga krav: - Nonces får ALDRIG kunna återanvändas (i denna kedja eller andra) - Måste förhindra reprisattacker permanent - Behöver mekanismer för att hantera lagringstillväxt - Måste vara motståndskraftig mot attacker i framkant

6/ Den naiva lösningen: lagra alla nonces i en databas för alltid. Detta har två stora problem: a) Obegränsad lagringstillväxt (särskilt med skräppostattacker) b) Sårbarhet för front-running-attacker Problem (a) är lättare att lösa än (b). Låt oss ta itu med lagring först...

7/ Tidsstämpelbaserade nonces löser lagringstillväxt! Använd tidsstämpel + förfalloperiod. Nonces som är äldre än 5 minuter tas bort från databasen. Men hur är det med samtidiga meddelanden från samma konto? De delar en tidsstämpel. Lösning: tidsstämpel + random_bytes för detaljerad unikhet.

8/ Att springa i framkant är den knepiga delen. Illvilliga aktörer kan fånga upp giltiga signaturer, köra dem i förväg för att markera nonces som använda, sedan avvisas den legitima användarens anrop. Detta är problematiskt i kedjan med batchåtgärder om en felaktig signatur avvisar en hel batch. För offchain: använd TLS-kryptering! Låt inte någon illvillig aktör någonsin se nonce eller signaturen.

9/ Glöm inte uthållighet! Om din nonce-cache bara finns i minnet kan angripare spela upp gamla nonces efter omstart av systemet. Spara alltid nonce-tillståndet till beständig lagring och läs in igen vid start. Cacheminnen med endast minne = fönster för återuppspelningssårbarhet.

10/ Unika priser per konsument! När du sänder till flera användare bör var och en få ett annat meddelande/signatur. Annars är du sårbar för Man-in-the-Middle-attacker där en mottagare vidarebefordrar meddelandet och utger sig för att vara den ursprungliga avsändaren.

11/ Inkrementella nonces (som Ethereum, nonce = föregående nonce + 1) har sin plats, men se upp! De skapar enorma utmaningar för offchain-infrastrukturen: meddelanden i oordning, synkroniseringsproblem och komplexa återställningsscenarier. Använd bara om du är säker på att meddelanden kommer (eller måste) komma fram i följd.

Sammanfattning – Checklista för Nonce-implementering: ✅ Använd nonces för att förhindra reprisattacker ✅ Bevara nonce-tillstånd mellan omstarter ✅ Implementera förfallomekanismer (tidsstämpel + rensning) ✅ Gör nonces unika per mottagare ✅ Skydda mot front-running med krypterade kanaler ✅ Undvik inkrementella nonces om inte ordning är garanterad Säkerheten sitter i detaljerna! 🛡️