Tror du at det er enkelt å implementere nonces? Tenk om igjen. Enten du bygger onchain-protokoller eller offchain-infrastruktur, er riktig nonce-implementering en av de vanskeligste delene av kryptografisk sikkerhet. La oss dykke ned i hvorfor replay-beskyttelse er vanskeligere enn det ser ut til 👇

2/ La oss først forstå digitale signaturer. I offentlig nøkkelkrypto (som BLS) har du en privat nøkkel som signerer meldinger og en offentlig nøkkel som verifiserer dem. I Ethereum: adresse = hash for offentlig nøkkel Melding = Hash for transaksjon signatur = 64 byte med kryptografisk bevis

3/ Her er problemet: regnestykket i de fleste offentlige nøkkelkryptoprotokoller begrenser ikke hvor mange ganger en signatur kan verifiseres mot samme melding. Når du har en gyldig signatur, kan du spille den av i det uendelige. Dette åpner døren for å spille av angrep på nytt.

4/ Skriv inn nonce: et "nummer brukt én gang" som forhindrer replay-angrep. Når en forbruker mottar en melding med en nonce, sjekker den om den nonce-verdien ble brukt før. Hvis ja, avviser →. Ethereum-transaksjoner bruker dette mønsteret.

5/ Men nonce-implementering er villedende kompleks. Viktige krav: - Nonces må ALDRI være gjenbrukbare (på denne kjeden eller andre) - Må forhindre repriseangrep permanent - Trenger mekanismer for å håndtere lagringsvekst - Må være motstandsdyktig mot angrep i frontløp

6/ Den naive løsningen: lagre alle nonces i en database for alltid. Dette har to store problemer: a) Ubegrenset lagringsvekst (spesielt med spamangrep) b) Sårbarhet for frontløpsangrep Oppgave (a) er lettere å løse enn (b). La oss ta tak i lagring først...

7/ Tidsstempelbaserte nonces løser lagringsvekst! Bruk tidsstempel + utløpsperiode. Nonces eldre enn 5 minutter blir slettet fra databasen. Men hva med samtidige meldinger fra samme konto? De deler et tidsstempel. Løsning: tidsstempel + random_bytes for granulær unikhet.

8/ Frontløp er den vanskelige delen. Ondsinnede aktører kan fange opp gyldige signaturer, kjøre dem foran for å merke nonces som brukt, og deretter blir den legitime brukerens kall avvist. Dette er problematisk onchain med batchoperasjoner hvis én ugyldig signatur avviser en hel batch. For offchain: bruk TLS-kryptering! Ikke la noen ondsinnede aktører noen gang se nonce eller signaturen.

9/ Ikke glem utholdenhet! Hvis nonce-cachen din bare er i minnet, kan angripere spille av gamle nonce-er på nytt etter at systemet har startet på nytt. Behold alltid nonce-tilstanden til varig lagring og last inn på nytt ved oppstart. Hurtigbuffere med bare minne = sikkerhetsproblem for avspilling på nytt.

10/ Unike nonces per forbruker! Når du kringkaster til flere brukere, bør hver få en annen melding/signatur. Ellers er du sårbar for Man-in-the-Middle-angrep der en mottaker videresender meldingen og utgir seg for å være den opprinnelige avsenderen.

11/ Inkrementelle nonces (som Ethereum, nonce = forrige nonce + 1) har sin plass, men pass på! De skaper enorme utfordringer for offchain-infrastruktur: meldinger som ikke er i drift, synkroniseringsproblemer og komplekse gjenopprettingsscenarier. Bruk bare hvis du er sikker på at meldinger vil (eller må) komme i rekkefølge.

Sammendrag - Sjekkliste for implementering av Nonce: ✅ Bruk nonces for å forhindre repriseangrep ✅ Behold nonce-tilstand på tvers av omstarter ✅ Implementere utløpsmekanismer (tidsstempel + opprydding) ✅ Gjør nonces unike per mottaker ✅ Beskytt mot front-running med krypterte kanaler ✅ Unngå inkrementelle nonces med mindre ordren er garantert Sikkerhet ligger i detaljene! 🛡️