Penulis artikel ini: Mysten Labs, Kostas Chalkias, dan Mahdi Sedaghat

https://www.sui.io/blog/suis-post-quantum-signature-schemes

Ringkasan poin-poin

  • Sui memilih ML-DSA-65 dari NIST Level 3, bukan tingkat keamanan yang lebih rendah dan biayanya lebih rendah. Saat ini, analisis kriptografi berbantuan AI sudah mampu memecahkan beberapa skema kriptografi kisi (lattice) yang telah melewati peninjauan manual bertahun-tahun, sementara biaya tambahan yang muncul akibat memilih margin keamanan yang lebih tinggi hampir dapat diabaikan: kinerja verifikasi ML-DSA-65 pada dasarnya setara dengan Ed25519.

  • Kedua solusi ini berasal dari dua sistem matematika yang berbeda. SLH-DSA berjalan di Move, bukan pada lapisan protokol; sehingga bahkan jika terjadi terobosan dalam kriptografi kisi, hal itu tidak memengaruhi jalur keamanan berbasis hash. Selain itu, Sui juga dapat beradaptasi terhadap perubahan standar eksternal tanpa perlu melakukan peningkatan protokol.

  • Pengguna yang sudah ada tidak akan terdampak. Kunci privat tetap 32 byte, sehingga metode backup dompet tidak perlu diubah. Akun pasca-kuantum menggunakan mode pilihan sukarela, dan alias alamat memungkinkan akun yang sudah ada untuk mengganti kunci yang diotorisasi menjadi kunci tahan kuantum sambil tetap mempertahankan alamat dan aset yang sama.

Dalam artikel terbaru (Sui tengah mempersiapkan diri untuk era kuantum), kami memperkenalkan arah pengembangan Sui untuk keamanan pasca-kuantum: gunakan ML-DSA-65 untuk autentikasi akun native, gunakan SLH-DSA-SHA2-128s untuk melindungi brankas bernilai tinggi, serta menyediakan jalur migrasi yang dapat mempertahankan alamat yang ada dan recovery phrase.

Artikel ini membahas “mengapa” di baliknya, dan menjelaskan pilihan-pilihan tersebut secara mendalam dari sudut pandang kriptografer. Mengapa memilih ML-DSA-65, bukan tingkat keamanan yang lebih murah? Mengapa meskipun tanda tangan Falcon lebih kecil, kami tidak memilihnya? Mengapa SLH-DSA ditempatkan di kontrak pintar, bukan di lapisan protokol? Mengapa kami tidak langsung memakai pustaka yang sudah ada, tetapi menulis wrapper Rust sendiri? Dalam proses itu, apa lagi yang kami temukan? Jika Anda ingin mengetahui logika teknis di balik keputusan-keputusan ini setelah membaca artikel sebelumnya, artikel ini adalah jawabannya.

Kesulitan sesungguhnya dari keputusan-keputusan ini, nyatanya, bukanlah memilih algoritma mana. NIST sudah hampir menyelesaikan masalah itu beberapa tahun lalu. Untuk tanda tangan, rentang kandidatnya sebenarnya hanya dua: ML-DSA (FIPS 204) dan SLH-DSA (FIPS 205). Pekerjaan besar justru ada setelah itu: memilih level keamanan, mengadopsi implementasi yang mana, cara memverifikasi kode, bagaimana menangani kunci yang sudah ada, serta jalan pintas yang secara teknis tampak menggoda namun akhirnya tidak dipilih.

Mari saya perkenalkan latar belakang kami dulu. Riset kami tentang sistem pasca-kuantum sudah lebih dulu dari Sui bertahun-tahun: pada 2017, kami meluncurkan skema pasca-kuantum produksi-level untuk Corda di R3—ini adalah tanda tangan pasca-kuantum yang pertama di bidang distributed ledger yang bersifat stateless dan bisa digunakan berulang; dalam beberapa tahun setelahnya, kami meneliti struktur kriptografi pasca-kuantum untuk blockchain bersama Mike Hearn; di Meta, kami membangun Winterfell—STARK prover sumber terbuka pertama; serta penelitian tentang PQ-EdDSA, HashWires, dan Truncator.

Untuk strategi migrasi spesifik bagi Sui, kami sudah merencanakannya sejak (bagaimana menjaga keamanan Sui di era komputasi kuantum) yang kami rilis pada April 2025—dari sisi tanda tangan, hash, enkripsi, hingga bukti pengetahuan nol. Yang diperkenalkan di bawah ini adalah bagian tanda tangan; kini keputusan terkait sudah ditetapkan final.

Definisi ancaman secara tepat

Algoritma Shor dapat langsung memecahkan kriptografi RSA dan kurva eliptik. Algoritma Grover hanya memberi percepatan tingkat kuadrat untuk fungsi hash; namun efek ini dapat dinetralisasi dengan menambah panjang output hash. Jadi untuk blockchain, hampir seluruh risiko kuantum terkonsentrasi pada tanda tangan, bukan pada hash.

