Menurut Anda menerapkan nonces itu sederhana? Pikirkan lagi. Baik Anda membangun protokol onchain atau infrastruktur offchain, implementasi nonce yang tepat adalah salah satu bagian tersulit dari keamanan kriptografi. Mari selami mengapa perlindungan replay lebih sulit daripada yang terlihat 👇

2/ Pertama, mari kita pahami tanda tangan digital. Dalam kripto kunci publik (seperti BLS), Anda memiliki kunci pribadi yang menandatangani pesan dan kunci publik yang memverifikasinya. Di Ethereum: address = hash kunci publik pesan = hash transaksi tanda tangan = 64 byte bukti kriptografi

3/ Inilah masalahnya: matematika di sebagian besar protokol kripto kunci publik tidak membatasi berapa kali tanda tangan dapat diverifikasi terhadap pesan yang sama. Setelah Anda memiliki tanda tangan yang valid, Anda dapat memutarnya ulang tanpa batas. Ini membuka pintu untuk memutar ulang serangan.

4/ Masukkan nonce: "nomor yang digunakan sekali" yang mencegah serangan pemutaran ulang. Ketika konsumen menerima pesan dengan nonce, ia memeriksa apakah nonce itu digunakan sebelumnya. Jika ya, → menolak. Transaksi Ethereum menggunakan pola ini.

5/ Tetapi implementasi nonce sangat rumit. Persyaratan utama: - Nonces TIDAK PERNAH dapat digunakan kembali (pada rantai ini atau lainnya) - Harus mencegah serangan replay secara permanen - Membutuhkan mekanisme untuk menangani pertumbuhan penyimpanan - Harus tahan terhadap serangan front-running

6/ Solusi naif: simpan semua nonces dalam database selamanya. Ini memiliki dua masalah utama: a) Pertumbuhan penyimpanan tak terbatas (terutama dengan serangan spam) b) Kerentanan terhadap serangan front-running Masalah (a) lebih mudah dipecahkan daripada (b). Mari kita bahas penyimpanan terlebih dahulu...

7/ Nonces berbasis stempel waktu memecahkan pertumbuhan penyimpanan! Gunakan stempel waktu + periode kedaluwarsa. Nonces yang lebih lama dari 5 menit akan dihapus dari database. Tapi bagaimana dengan pesan simultan dari akun yang sama? Mereka berbagi stempel waktu. Solusi: stempel waktu + random_bytes untuk keunikan terperinci.

8/ Lari di depan adalah bagian yang sulit. Aktor jahat dapat mencegat tanda tangan yang valid, menjalankannya untuk menandai nonces sebagai digunakan, lalu panggilan pengguna yang sah ditolak. Ini adalah onchain yang bermasalah dengan operasi batch jika satu tanda tangan yang buruk menolak seluruh batch. Untuk offchain: gunakan enkripsi TLS! Jangan biarkan aktor jahat melihat nonce atau tanda tangan.

9/ Jangan lupakan ketekunan! Jika cache nonce Anda hanya ada di memori, penyerang dapat memutar ulang nonces lama setelah sistem di-reboot. Selalu pertahankan status nonce ke penyimpanan yang tahan lama dan muat ulang saat startup. Cache hanya memori = jendela kerentanan pemutaran ulang.

10/ Nonces unik per konsumen! Saat menyiarkan ke beberapa pengguna, masing-masing harus mendapatkan pesan/tanda tangan yang berbeda. Jika tidak, Anda rentan terhadap serangan Man-in-the-Middle di mana satu penerima meneruskan pesan, menyamar sebagai pengirim asli.

11/ Nonces bertahap (seperti Ethereum, nonce = nonce sebelumnya + 1) memiliki tempatnya, tetapi berhati-hatilah! Mereka menciptakan tantangan besar untuk infrastruktur offchain: pesan yang tidak berurutan, masalah sinkronisasi, dan skenario pemulihan yang kompleks. Hanya gunakan jika Anda yakin pesan akan (atau harus) tiba secara berurutan.

Ringkasan - Daftar periksa implementasi Noce: ✅ Gunakan nonces untuk mencegah serangan replay ✅ Mempertahankan status nonce di seluruh reboot ✅ Menerapkan mekanisme kedaluwarsa (stempel waktu + pembersihan) ✅ Jadikan nonces unik per penerima ✅ Lindungi dari front-running dengan saluran terenkripsi ✅ Hindari nonces bertahap kecuali pesanan dijamin Keamanan ada dalam detailnya! 🛡️