💡 Tam çalışan örnek GitHub’da mevcuttur:
sign-word-with-ml-dsa-certificates-dotnet
Eski Yöntem Bir Proje Planıydı
Belge imzalamasını post‑kuantum hâline getirmek için neler gerektiğini sorarsanız bir yol haritası alırsınız: algoritmaları değerlendirin, bir kütüphane seçin, imzalama kodu üzerine bir soyutlama katmanı yazın, çift‑imzalama dönemi planlayın, bir çeyrek bütçelendirin.
Bunların çoğu organizasyon yarısı için hâlâ geçerli – sertifika temini, politika, doğrulayıcı desteği. Kod yarısı ise yol haritasının öngördüğünden daha küçüktür ve bu, birinin ona bir çeyrek ayırmadan önce bilmesi gereken bir şeydir.
ML‑DSA imzalama, .NET için GroupDocs.Signature yeteneği olup, FIPS 204 tabanlı, NIST post‑kuantum imza standardına göre sertifikalarla Word belgelerini imzalar. 26.9 sürümünde geldi ve çağıran kod açısından farklı bir PFX dosyasıdır.
Daha İyi Bir Yol Var
İşte tüm kod değişikliği:
using var signature = new Signature(sourcePath);
var options = new DigitalSignOptions(pfxPath)
{
Password = certificatePassword
};
SignResult result = signature.Sign(outputPath, options);
Bu, RSA sertifikası için kullanılan aynı çağrıdır. Algoritma sertifikanın bir özelliğidir, bu yüzden bir seçenekle seçilmez, bir soyutlama katmanı gerekmez ve geçiş dönemi için ikinci bir kod yolu ortaya çıkmaz. DigitalSignOptions nesnesini bir ML‑DSA PFX dosyasına yönlendirin; çıktı bir ML‑DSA imzası olur.
Sonuçtan sertifikayı geri okumak, birden fazla sertifikanın devrede olduğu durumlarda faydalıdır:
var created = result.Succeeded.OfType<DigitalSignature>().FirstOrDefault();
return created?.Certificate?.Subject ?? "(no certificate returned)";
Seçenekleri Sayılarla, Görüşlerle Değil Belirleme
ML‑DSA üç parametre setiyle gelir ve NIST güvenlik kategorileri 2, 3 ve 5’e karşılık gelir. Daha güçlü olmak, hem anahtarın hem de imzanın daha büyük olması demektir ve mantıklı yol, kendi belgenizi üç kez imzalayıp sonuçlara bakmaktır:
var levels = new Dictionary<string, string>
{
["ML-DSA-44"] = MlDsa44Pfx,
["ML-DSA-65"] = MlDsa65Pfx,
["ML-DSA-87"] = MlDsa87Pfx
};
Örnek, her seviye için bir imzalı kopya yazar ve her birinin boyutunu kaydeder; böylece ödünleşim bir ölçüm olur, bir spesifikasyondan tablo değil. Tek bir sözleşme için fark gözle görülür değildir; ancak birkaç milyon imzalı belge içeren bir arşiv için kapasite sorusu, en yüksek seviyeye standartlaşmadan önce sorulması gereken bir sorudur.
ML‑DSA‑65, hiçbir politikanın bir seviye belirlemediği durumlarda makul varsayılan değerdir. CNSA 2.0 gibi profiller ML‑DSA‑87’yi açıkça adlandırır ve ML‑DSA‑44 yalnızca boyutun marjdan daha önemli olduğu durumlarda mantıklıdır.
Doğrulama Yalnızca Kamu Sertifikasını İster
Dağıtım hikayesi RSA ile aynı kalır; bu da ikinci iyi haberdir:
var options = new DigitalVerifyOptions(certificatePath);
if (password != null)
{
options.Password = password;
}
VerificationResult result = signature.Verify(options);
Alıcı, imzalayanın .cer dosyasına ve başka bir şeye ihtiyaç duymaz. Sonuç, imza içeriğe uyduğunda ve sertifika seri numarası ve parmak iziyle eşleştiğinde geçerlidir; bu yüzden farklı bir taraf tarafından imzalanmış bir belge kontrolü geçemez – örnek bunu iki kez doğrulama yaparak gösterir, bir kez doğru sertifika, bir kez başka birinin sertifikasıyla.
Yan Yana: Beklenen vs. Gerçek
| Bir geçiş planının varsaydığı | 26.9’un gerçekte gerektirdiği | |
|---|---|---|
| Kod değişikliği | imzalama üzerine soyutlama katmanı | farklı bir PFX yolu |
| API yüzeyi | yeni post‑kuantum metodları | DigitalSignOptions, değişmemiş |
| Seviye seçimi | kütüphane yapılandırması | yüklediğiniz sertifika |
| Doğrulama | alıcılar için yeni araçlar | imzalayanın kamu .cer dosyası |
| Platform çalışması | OS‑başına anahtar yönetimi | yok – kütüphane dahili olarak geri döner |
| Format kapsamı | tüm formatlar | şimdilik yalnızca Word formatları |
Son satır planlamayı sınırlayan noktadır ve bu makalenin dürüst kısmına yol açar.
Henüz Çalışmayanlar
İki sınırlama, bir şey vaat etmeden önce bilmeniz gerekenler.
Format kapsamı 26.9’da yalnızca Word – DOCX, DOC, ODT ve Word ailesinin geri kalanları. PDF, elektronik tablolar ve sunumlar ML‑DSA ile imzalanamaz. PDF‑öncelikli bir akış için bu sürüm prototipleme ve ölçüm amaçlıdır, geçiş için değil.
Doğrulayıcı desteği diğer sınırlamadır. ML‑DSA için henüz standart bir XML‑DSig tanımlayıcısı yoktur, bu yüzden Microsoft Word imzayı geçerli olarak raporlamayabilir, ancak kriptografik olarak sağlamdır ve API üzerinden doğru şekilde doğrulanır. Bu bir standart boşluğu, bir hata değildir ve doğrulamanın dosyayı açan inceleyicide değil, kodunuzda yapılması gerektiği anlamına gelir.
Ayrıca, .NET her yerde – Linux üzerindeki .NET 8 dahil – ML‑DSA anahtarlarını okuyamaz. Okuyamadığı yerlerde GroupDocs.Signature, sertifikayı Word motoru aracılığıyla okur; böylece aynı derleme bir geliştirici dizüstü bilgisayarında ve bir Linux konteynerinde koşulsuz kod olmadan çalışır.
Bu Sınırlamalar Göz Önünde Bulundurularak Şimdi Yapmak Değer mi?
Evet, iki sebeple ki bunlar kodla ilgili değil. Sertifika temini yavaştır – kamu CA’ları hâlâ ML‑DSA dağıtımına başlıyor – bu yüzden organizasyon tarafı çalışması erken başlatıldığında fayda sağlar. Ayrıca “bugün post‑kuantum imza üretebilir miyiz?” sorusu uyum ekiplerinin sormaya başladığı bir sorudur; bir plan yerine imzalı bir belgeyle yanıt verebilmek, harcanan öğleden sonranın karşılığını verir.
Örneğin Gerçekte Kanıtladığı Şey
Dört yöntem, sırasıyla çalıştırılır ve çıkış kodu sonuca bağlanır. Sözleşmeyi ML‑DSA‑65 ile imzalar ve kullanılan sertifikanın konusunu (subject) yazdırır. Aynı sözleşmeyi üç seviyede imzalar ve ortaya çıkan boyutları yazdırır. İmzalı dosyayı iki kez doğrular – bir kez imzalayanın kamu sertifikasıyla, başarı beklenir; bir kez başka bir imzalayanın sertifikasıyla, başarısızlık beklenir. Son olarak çıktıda bulunan dijital imzaları listeler.
İkinci doğrulama, kopyalanması gereken kısımdır. Sadece geçerli girdi gösterilmiş bir rutin, geçersiz bir girdiyi reddedip reddetmeyeceği hakkında hiçbir şey söylemez; imzalar için bu tam olarak sorulmak istenen sorudur.
Gerçek Dünya Örneği: Otuz Yıllık Sözleşme
Uzun süreli arşivler, konunun teorik olmaktan çıkıp pratiğe döndüğü yerdir. Bugün imzalanıp otuz yıl saklanacak bir sözleşme, bu süre içinde kriptografinin ne yönde evrileceğine bakılmaksızın doğrulanabilir olmalıdır ve “şimdi topla, sonra deşifre et” tam da bu tür materyaller için belgelenmiş bir tehdit modelidir.
Böyle bir arşiv için bugün uygulanabilecek pratik adım çift‑yolludur: ML‑DSA’nın henüz kapsamadığı formatlar için RSA’yı tutun, Word çıktısını ML‑DSA‑65 ya da 87 ile imzalamaya başlayın ve her belge için hangi algoritmanın kullanıldığını kaydedin; böylece gelecekteki bir denetim dosyaları açmadan algoritmaları ayırt edebilir.
Örneği Kopyalamadan Önce Düzeltmeniz Gereken Tek Şey
Depo, demo amaçlı kutudan çıkar çıkmaz çalışması için kendinden imzalı ML‑DSA sertifikaları içerir; bu da documents/ içinde dört PFX dosyası ve sabit bir şifre olduğu anlamına gelir. Sadece bu örnek içinde geçerli olacak geçici bir test sertifikası için bu uygundur.
Ancak bu, kendi deponuza taşımanız gereken bir model değildir. GroupDocs’un “certificate‑validity” örneği gibi çalışma zamanında test sertifikaları üretin ya da tamamen sürüm kontrolünden dışarıda tutun. Bir anahtarın depoya işlenmesi, iptal edilmesi zor bir durum yaratır ve demoyu ömründen uzun tutar.
Sonuç
Post‑kuantum geçişinin maliyetli parçaları sertifikalar, politika ve doğrulayıcılardır. Kod, en azından .NET’te Word belgeleri için, farklı bir PFX ve aynı DigitalSignOptions çağrısıdır. Örneği klonlayın, kendi sözleşmelerinizden birine yönlendirin; birkaç dakikada üç imzalı dosya, iki doğrulama sonucu ve bir boyut karşılaştırması elde edeceksiniz – bu, bir tahmin yerine geçiş planı için çok daha sağlam bir temeldir.