Keunikan blockchain bukan pada algoritmanya sendiri, melainkan pada cara kunci publik diekspos. Dalam kebanyakan sistem, kunci publik berada di balik semacam batas akses, sehingga penyerang harus terlebih dulu menembus sistem dan barulah hitung mundur benar-benar dimulai. Namun di rantai (on-chain), ketika sebuah akun menyelesaikan transaksi pertamanya, kunci publiknya akan dipublikasikan secara permanen. Mirip dengan konsep “kumpulkan sekarang, dekripsikan nanti”, serangan terhadap tanda tangan bahkan tidak harus memiliki perangkat kuantum sekarang—cukup menyimpan data dan menunggu dengan sabar: kumpulkan kunci publik yang sudah dipublikasikan hari ini, lalu setelah perangkat kuantum matang, barulah memalsukan tanda tangan. Jendela pengumpulan itu sudah terbuka sejak beberapa tahun lalu, dan prediksi kemampuan komputasi kuantum juga terus bergerak ke arah yang sama: estimasi kebutuhan sumber daya untuk memecah kunci RSA 2.048-bit turun dari sekitar 20 juta quantum bits (qubit) pada 2019 menjadi kurang dari 1 juta pada 2025. Setiap kali koreksi, berarti mesin yang dibutuhkan menjadi lebih kecil dan lebih murah, bukan lebih mahal.

Ini juga mendefinisikan ulang tenggat waktu migrasi. Dalam perintah eksekutif nomor 14412 yang dirilis AS pada Juni 2026, lembaga federal diminta menyelesaikan migrasi pembentukan kunci pasca-kuantum sebelum Desember 2030, dan menyelesaikan migrasi tanda tangan digital sebelum Desember 2031—lebih cepat daripada jadwal migrasi 2035 yang masih berada pada tahap draf oleh NIST. Adapun untuk kunci di rantai (on-chain), batas waktunya bahkan lebih awal, karena risikonya terakumulasi ke masa lalu: sebuah kunci yang sudah dipublikasikan sejak hari pertama berarti sudah terekspos sejak hari pertama, bukan mulai terekspos ketika batas waktu tiba.

Mengapa memilih ML-DSA-65, bukan ML-DSA-44

NIST membagi skema pasca-kuantum menjadi lima tingkat keamanan. Setiap tingkat memiliki tolok ukur serangan brute-force, bukan angka keamanan yang abstrak dalam satuan bit:

  • Level 1：tingkat kesulitannya minimal setara dengan memulihkan kunci AES-128

  • Level 3：setara dengan AES-192

  • Level 5：setara dengan AES-256

Tingkat genap didefinisikan berdasarkan tabrakan (hash collision): Level 2 sesuai SHA-256, Level 4 sesuai SHA-384.

ML-DSA menyediakan tiga set parameter:

ML-DSA-44：Level 2

ML-DSA-65：Level 3

ML-DSA-87：Level 5

Sebuah tingkat keamanan mewakili ambang keamanan di bawah metode serangan terbaik yang diketahui saat ini. Karena itu, memilih tingkat tertentu pada dasarnya menjawab pertanyaan: jika pada masa depan metode serangan paling canggih semakin membaik, seberapa besar ruang keamanan yang perlu kita sisakan?

Sui 最终选择 menggabungkan ML-DSA-65 Level 3 sebagai skema tanda tangan asli protokol, bukan ML-DSA-44 yang biayanya lebih rendah.

Salah satu alasan penting lainnya adalah, baru-baru ini Anthropic menemukan serangan terhadap skema tanda tangan HAWK. HAWK adalah skema kriptografi berbasis kisi yang telah diteliti secara mendalam dan menjalani banyak tinjauan kriptoanalisis. Perlu ditekankan bahwa HAWK dan ML-DSA didasarkan pada masalah kisi yang berbeda, sehingga serangan terhadap HAWK tidak bisa diterapkan langsung ke ML-DSA. Namun yang benar-benar layak diperhatikan adalah pelajaran yang dibawanya: analisis kripto berbantuan AI telah mulai menemukan masalah yang selama bertahun-tahun tetap tidak ditemukan meskipun sudah lama ditinjau manusia.

Ini mengubah cara kita menilai seberapa besar ruang keamanan (safety margin) yang perlu dipertahankan untuk asumsi kriptografi berbasis kisi (lattice). Level 1 meninggalkan ruang yang lebih kecil ketika estimasi keamanan berubah, sedangkan Level 3 menyediakan buffer yang lebih besar—dan terbukti bahwa biaya dari tambahan margin keamanan ini sangat kecil.

