Denk je dat het implementeren van nonces eenvoudig is? Denk nog eens na. Of je nu on-chain protocollen of off-chain infrastructuur bouwt, een goede implementatie van nonces is een van de moeilijkste onderdelen van cryptografische beveiliging. Laten we duiken in waarom replaybescherming moeilijker is dan het lijkt 👇

2/ Laten we eerst digitale handtekeningen begrijpen. In publieke sleutelcryptografie (zoals BLS) heb je een privésleutel die berichten ondertekent en een publieke sleutel die ze verifieert. In Ethereum: adres = hash van de publieke sleutel bericht = transactiehash handtekening = 64 bytes van cryptografisch bewijs

3/ Hier is het probleem: de wiskunde in de meeste public key crypto protocollen beperkt niet hoe vaak een handtekening kan worden geverifieerd tegen hetzelfde bericht. Zodra je een geldige handtekening hebt, kun je deze oneindig vaak herhalen. Dit opent de deur naar replay-aanvallen.

4/ Voer de nonce in: een "eenmalig getal" dat replay-aanvallen voorkomt. Wanneer een consument een bericht met een nonce ontvangt, controleert hij of die nonce eerder is gebruikt. Zo ja → afwijzen. Ethereum-transacties gebruiken dit patroon.

5/ Maar de implementatie van nonces is bedrieglijk complex. Belangrijke vereisten: - Nonces mogen NOOIT herbruikbaar zijn (op deze keten of andere) - Moet permanent replay-aanvallen voorkomen - Mechanismen nodig om opslaggroei te beheren - Moet bestand zijn tegen front-running aanvallen

6/ De naïeve oplossing: sla alle nonces voor altijd op in een database. Dit heeft twee grote problemen: a) Onbeperkte opslaggroei (vooral bij spamaanvallen) b) Kwetsbaarheid voor front-running aanvallen Probleem (a) is gemakkelijker op te lossen dan (b). Laten we eerst de opslag aanpakken...

7/ Tijdstempel-gebaseerde nonces lossen opslaggroei op! Gebruik tijdstempel + vervalperiode. Nonces ouder dan 5 minuten worden uit de database verwijderd. Maar wat als er gelijktijdige berichten van hetzelfde account zijn? Ze delen een tijdstempel. Oplossing: tijdstempel + random_bytes voor granulaire uniciteit.

8/ Front-running is het lastige deel. Kwaadaardige actoren kunnen geldige handtekeningen onderscheppen, ze front-runnen om nonces als gebruikt te markeren, waarna de oproep van de legitieme gebruiker wordt afgewezen. Dit is problematisch on-chain met gebundelde operaties als één slechte handtekening een hele batch afwijst. Voor off-chain: gebruik TLS-encryptie! Laat nooit een kwaadaardige actor de nonce of handtekening zien.

9/ Vergeet niet volhardend te zijn! Als je nonce-cache alleen in het geheugen staat, kunnen aanvallers oude nonces opnieuw afspelen na systeemherstarts. Zorg ervoor dat je de nonce-status opslaat in duurzame opslag en deze opnieuw laadt bij het opstarten. Alleen geheugen-caches = venster voor herhalingskwetsbaarheid.

10/ Unieke nonces per consument! Bij het uitzenden naar meerdere gebruikers, moet elke gebruiker een ander bericht/handtekening ontvangen. Anders ben je kwetsbaar voor Man-in-the-Middle-aanvallen waarbij één ontvanger het bericht doorstuurt en de oorspronkelijke afzender imiteert.

11/ Incrementele nonces (zoals Ethereum, nonce = vorige nonce + 1) hebben hun plaats, maar wees voorzichtig! Ze creëren enorme uitdagingen voor offchain-infrastructuur: berichten in de verkeerde volgorde, synchronisatieproblemen en complexe herstelscenario's. Gebruik ze alleen als je zeker weet dat berichten (of moeten) in volgorde aankomen.

Samenvatting - Nonce implementatie checklist: ✅ Gebruik nonces om replay-aanvallen te voorkomen ✅ Bewaar de nonce-status bij herstarts ✅ Implementeer vervaldmechanismen (timestamp + opruiming) ✅ Maak nonces uniek per ontvanger ✅ Bescherm tegen front-running met versleutelde kanalen ✅ Vermijd incrementele nonces tenzij de volgorde gegarandeerd is Beveiliging zit in de details! 🛡️