💡 Contoh lengkap yang berfungsi tersedia di GitHub:
sign-word-with-ml-dsa-certificates-dotnet
Cara Lama Adalah Rencana Proyek
Tanyakan apa yang dibutuhkan untuk membuat penandatanganan dokumen menjadi post‑kuantum dan Anda akan mendapatkan peta jalan: mengevaluasi algoritma, memilih pustaka, menulis lapisan abstraksi di atas kode penandatanganan, merencanakan periode penandatanganan ganda, menganggarkan satu kuartal.
Sebagian besar hal itu masih berlaku untuk sisi organisasi — pengadaan sertifikat, kebijakan, dukungan validator. Sisi kode ternyata lebih kecil daripada yang disarankan peta jalan, dan itu penting untuk diketahui sebelum siapa pun menganggarkan satu kuartal untuknya.
Penandatanganan ML‑DSA adalah kemampuan GroupDocs.Signature untuk .NET yang menandatangani dokumen Word dengan sertifikat berbasis FIPS 204, standar tanda tangan post‑kuantum NIST. Fitur ini muncul pada versi 26.9, dan dari sudut pandang kode pemanggil ia hanyalah file PFX yang berbeda.
Ada Cara yang Lebih Baik
Berikut seluruh perubahan kode:
using var signature = new Signature(sourcePath);
var options = new DigitalSignOptions(pfxPath)
{
Password = certificatePassword
};
SignResult result = signature.Sign(outputPath, options);
Itu adalah pemanggilan yang sama digunakan untuk sertifikat RSA. Algoritma merupakan properti dari sertifikat, jadi tidak ada opsi yang memilihnya, tidak diperlukan lapisan abstraksi, dan tidak muncul jalur kode kedua untuk periode transisi. Arahkan DigitalSignOptions ke sebuah PFX ML‑DSA dan output‑nya adalah tanda tangan ML‑DSA.
Membaca kembali sertifikat dari hasil sangat berguna ketika beberapa sertifikat sedang dipakai:
var created = result.Succeeded.OfType<DigitalSignature>().FirstOrDefault();
return created?.Certificate?.Subject ?? "(no certificate returned)";
Memilih Tingkat, Dengan Angka Alih‑alih Opini
ML‑DSA hadir dalam tiga set parameter, yang memetakan ke kategori keamanan NIST 2, 3, dan 5. Semakin kuat berarti semakin besar — baik kunci maupun tanda tangan — dan cara yang masuk akal untuk memutuskan adalah menandatangani dokumen Anda sendiri tiga kali dan melihat:
var levels = new Dictionary<string, string>
{
["ML-DSA-44"] = MlDsa44Pfx,
["ML-DSA-65"] = MlDsa65Pfx,
["ML-DSA-87"] = MlDsa87Pfx
};
Contoh menulis satu salinan yang ditandatangani per tingkat dan mencatat setiap ukuran, sehingga trade‑off menjadi pengukuran bukan tabel dari spesifikasi. Untuk satu kontrak perbedaannya tidak signifikan; untuk arsip berisi beberapa juta dokumen yang ditandatangani, ini menjadi pertanyaan kapasitas yang layak ditanyakan sebelum menstandarkan pada tingkat tertinggi.
ML‑DSA‑65 adalah nilai default yang wajar ketika tidak ada kebijakan yang menentukan. Profil seperti CNSA 2.0 secara eksplisit menyebut ML‑DSA‑87, dan ML‑DSA‑44 masuk akal hanya ketika ukuran lebih penting daripada margin.
Verifikasi Hanya Membutuhkan Sertifikat Publik
Cerita distribusi tidak berubah dari RSA, yang merupakan berita baik kedua:
var options = new DigitalVerifyOptions(certificatePath);
if (password != null)
{
options.Password = password;
}
VerificationResult result = signature.Verify(options);
Seorang penerima hanya membutuhkan .cer penandatangan dan tidak ada yang lain. Hasilnya valid hanya ketika tanda tangan cocok dengan konten dan sertifikat cocok berdasarkan nomor seri serta sidik jari, sehingga dokumen yang ditandatangani oleh pihak lain gagal pemeriksaan — yang dibuktikan contoh dengan menjalankan verifikasi dua kali, sekali dengan sertifikat yang benar dan sekali dengan sertifikat orang lain.
Sebanding: Diharapkan vs. Aktual
| Apa yang diasumsikan oleh rencana migrasi | Apa yang sebenarnya dibutuhkan oleh 26.9 | |
|---|---|---|
| Perubahan kode | lapisan abstraksi atas penandatanganan | jalur PFX yang berbeda |
| Permukaan API | metode post‑kuantum baru | DigitalSignOptions, tidak berubah |
| Pemilihan tingkat | konfigurasi perpustakaan | sertifikat mana yang Anda muat |
| Verifikasi | alat baru untuk penerima | .cer publik penandatangan |
| Pekerjaan platform | penanganan kunci per‑OS | tidak ada — perpustakaan kembali secara internal |
| Cakupan format | semua format | hanya format Word, untuk saat ini |
Baris terakhir adalah yang membatasi perencanaan, dan mengarah pada bagian jujur artikel ini.
Apa yang Belum Berfungsi
Dua batasan, keduanya penting diketahui sebelum Anda menjanjikan apa pun.
Cakupan format masih hanya Word pada 26.9 — DOCX, DOC, ODT, dan seluruh keluarga Word. PDF, spreadsheet, serta presentasi tidak dapat ditandatangani dengan ML‑DSA. Untuk pipeline yang mengutamakan PDF, rilis ini lebih cocok untuk prototyping dan pengukuran daripada migrasi.
Dukungan validator adalah batasan lainnya. Belum ada pengenal XML‑DSig standar untuk ML‑DSA, sehingga Microsoft Word mungkin tidak melaporkan tanda tangan sebagai valid meskipun secara kriptografis sah dan diverifikasi dengan benar melalui API. Itu merupakan kesenjangan standar, bukan cacat, dan berarti verifikasi harus berada di dalam kode Anda, bukan pada reviewer yang membuka berkas dan melihat banner.
Ada juga detail platform yang tidak memerlukan tindakan: .NET tidak dapat membaca kunci ML‑DSA di semua tempat, termasuk Linux pada .NET 8. Di mana tidak dapat, GroupDocs.Signature membaca sertifikat melalui mesin Word, sehingga build yang sama dapat dijalankan di laptop pengembang dan kontainer Linux tanpa kode kondisional.
Apakah layak dilakukan sekarang, mengingat batasan tersebut?
Ya, untuk dua alasan yang tidak berhubungan dengan kode. Pengadaan sertifikat lambat — CA publik masih meluncurkan penerbitan ML‑DSA — sehingga pekerjaan sisi organisasi mendapat manfaat dari memulai lebih awal. Dan “bisakah kami menghasilkan tanda tangan post‑kuantum hari ini” adalah pertanyaan yang mulai diajukan tim kepatuhan; dapat menjawabnya dengan dokumen yang ditandatangani daripada sekadar rencana layak untuk sore itu.
Apa yang Sebenarnya Dibuktikan oleh Contoh
Empat metode, dijalankan berurutan, dengan kode keluar terkait hasil. Ia menandatangani kontrak dengan ML‑DSA‑65 dan mencetak subjek sertifikat yang digunakan. Ia menandatangani kontrak yang sama pada ketiga tingkat dan mencetak ukuran yang dihasilkan. Ia memverifikasi berkas yang ditandatangani dua kali — sekali dengan sertifikat publik penandatangan, mengharapkan sukses, dan sekali dengan sertifikat penandatangan lain, mengharapkan gagal. Kemudian ia mencantumkan tanda tangan digital yang ditemukan pada output.
Verifikasi kedua adalah yang layak disalin. Rutinitas yang hanya pernah ditunjukkan dengan input valid tidak memberi tahu apa‑apa tentang apakah ia akan menolak input tidak valid, dan untuk tanda tangan itulah seluruh pertanyaannya.
Contoh Dunia Nyata: Kontrak Tiga Puluh Tahun
Arsip dengan retensi panjang adalah tempat hal ini tidak lagi bersifat teoretis. Kontrak yang ditandatangani hari ini dan disimpan selama tiga puluh tahun harus tetap dapat diverifikasi melintasi apa pun yang terjadi pada kriptografi dalam jangka waktu itu, dan “panen sekarang, dekripsi nanti” adalah model ancaman yang terdokumentasi untuk materi semacam itu.
Untuk arsip seperti itu, langkah praktis hari ini adalah jalur ganda: tetap gunakan RSA untuk format yang belum dicakup ML‑DSA, mulailah menandatangani output Word dengan ML‑DSA‑65 atau 87, dan catat algoritma yang digunakan per dokumen sehingga audit di masa depan dapat membedakannya tanpa membuka berkas.
Satu Hal yang Perlu Diperbaiki dalam Contoh Sebelum Menyalinnya
Repositori menyertakan sertifikat ML‑DSA yang ditandatangani sendiri sehingga demonstrasi dapat dijalankan langsung, yang berarti empat file PFX dan kata sandi yang ditulis keras berada di documents/. Untuk sertifikat uji yang hanya berlaku di dalam contoh itu, itu sudah cukup.
Namun itu bukan pola yang harus dibawa ke repositori Anda sendiri. Hasilkan sertifikat uji pada waktu berjalan, seperti yang dilakukan contoh certificate‑validity GroupDocs, atau simpan di luar kontrol versi sepenuhnya. Kunci yang dikomitkan sulit dicabut dan cenderung bertahan lebih lama daripada demo yang ditulis untuknya.
Kesimpulan
Bagian paling mahal dari migrasi post‑kuantum adalah sertifikat, kebijakan, dan validator. Kode, setidaknya untuk dokumen Word di .NET, hanyalah PFX yang berbeda dan pemanggilan DigitalSignOptions yang sama. Kloning contoh, arahkan ke salah satu kontrak Anda, dan Anda akan memiliki tiga berkas yang ditandatangani, dua hasil verifikasi, serta perbandingan ukuran dalam beberapa menit — yang merupakan dasar yang lebih baik untuk rencana migrasi daripada sekadar perkiraan.