Ada dua alasan tambahan. Pertama, Chrome dan Cloudflare juga memilih Level 3 dalam pertukaran kunci pasca-kuantum yang saat ini sudah melindungi banyak lalu lintas Web, sehingga level ini sudah memiliki pengalaman deployment yang lebih banyak. Kedua, saat berdiskusi dengan industri keuangan yang teregulasi mengenai mekanisme pembentukan kunci, Level 3 juga lebih sesuai dengan ekspektasi keamanan institusi-institusi tersebut.

Dukungan perangkat keras juga merupakan faktor penting yang kami pertimbangkan. Kami langsung menguji kompatibilitas FIPS 204 dengan SDK dari vendor HSM dan hardware wallet. Kami juga menguji ML-DSA pada perangkat DePIN berdaya sangat rendah—perangkat seperti ini mewakili batas CPU dan RAM yang dihadapi wallet pasca-kuantum berbasis NFC, serta menjadi skenario pertama ketika algoritma terlalu berat.

Seluruh ekosistem juga tengah bergerak menuju pilihan yang serupa. Ledger baru-baru ini menambahkan dukungan awal ML-DSA resmi (FIPS 204) ke SDK-nya, dan kompatibel secara bit-per-bit dengan standar NIST. Kami juga memverifikasi bahwa Ledger dan implementasi kami bisa saling beroperasi tanda tangan dua arah.

Sementara itu, kami terus memantau kemajuan kriptoanalisis yang menargetkan ML-DSA. Ketidakpastian yang terus ada ini—itulah salah satu alasan kami memprioritaskan peluncuran SLH-DSA sebagai solusi tanda tangan cerdas di kontrak, dan merekomendasikannya untuk brankas bernilai tinggi: keamanannya bergantung pada fungsi hash, bukan pada kriptografi berbasis kisi. Karena itu, bahkan jika di masa depan ada terobosan riset kisi yang memengaruhi estimasi keamanan ML-DSA, hal tersebut tidak akan memengaruhi SLH-DSA.

Mengapa tidak memilih Falcon?

Salah satu kandidat berbasis kisi lainnya adalah Falcon (FN-DSA, yaitu FIPS 206 yang akan datang). Keunggulan utamanya adalah tanda tangan yang lebih kecil. Ukuran tanda tangan FN-DSA-512 pada Level 1 hanya 666 byte, sedangkan ukuran tanda tangan ML-DSA-65 pada Level 3 adalah 3.309 byte.

Meskipun demikian, kami tetap tidak memilih Falcon, karena termasuk:

  • Tidak ada Level 3. Falcon hanya menyediakan dua tingkat keamanan, Level 1 dan Level 5 (masing-masing FN-DSA-512 dan FN-DSA-1024): Anda memilih Level 1 yang margin-nya lebih kecil seperti yang baru saja kami sebutkan, atau menanggung biaya Level 5 untuk mendapatkan buffer keamanan yang lebih besar—yang akan membuat metrik-metrik kira-kira menjadi dua kali lipat.

  • Belum diselesaikan standarisasinya. FIPS 206 saat ini masih belum final; sebagai perbandingan, FIPS 204 sudah resmi final sejak 2024.

  • Kurangnya standarisasi cara derivasi seed ke kunci. Ini akan merusak karakteristik seed 32 byte yang memungkinkan metode backup dompet tetap tidak berubah.

  • Sampling Gaussian berbasis float. Saat menandatangani, Falcon perlu menggunakan floating point FFT untuk melakukan discrete Gaussian sampling, dan mekanisme ini umumnya dianggap lebih sulit untuk diselesaikan dengan benar dibanding implementasi mana pun yang dibutuhkan oleh ML-DSA. Sebaliknya, ML-DSA menggunakan integer dari awal sampai akhir.

  • Lebih sulit mengimplementasikan dengan aman. Di bawah mekanisme Gaussian sampling, perlu memastikan eksekusi constant-time, ketahanan terhadap serangan fault dan serangan cache, serta memastikan kualitas bilangan acak—ini menuntut persyaratan implementasi yang lebih tinggi.

  • Perlindungan terhadap side-channel lebih sulit. Karena melibatkan Gaussian sampling dan operasi FFT, Falcon umumnya dianggap lebih sulit untuk dibuat aman dan andal dibanding ML-DSA dalam melawan serangan timing, serangan cache, dan serangan fault.

  • Kecepatan verifikasi. Pada tingkat keamanan yang lebih tinggi, kecepatan verifikasi Falcon lebih lambat daripada hasil pengujian ML-DSA kami. Secara spesifik, pada mesin yang sama, waktu verifikasi FN-DSA-1024 adalah 49,8 mikrodetik, sedangkan ML-DSA-65 hanya 23,2 mikrodetik. Artinya, dengan margin keamanan yang cukup, kecepatan verifikasi parameter set Falcon kira-kira 2 kali lebih lambat dibanding skema yang kami pilih.

  • Ekosistem perangkat keras. Banyak vendor HSM, smart card, TPM, dan elemen keamanan memprioritaskan dukungan ML-DSA: ia menyelesaikan standardisasi lebih awal, lebih mudah diimplementasikan, dan juga merupakan skema yang paling diminta mendukung oleh pelanggan perusahaan. Berdasarkan masukan yang kami terima, dukungan perangkat keras untuk Falcon sedang membaik, tetapi adopsinya masih belum sebanyak ML-DSA.

  • Terakhir, yang tak kalah penting adalah ekosistem dan alat. Saat ini ML-DSA lebih matang dalam hal pustaka kriptografi, SDK, test vector, paket kepatuhan, serta implementasi yang sudah tersertifikasi. Ini dapat menurunkan risiko implementasi rekayasa, terutama ketika dijadikan fitur native protokol.

