Arahan dan ruang lingkup
Implementasikan wrapper verifikasi tanda tangan ML-DSA di mana pemanggil menyediakan algoritma, kunci publik, pesan, tanda tangan, dan konteks. Bagaimana Anda memvalidasi input, mencegah replay lintas-protokol, serta merancang penanganan error dan pengujian?
Hal yang dievaluasi pewawancara
- Menggunakan kembali implementasi FIPS 204 yang telah divalidasi alih-alih menulis ulang primitif kriptografi berbasis kisi (lattice cryptography).
- Menjaga pengidentifikasi algoritma, kunci publik, pesan, tanda tangan, dan konteks sebagai input yang tidak ambigu.
- Membedakan tanda tangan tidak valid, input salah bentuk (malformed), algoritma yang tidak didukung, dan kesalahan internal tanpa membocorkan detail sensitif.
- Menggunakan pengikatan konteks (context binding), antarmuka yang ramping, dan uji vektor untuk mencegah replay lintas-protokol dan pergeseran implementasi (implementation drift).
Pertanyaan klarifikasi
- Set parameter ML-DSA mana yang digunakan, dan apakah pustaka tersebut telah lulus validasi vektor FIPS 204?
- Protokol mana yang mendefinisikan konteks, apakah boleh kosong, serta batasan pengkodean dan panjang apa yang berlaku?
- Apakah kegagalan verifikasi merupakan hasil bisnis biasa atau peristiwa peringatan dan audit?
- Apakah pesan dialirkan (streamed), apakah antarmuka pra-hash diperlukan, dan bagaimana kunci dirotasi?
Kerangka jawaban 30 detik
Saya akan menjaga wrapper tetap berada di atas API pustaka ML-DSA yang telah divalidasi. Pilih set parameter dari pengidentifikasi algoritma yang eksplisit, validasi input byte dan konteks, serta teruskan konteks protokol bersama pesan ke proses verifikasi. Kembalikan hanya valid, invalid, unsupported, atau malformed; jangan pernah mengembalikan trace eksepsi. Uji vektor resmi, manipulasi (tampering), set parameter yang salah, replay lintas-konteks, batas panjang, konkurensi, dan rotasi. Kunci privat dan pesan lengkap tidak boleh masuk ke dalam log.
Pembahasan mendalam langkah demi langkah
1. Menetapkan batas wrapper
FIPS 204 mendefinisikan penandatanganan dan verifikasi ML-DSA; RFC 9882 mencatat bahwa CMS menggunakan algoritma verifikasi yang sama untuk tanda tangan hedged dan deterministik. Kode aplikasi tidak boleh mengimplementasikan NTT, sampling, atau rejection sampling. Kunci dependensi, set parameter, dan antarmuka pustaka yang telah teruji.
2. Memvalidasi input dan konteks
Periksa apakah pengidentifikasi algoritma diizinkan, byte kunci publik dan tanda tangan sesuai dengan set parameter yang dipilih, dan pesan berada dalam kebijakan. Enkode konteks sesuai dengan protokol. Konteks bukanlah label log; konteks menyediakan pemisahan domain tanda tangan dan harus berupa nilai yang sama yang disepakati oleh penandatangan. Konteks yang hilang atau salah akan menghasilkan malformed atau invalid; jangan pernah menebak konteks kosong.
3. Merancang semantik error yang aman
Kembalikan hasil terstruktur seperti valid, invalid, unsupported, atau malformed alih-alih mengulang eksepsi pustaka, materi kunci, atau detail parser. Metrik dan audit hanya mencatat algoritma, versi, kelas hasil, dan id permintaan. Kesalahan internal diteruskan melalui saluran error dan peringatan yang terkontrol; kerusakan pustaka (library crash) tidak boleh disamarkan sebagai tanda tangan tidak valid.
4. Mengunci perilaku dengan vektor dan pengujian protokol
Jalankan vektor yang kompatibel dengan NIST ACVP atau FIPS 204 terlebih dahulu, lalu uji pembalikan bit (bit flips), pemotongan (truncation), konteks yang berbeda, pengidentifikasi algoritma yang salah, dan kunci lama. Dalam kasus lintas-protokol, pastikan pesan yang sama tidak diterima di bawah konteks yang berbeda. Gunakan input yang tidak dapat diubah (immutable) untuk panggilan konkuren, terima rentang waktu kunci lama yang eksplisit selama rotasi, dan tolak setelah kedaluwarsa.
Contoh jawaban berkualitas tinggi
Saya akan membuat ini sebagai wrapper tipis di sekitar pustaka yang divalidasi, bukan mengimplementasikan ulang ML-DSA. Pemanggil harus menyediakan pengidentifikasi algoritma yang eksplisit, set parameter, kunci publik, pesan, tanda tangan, dan konteks protokol. Wrapper memvalidasi format dan ukuran, meneruskan konteks yang sama ke API verifikasi, dan tidak pernah mencoba ulang set parameter lain atau konteks kosong setelah kegagalan. Ini hanya mengembalikan valid, invalid, unsupported, atau malformed; kesalahan internal memicu peringatan secara terpisah, dan log mengecualikan kunci serta pesan. Vektor FIPS/ACVP, uji manipulasi, pemotongan, replay lintas-konteks, rotasi kunci, dan konkurensi memastikan perilaku tetap konsisten sementara versi pustaka dan parameter tetap dikunci.
Kesalahan umum
- Mengimplementasikan ulang NTT, sampling, atau rejection sampling ML-DSA.
- Mengabaikan pengidentifikasi algoritma dan mencoba satu kunci publik di berbagai set parameter.
- Mencoba ulang dengan konteks kosong atau alternatif setelah verifikasi gagal.
- Menggabungkan kerusakan pustaka, tanda tangan tidak valid, dan input salah bentuk menjadi satu hasil yang tidak beralasan.
- Menulis pesan lengkap, kunci, atau trace eksepsi ke dalam log.
- Hanya menguji happy path tanpa kasus vektor, manipulasi, replay, dan rotasi.
Pertanyaan lanjutan dan jawaban
Apakah tanda tangan hedged dan deterministik memerlukan kode verifikasi yang berbeda?
Tidak. RFC 9882 menyatakan bahwa keduanya menggunakan algoritma verifikasi yang sama, sehingga wrapper tidak boleh bercabang ke dua jalur verifikasi berdasarkan mode penandatanganan.
Mengapa konteks mencegah replay lintas-protokol?
Konteks mengikat tanda tangan ke domain protokol. Pesan dan kunci yang sama memiliki arti verifikasi yang berbeda di bawah konteks yang berbeda; verifikator tidak boleh menebak atau menggunakan nilai fallback ketika konteks hilang.
Bagaimana Anda menangani pembaruan pustaka?
Kunci set parameter dan versi pustaka, jalankan vektor resmi dan sampel kompatibilitas historis, lalu lakukan deployment canary untuk perubahan tersebut. Catat versi dan kelas hasil, pertahankan verifikator lama sampai migrasi selesai jika perilakunya berbeda.