Myslíte si, že implementace nonce je jednoduchá? Zamyslete se znovu. Ať už vytváříte onchain protokoly nebo offchain infrastrukturu, správná implementace nonce je jednou z nejsložitějších částí kryptografického zabezpečení. Pojďme se podívat na to, proč je ochrana proti přehrání těžší, než se zdá 👇

2/ Nejprve si pochopme digitální podpisy. V kryptografii s veřejným klíčem (jako je BLS) máte soukromý klíč, který podepisuje zprávy, a veřejný klíč, který je ověřuje. V Ethereu: address = hodnota hash veřejného klíče zpráva = hodnota hash transakce podpis = 64 bajtů kryptografického důkazu

3/ Zde je problém: matematika ve většině kryptografických protokolů s veřejným klíčem neomezuje, kolikrát lze podpis ověřit proti stejné zprávě. Jakmile budete mít platný podpis, můžete jej přehrávat donekonečna. To otevírá dveře k opakovaným útokům.

4/ Zadejte nonce: "číslo použité jednou", které zabraňuje útokům opakovaného přehrávání. Když příjemce obdrží zprávu s hodnotou nonce, zkontroluje, zda byla tato hodnota nonce použita dříve. Pokud ano, → zamítnout. Transakce Ethereum používají tento vzor.

5/ Implementace nonce je však klamavě složitá. Klíčové požadavky: - Nonce nesmí být NIKDY opakovaně použitelné (na tomto řetězci nebo jiných) - Musí trvale zabránit útokům přehrání - Potřebujete mechanismy pro zvládnutí růstu úložiště - Musí být odolný vůči útokům typu front-running

6/ Naivní řešení: uložit všechny nonce do databáze navždy. To má dva hlavní problémy: a) Neomezený růst úložiště (zejména pomocí spamových útoků) b) Zranitelnost vůči front-running útokům Problém (a) je snazší vyřešit než (b). Nejprve se vypořádejme s úložištěm...

7/ Nonce založené na časových razítkách řeší růst úložiště! Použijte časové razítko + dobu platnosti. Hodnoty Nonce starší než 5 minut se z databáze odstraní. Ale co souběžné zprávy ze stejného účtu? Sdílejí časové razítko. Řešení: časové razítko + random_bytes pro granulární jedinečnost.

8/ Běh vpředu je ošemetná část. Aktéři se zlými úmysly mohou zachytit platné podpisy, spustit je dopředu, aby označily hodnoty nonce jako použité, a poté se volání legitimního uživatele odmítne. To je problematické u dávkových operací, pokud jeden špatný podpis odmítne celou dávku. Pro offchain: použijte šifrování TLS! Nedovolte, aby žádný aktér se zlými úmysly nikdy neviděl nonce nebo podpis.

9/ Nezapomínejte na vytrvalost! Pokud je mezipaměť nonce pouze v paměti, mohou útočníci po restartování systému znovu přehrát staré mezipaměti nonce. Vždy zachovat stav nonce do trvalého úložiště a znovu načíst při spuštění. Mezipaměti pouze z paměti = okno chyby zabezpečení pro opakované přehrávání.

10/ Unikátní nonce na spotřebitele! Při vysílání pro více uživatelů by měl každý dostat jinou zprávu/podpis. V opačném případě jste zranitelní vůči útokům Man-in-the-Middle, kdy jeden příjemce přepošle zprávu a vydává se za původního odesílatele.

11/ Inkrementální nonce (jako Ethereum, nonce = prev nonce + 1) mají své místo, ale pozor! Vytvářejí obrovské výzvy pro offchain infrastrukturu: zprávy mimo provoz, problémy se synchronizací a složité scénáře obnovy. Používejte pouze v případě, že jste si jisti, že zprávy budou (nebo musí) přicházet v pořadí.

Shrnutí – kontrolní seznam implementace nonce: ✅ Použití hodnoty nonce k zabránění útokům přehrání ✅ Zachování stavu nonce napříč restarty ✅ Implementace mechanismů vypršení platnosti (časové razítko + vyčištění) ✅ Nastavení hodnoty nonce jako jedinečné pro každého příjemce ✅ Ochrana před front-running pomocí šifrovaných kanálů ✅ Vyhněte se přírůstkovým nonce, pokud není zaručeno pořadí Bezpečnost je v detailech! 🛡️