Oleh karena itu, ukuran tanda tangan yang lebih kecil tidak cukup untuk menutup kekurangan-kekurangan ini.

Mengapa SLH-DSA berjalan di Move, bukan di lapisan protokol

Untuk aset bernilai tinggi, kami menyediakan brankas smart contract berbasis hash menggunakan SLH-DSA-SHA2-128s (FIPS 205), bukan menjadikannya skema tanda tangan native protokol. Ini bukan karena kami tidak mempercayai SLH-DSA. Justru sebaliknya. Kriptografi berbasis hash adalah kelas yang pemahamannya lebih mendalam dalam dua sistem tersebut, dan SHA-256 juga sudah banyak digunakan. Beberapa tim hardware wallet yang kami konsultasi bahkan lebih menyukai skema berbasis hash, karena para engineer memahaminya lebih dalam.

Alasannya menaruhnya di dalam kontrak ada tiga:

  • Karakteristik biaya. Biaya verifikasi SLH-DSA jelas lebih tinggi daripada Ed25519, dan ukuran tanda tangannya juga lebih besar, sehingga tidak bisa secara efektif mengurangi overhead dengan caching. Untuk ML-DSA, kunci publik adalah bagian yang bisa digunakan ulang, sehingga caching memberi keuntungan yang nyata; sedangkan SLH-DSA tidak memiliki ruang optimasi seperti itu.

  • Risiko perubahan standar. Bitcoin, Ethereum, dan putaran standar NIST berikutnya sangat mungkin akhirnya mengerucut ke sekumpulan skema tanda tangan yang lebih kecil daripada saat ini. Apa pun skema yang dipilih komunitas Bitcoin dan Ethereum—termasuk berbagai skema berbasis hash yang sedang dibahas saat ini—kami ingin dapat dengan cepat mewujudkan kompatibilitas. Jembatan Sui ke Ethereum, serta Hashi untuk Bitcoin, membuat kebutuhan ini lebih nyata: jika diimplementasikan di dalam kontrak, maka dompet Bitcoin yang mendukung kriptografi pasca-kuantum yang kompatibel di Sui tidak perlu merilis versi inti Sui yang baru; jika diimplementasikan secara native, maka setiap kali standar target eksternal berubah, kemungkinan besar akan diperlukan upgrade protokol.

  • Ruang implementasi. Implementasi SLH-DSA di Move terutama melibatkan operasi terkait pohon Merkle. Dibandingkan menambahkan autentikator native, ruang implementasinya lebih kecil, dan kodenya lebih jelas serta mudah dipahami. Selain itu, ia bisa langsung diluncurkan tanpa perlu fork atau upgrade protokol, karena pemrosesan byte yang dibutuhkan dan primitif hash sudah ada di bahasa Move.

Dua skema ini dibangun di atas sistem matematika yang berbeda—itulah inti dari desainnya. Jika asumsi keamanan kriptografi berbasis kisi dipecahkan, itu tidak akan memengaruhi jalur keamanan berbasis hash; demikian juga sebaliknya.

Untuk akun dengan nilai tertinggi, mekanisme multisig 2-of-2 Sui yang sudah ada juga memungkinkan pengguna meminta sekaligus tanda tangan tradisional dan tanda tangan pasca-kuantum untuk mengotorisasi transaksi, sehingga tidak ada satu pun skema yang berdiri sendiri menjadi single point of failure dalam sistem keamanan. Ini juga alasan di balik solusi keamanan hibrida yang belakangan diperdebatkan oleh Bernstein.

Kedua skema ini mengikuti algoritma kriptografi pasca-kuantum yang distandardisasi oleh NIST (ML-KEM, ML-DSA, SLH-DSA), serta roadmap persiapan keamanan kuantum yang disusun bersama CISA, NSA, dan NIST.

Pengujian performa

Pilihan-pilihan di atas akhirnya tetap tak lepas dari biaya. Kami mengujinya dengan fastcrypto pada Apple M2 Max.

