Crezi că implementarea nonces este simplă? Gândiți-vă din nou. Indiferent dacă construiți protocoale onchain sau infrastructură offchain, implementarea corectă nonce este una dintre cele mai dificile părți ale securității criptografice. Să ne scufundăm în motivul pentru care protecția la reluare este mai grea decât pare 👇

2/ În primul rând, să înțelegem semnăturile digitale. În criptomonedele cu cheie publică (cum ar fi BLS), aveți o cheie privată care semnează mesajele și o cheie publică care le verifică. În Ethereum: adresă = hash cheie publică mesaj = hash tranzacție semnătură = 64 octeți de dovadă criptografică

3/ Iată problema: matematica în majoritatea protocoalelor cripto cu cheie publică nu limitează de câte ori poate fi verificată o semnătură în raport cu același mesaj. Odată ce aveți o semnătură validă, o puteți reda la infinit. Acest lucru deschide ușa pentru reluarea atacurilor.

4/ Introduceți nonce: un "număr folosit o dată" care previne atacurile de reluare. Când un consumator primește un mesaj cu un nonce, verifică dacă acel nonce a fost folosit înainte. Dacă da, → respingeți. Tranzacțiile Ethereum folosesc acest model.

5/ Dar implementarea nonce este înșelător de complexă. Cerințe cheie: - Nonce-urile nu trebuie să fie NICIODATĂ reutilizabile (pe acest lanț sau pe altele) - Trebuie să prevină permanent atacurile de reluare - Aveți nevoie de mecanisme pentru a gestiona creșterea stocării - Trebuie să fie rezistent la atacurile frontale

6/ Soluția naivă: stocați toate nonce-urile într-o bază de date pentru totdeauna. Acest lucru are două probleme majore: a) Creșterea nelimitată a stocării (în special cu atacuri de spam) b) Vulnerabilitate la atacuri frontale Problema (a) este mai ușor de rezolvat decât (b). Să abordăm mai întâi depozitarea...

7/ Nonce-urile bazate pe marcaj temporal rezolvă creșterea stocării! Utilizați marcajul temporal + perioada de expirare. Nonce-urile mai vechi de 5 minute sunt șterse din baza de date. Dar cum rămâne cu mesajele simultane din același cont? Au un marcaj de timp. Soluție: marcaj temporal + random_bytes pentru unicitate granulară.

8/ Alergarea în față este partea dificilă. Actorii rău intenționați pot intercepta semnături valide, le pot executa pentru a marca nonce-urile ca utilizate, apoi apelul utilizatorului legitim este respins. Acest lucru este problematic în lanț cu operațiunile în lot dacă o semnătură greșită respinge un întreg lot. Pentru offchain: utilizați criptarea TLS! Nu lăsați niciun actor rău intenționat să vadă vreodată nonce sau semnătura.

9/ Nu uita de perseverență! Dacă memoria cache nonce este doar în memorie, atacatorii pot reda nonces vechi după repornirea sistemului. Păstrați întotdeauna starea nonce la stocare durabilă și reîncărcați la pornire. Cache-uri numai pentru memorie = fereastra de vulnerabilitate de reluare.

10/ Nonces unice per consumator! Când difuzați către mai mulți utilizatori, fiecare ar trebui să primească un mesaj/semnătură diferită. În caz contrar, sunteți vulnerabil la atacuri Man-in-the-Middle în care un destinatar redirecționează mesajul, uzurpându-l pe expeditorul inițial.

11/ Nonce-urile incrementale (cum ar fi Ethereum, nonce = prev nonce + 1) își au locul, dar atenție! Acestea creează provocări masive pentru infrastructura offchain: mesaje depășite, probleme de sincronizare și scenarii complexe de recuperare. Utilizați numai dacă sunteți sigur că mesajele vor ajunge (sau trebuie) să ajungă în secvență.

Rezumat - Lista de verificare a implementării Nonce: ✅ Folosiți nonces pentru a preveni atacurile de reluare ✅ Persistați starea nonce între reporniri ✅ Implementați mecanisme de expirare (marcaj temporal + curățare) ✅ Faceți nonces unice per receptor ✅ Protejați-vă împotriva front-running cu canale criptate ✅ Evitați nonce-urile incrementale, cu excepția cazului în care comanda este garantată Securitatea este în detalii! 🛡️