Yang benar-benar penting di sini ada dua hal.

Performa verifikasi sebanding dengan Ed25519, bahkan sedikit lebih baik; akibatnya, biaya CPU yang dibutuhkan node verifikasi untuk memproses setiap tanda tangan tidak meningkat. Hal ini penting karena Sui adalah salah satu L1 tercepat di dunia—bahkan setelah migrasi tahan kuantum selesai, kita tetap harus mempertahankan keunggulan tersebut. Indikator yang benar-benar penting adalah biaya verifikasi, karena biaya komputasi terjadi di lokasi berbeda: pembuatan kunci dan penandatanganan dilakukan di luar rantai untuk setiap transaksi oleh perangkat penanda; sedangkan verifikasi perlu dilakukan oleh setiap node verifikasi untuk setiap transaksi. Dari nilai absolut, kecepatan tanda tangan memang lebih lambat, tetapi di perangkat sisi klien hanya sekitar 66 mikrodetik, dan bahkan di browser pun hanya level milidetik—pengguna pada dasarnya tidak merasakan perbedaan itu.

Kunci privat tetap 32 byte, karena pada dasarnya ia adalah sebuah seed. Dompet dapat terus melakukan backup dan pemulihan dengan cara yang benar-benar sama seperti sekarang, sedangkan kunci baru akan dihasilkan melalui jalur turunan standar yang baru dari recovery phrase yang sama yang dimiliki pengguna.

Biaya yang benar-benar harus dibayar adalah ukuran data: data terkait per transaksi akan bertambah kira-kira hingga 50 kali lipat dari semula. Ini adalah biaya yang harus ditanggung seluruh industri untuk memperoleh kemampuan tahan kuantum, dan inilah fokus utama pekerjaan optimasi kami saat ini. Namun, untuk Sui ada dua faktor yang dapat mengurangi masalah ini. Pertama, batas maksimum ukuran transaksi Sui bisa mencapai 128 KB, sehingga dibandingkan blockchain yang membatasi ukuran transaksi secara lebih ketat, Sui memiliki ruang lebih besar. Kedua, kami sebelumnya sudah meluncurkan dan benar-benar menjalankan skema yang mencakup tanda tangan berukuran besar, termasuk multisig dan zkLogin. Selain itu, blok transaksi yang dapat diprogram (PTB) memungkinkan satu tanda tangan mengotorisasi banyak operasi, sehingga overhead tambahan per operasi rata-rata sebenarnya lebih rendah daripada perkiraan langsung dari ukuran satu tanda tangan saja. Ke depan, mekanisme caching kunci publik serupa seperti yang ada pada zkLogin juga bisa diterapkan: pengguna hanya perlu mengirim kunci publik mereka sekali, lalu transaksi berikutnya cukup mengirim tanda tangan. Namun, fitur ini tidak akan diaktifkan pada versi awal. Kami ingin implementasi versi pertama tetap relatif konservatif, lalu mengaktifkan optimasi ini secara bertahap setelah dipertimbangkan secara matang.

Perlu dijelaskan juga bahwa data di atas hanya mewakili satu konfigurasi pengujian. Untuk laporan performa yang lebih lengkap dan ketat, perlu mencakup jalur eksekusi Rust di sisi verifikator node, konfigurasi untuk developer biasa, serta penandatanganan di sisi browser melalui stack teknologi TypeScript. Kami berencana untuk mempublikasikan data pengujian yang lebih lengkap setelah ini. Untuk perbandingan yang lebih menyeluruh terhadap kandidat tanda tangan NIST, Anda bisa merujuk ke nist-sigs-zoo.

Selain itu, penelitian Remora milik Sui tentang ekstensibilitas eksekusi juga membuat masalah ekspansi throughput yang terlibat dalam migrasi pasca-kuantum menjadi lebih mudah ditangani. Kedua jalur penelitian ini sejak awal memang sengaja dipromosikan secara bersinergi.

Cara implementasi, dan mengapa kami memilih untuk melakukannya sendiri

Hampir setiap bahasa pemrograman memiliki pustaka kriptografi besar, dan di dalamnya sudah termasuk ML-DSA. Jadi, mengimpor pustaka jadi tampaknya menjadi pilihan paling jelas. Tapi kami mengambil pendekatan berbeda: kami mengembangkan mysten-mldsa-native-rs, yaitu wrapper Rust ringan yang kami tulis berdasarkan mldsa-native. mldsa-native adalah implementasi ML-DSA yang ringkas dan diverifikasi secara formal, yang dipelihara oleh proyek pq-code-package di bawah Linux Foundation. Ia memakai inti yang sama dengan beberapa pustaka kriptografi industri arus utama seperti aws-lc, hanya saja tidak menyertakan komponen lain dari pustaka besar tersebut.

Alasan kami melakukannya seperti ini adalah karena bagian kode ini berada di jalur eksekusi konsensus. Setiap verifikator node perlu menjalankan kode verifikasi untuk setiap transaksi, jadi kami ingin mempersempit ruang implementasi agar kodenya mudah dibaca dan diaudit, sekaligus menghindari opsi yang mungkin salah dikonfigurasi. Enkapsulasi ini hanya menyediakan satu mode: mode default FIPS 204, menggunakan hedged signing (tanda tangan dengan pengimbangan), yaitu setiap kali menandatangani menggunakan keacakan baru untuk meningkatkan ketahanan terhadap serangan fault dan masalah penggunaan ulang bilangan acak. Ia sendiri tidak memuat generator bilangan acak, sehingga setiap operasi bisa direproduksi di lingkungan pengujian. Bentuk serialisasi untuk kunci privat hanya satu, yaitu seed 32 byte, sehingga dompet tetap dapat melakukan backup dan pemulihan dengan cara yang benar-benar sama seperti saat ini.

Seperti disebut sebelumnya, kecepatan implementasi kami sangat cepat. Hal ini terutama berkat implementasi assembly yang sudah diverifikasi dari hulu untuk Apple/ARM dan server x86. Sistem akan memilih implementasi yang sesuai secara otomatis saat runtime berdasarkan mesin yang berbeda, sehingga memastikan bahwa file biner yang sama dapat berjalan dengan benar dalam lingkungan perangkat keras verifikator node yang beragam. Apa pun implementasi lapisan dasar yang dipilih, tanda tangan yang dihasilkan akan benar-benar sama. Perbedaannya hanya pada performa: kecepatan eksekusi backend assembly kira-kira 2,5 kali lebih cepat daripada implementasi C yang portabel.

Sebuah titik kegagalan yang jarang dibahas

Bagian paling berbahaya dari kriptografi baru sering kali bukan matematikanya, melainkan kode dan implementasi yang dikebut.

Tahun ini, terungkap adanya celah integritas (soundness) pada sebuah STARK prover yang terkemuka: sebuah nilai yang dipercaya oleh verifikator node ternyata tidak benar-benar terikat ke transcript pembuktian, sehingga penyerang dapat memalsukan bukti pernyataan yang salah, sementara verifikator node tetap menerimanya. Celah ini sudah ada di kode sumber terbuka sejak 2024, melewati audit eksternal dan verifikasi formal, namun tidak pernah ditemukan. Akhirnya pada Juni 2026, celah ini ditemukan oleh alat audit berbasis AI—untungnya belum sempat dieksploitasi sebelumnya.

ML-DSA sendiri juga pernah mengalami kasus serupa. Hanya pada tahun 2026 saja, dalam 3 basis kode independen untuk skema tanda tangan ini sudah diungkapkan 4 celah pada level implementasi:

  • Ada celah out-of-bounds write pada proses tanda tangan libgcrypt (CVE-2026-41990);

  • Ada celah side-channel timing pada proses perhitungan hint di crate ml-dsa milik RustCrypto yang dapat menyebabkan kebocoran informasi kunci tanda tangan (CVE-2026-22705);

  • Di crate yang sama juga ada celah verifikasi yang secara keliru menerima tanda tangan yang berisi repeated hint index (CVE-2026-24850);

  • Ada celah fault injection pada kode pasca-kuantum untuk perangkat tertanam dari wolfSSL (CVE-2026-3503).

Yang paling patut dicermati adalah celah verifikasi tersebut: menurut standar FIPS 204, tanda tangan yang valid hanya memiliki satu cara pengkodean yang sah. Jika sebuah implementasi keliru menerima pengkodean kedua, maka validitas tanda tangan bisa bergantung pada node mana yang Anda tanyai. Di blockchain, hal ini dapat langsung menyebabkan chain split.

Sementara itu, pada periode yang sama, jumlah kali matematika dasar ML-DSA sendiri berhasil ditembus adalah nol.

Dengan kata lain, fondasi matematiknya saat ini tetap kokoh; risiko sebenarnya lebih banyak berada pada level implementasi kode.

Kami berkali-kali menyebut contoh ini karena ia menyediakan patokan penilaian risiko yang sangat penting dan masuk akal untuk apa pun yang kami publikasikan; hasil riset HAWK juga mengarah ke arah yang sama. Mekanisme audit yang selama ini lama kami andalkan—termasuk audit manual, metode formal, dan fakta bahwa kode tersebut sudah beredar dan diuji secara publik selama bertahun-tahun—tidak menemukan masalah-masalah itu, sementara analisis berbantuan AI justru menemukannya.

Ini semakin menegaskan bahwa kita perlu:

  • Menyisakan ruang keamanan yang cukup saat memilih parameter keamanan;

  • Menjaga ruang implementasi serendah mungkin, agar mudah diaudit;

  • Menjadikan verifikasi lintas-implementasi sebagai ambang batas yang wajib dalam proses pembangunan;

  • Untuk komponen yang terbaru dan tingkat kematangannya masih relatif rendah, gunakan strategi peluncuran yang lebih hati-hati dan bertahap.

Ini juga alasan untuk bagian berikutnya yang akan kita bahas.

Kami belum menekan tombol itu untuk saat ini

Kami sebenarnya punya jalan pintas yang lebih ideal daripada skema yang saat ini kami gunakan, tetapi untuk saat ini kami belum memilihnya.

Setiap kunci Ed25519 di Sui diturunkan dari sebuah seed yang dilindungi dengan hash. Bahkan jika komputer kuantum berhasil memecahkan skema kriptografi kurva eliptik, ia hanya bisa memulihkan skalar tanda tangan, tetapi tidak dapat menelusuri kembali seed asli yang menghasilkan skalar tanda tangan tersebut. Paper riset kami Post-Quantum Readiness in EdDSA Chains (Baldimtsi, Chalkias, Roy dan Sedaghat, eprint 2025/1368) memanfaatkan sifat asimetris ini untuk mengubahnya menjadi sebuah bukti kepemilikan yang tahan kuantum: pengguna dapat membuktikan melalui bukti pengetahuan nol bahwa mereka memegang seed asli, sehingga mengotorisasi sebuah kunci pasca-kuantum yang baru, sambil mempertahankan alamat yang lama, dan dalam seluruh proses tidak ada informasi rahasia yang perlu diekspos.

Skema ini memiliki beberapa karakteristik yang lebih baik dibanding migrasi melalui jalur turunan baru. Skema ini cocok untuk akun yang kunci publiknya sudah terekspos; juga dapat ditelusuri untuk diterapkan pada kunci yang sudah diturunkan bertahun-tahun lalu; bahkan dapat diterapkan pada akun yang “tidur” dan tidak akan menandatangani transaksi apa pun lagi di masa depan. Ini adalah kategori akun yang tidak dapat dicakup oleh skema migrasi lain. Untuk blockchain yang tidak mendukung turunan seed deterministik, akun seperti ini bahkan sama sekali tidak dapat dimigrasikan dengan cara ini. Inilah keunggulan struktural yang dimiliki blockchain berbasis EdDSA dibanding ECDSA, dan inilah alasan paper ini meneliti EdDSA secara khusus.

Jadi, jika skema ini begitu bagus, mengapa sekarang tidak langsung mengaktifkannya? Karena tombol ini pada dasarnya adalah sebuah sistem bukti pengetahuan nol. Jika sekarang diaktifkan, maka keamanan akun akan bergantung pada sistem pembuktian ini, dan teknologi ini sendiri lebih muda daripada skema tanda tangan yang ingin dilindunginya. Dikombinasikan dengan risiko implementasi yang disebut pada bagian sebelumnya, inilah alasan kami memilih untuk berhati-hati.

Biaya untuk menunggu sebenarnya kecil, karena tombol ini tidak akan kedaluwarsa. Sebuah seed tidak akan menjadi tidak rahasia hanya karena waktu berlalu. Setelah sistem bukti pengetahuan nol mengumpulkan cukup validasi keamanan dan kepercayaan, kami masih dapat membangun dan mengaktifkan mekanisme pembuktian tersebut. Sementara itu, kami akan menyelesaikan migrasi dengan cara yang lebih langsung terlebih dahulu: melalui jalur derivasi yang baru untuk mendukung akun pasca-kuantum native, dan menggunakan alias alamat untuk membantu migrasi akun yang sudah ada.

Oleh karena itu, saat ini kami memandang zkPQ-EdDSA sebagai saklar keamanan darurat yang diperlukan di masa depan jika suatu saat dibutuhkan, bukan sebagai fitur peluncuran pertama. Ada satu karakteristik desain lain yang patut diperhatikan: karena kunci privat ML-DSA di Sui juga merupakan seed 32 byte, maka di masa depan jika diperlukan, mekanisme “bukti kepemilikan seed” ini juga dapat diterapkan lebih lanjut pada akun pasca-kuantum itu sendiri.

Mekanisme migrasi

Dalam dua peningkatan keamanan tersebut, Sui akan menyediakan jalur derivasi standar yang baru dan menerapkan pilihan sukarela di level akun. Akun yang sudah ada tidak perlu memindahkan dana. Alias alamat (Address Aliases) yang sudah dideploy memungkinkan akun memperbarui kunci yang diotorisasi menjadi kunci pasca-kuantum, sekaligus: alamat tetap tidak berubah, dan aset tetap di tempat semula. Untuk pengguna yang sudah ada, mekanisme inilah yang sebenarnya menanggung pekerjaan migrasi saat ini, bukan skema bukti pengetahuan nol yang disebut sebelumnya dan saat ini masih ditunda.

Untuk brankas tahan kuantum, penarikan menggunakan model dua transaksi, sedangkan transfer sederhana mungkin hanya memerlukan satu. Bagi pengembang dan institusi, maknanya sangat jelas: akun tahan kuantum akan diluncurkan bertahap sebagai fitur opsional baru, seperti zkLogin dan Passkeys. Tidak ada pemaksaan migrasi, dan fitur yang ada tidak akan berubah. Mengaktifkannya hanyalah upgrade fungsi protokol yang rutin, bukan perubahan pada mekanisme konsensus atau status yang sudah ada.

Sejauh mana industri sudah sampai

Kami bukan satu-satunya tim yang melakukan ini, dan kami juga tidak ingin menjadi satu-satunya. Near musim panas ini sudah merilis ML-DSA-65 sebagai tipe kunci opsional, dengan memilih skema dan tingkat keamanan yang sama seperti Sui—ini merupakan sinyal independen yang berharga. Roadmap konsensus Ethereum lebih condong ke skema berbasis hash. Bitcoin saat ini memiliki beberapa proposal aktif, tetapi belum memutuskan pilihan final.

Kami menganggap bahwa keunggulan nyata Sui bukanlah memilih algoritma mana, melainkan desain arsitekturnya:

  • Dua skema tersebut sesuai dengan dua model ancaman;

  • Brankas dapat beradaptasi dengan standar eksternal tanpa upgrade protokol;

  • Pengguna dapat mempertahankan alamat yang lama;

Kondisi saat ini dan jadwal

Implementasi inti sudah selesai dan sudah menjalani pengujian performa. Rencana saat ini:

  • Brankas tahan kuantum: terpasang di mainnet tahun ini;

  • Akun ML-DSA-65 native: sebelum akhir tahun masuk ke testnet;

  • Autentikasi akun native: target paling lambat masuk ke mainnet pada kuartal pertama 2027.

Dukungan untuk wallet, SDK, dan CLI akan dirilis secara bersamaan.

Audit eksternal independen saat ini sedang berlangsung. Kami tidak dapat menjamin semua audit akan selesai sepenuhnya sesuai rencana, dan karena itu kami lebih memilih menunda tanggal daripada meluncurkan autentikator yang belum diaudit secara memadai. Karena itu, artikel ini menjelaskan arah saat ini, dan waktu final masih mungkin disesuaikan berdasarkan hasil audit dan umpan balik dari testnet.

Semua hal yang dibutuhkan untuk tinjauan terkait sudah dipublikasikan, termasuk FIPS 204, FIPS 205, implementasi mldsa-native C yang sudah diverifikasi secara formal, wrapper native Rust mysten-mldsa-native-rs dari Mysten, serta implementasi open-source Post-Quantum Readiness in EdDSA Chains yang saat ini sengaja kami tunda untuk diluncurkan.

Dibanding mencari pujian, kami lebih ingin pekerjaan ini mendapatkan perhatian dan bisa diaudit. Kami sengaja membatasi ruang implementasi sedemikian rupa, menjadikan verifikasi silang sebagai ambang batas wajib dalam pembangunan, dan sengaja menunda penerapan jalan pintas migrasi. Jika Anda bekerja pada penandatanganan pasca-kuantum, hardware wallet, atau sistem proving, dan merasa ada salah satu keputusan yang bermasalah, kami sangat ingin mendengar pendapat Anda.

Sebuah telur paskah

Jalur turunan adalah aturan yang diikuti dompet ketika mengonversi sebuah mnemonic menjadi banyak kunci: ia terdiri dari serangkaian angka yang diaplikasikan secara berurutan langkah demi langkah. Karena itu, mnemonic yang sama akan menghasilkan kunci yang sama di perangkat apa pun. Semua kunci berbasis mnemonic di Sui diturunkan melalui jalur seperti ini, dan angka pertama—nomor kegunaan—digunakan untuk mengidentifikasi skema tanda tangan.

Saat ini, kunci Ed25519 di Sui menggunakan jalur derivasi berikut:

m/44'/784'/0'/0'/0'

Di mana 784' mewakili Sui, 44' adalah nomor kegunaan; skema tanda tangan ECDSA masing-masing menggunakan 54' dan 74'. Kunci pasca-kuantum akan memakai:

m/94'/784'/0'/0'/0'

Angka 94 di sini bukan sekadar angka berikutnya dalam urutan, tetapi ia merepresentasikan sebuah tahun. Kebetulan, Peter Shor menerbitkan algoritma yang membuat semua ini menjadi perlu pada tahun 1994. Untuk merayakan kebetulan ini, setiap jalur derivasi kunci kuantum-aman (quantum-safe) Sui akan menyertakan tahun saat hitungan mundur ini dimulai.