💡 ตัวอย่างทำงานเต็มที่พร้อมให้ใช้งานบน GitHub:
sign-word-with-ml-dsa-certificates-dotnet
วิธีเดิมเป็นแผนโครงการ
ถามว่าอะไรบ้างที่ต้องทำเพื่อทำให้การลงนามเอกสารเป็นแบบหลังควอนตัมและคุณจะได้แผนงาน: ประเมินอัลกอริทึม, เลือกไลบรารี, เขียนชั้นนามธรรมเหนือโค้ดการลงนาม, วางแผนช่วงเวลาการลงนามคู่, จัดสรรงบประมาณไตรมาสหนึ่ง
ส่วนใหญ่ของสิ่งเหล่านี้ยังคงเป็นความจริงสำหรับด้านองค์กร — การจัดหาใบรับรอง, นโยบาย, การสนับสนุน validator. ส่วนของโค้ดกลับเล็กกว่าที่แผนงานบ่งบอกและนั่นเป็นข้อมูลที่ควรรู้ก่อนที่ใครจะจัดสรรงบประมาณไตรมาสหนึ่งให้กับมัน
การลงนาม ML‑DSA เป็นความสามารถของ GroupDocs.Signature สำหรับ .NET ที่ลงนามเอกสาร Word ด้วยใบรับรองตาม FIPS 204, มาตรฐานลายเซ็นหลังควอนตัมของ NIST. มันมาถึงในเวอร์ชัน 26.9 และจากมุมมองของโค้ดที่เรียกใช้ มันเป็นไฟล์ PFX ที่แตกต่างกัน
มีวิธีที่ดีกว่า
นี่คือการเปลี่ยนแปลงโค้ดทั้งหมด:
using var signature = new Signature(sourcePath);
var options = new DigitalSignOptions(pfxPath)
{
Password = certificatePassword
};
SignResult result = signature.Sign(outputPath, options);
นี่คือการเรียกใช้เดียวกันที่ใช้กับใบรับรอง RSA. อัลกอริทึมเป็นคุณสมบัติของใบรับรอง, ดังนั้นไม่มีตัวเลือกใดเลือกมัน, ไม่ต้องมีชั้นนามธรรม, และไม่มีเส้นทางโค้ดที่สองปรากฏสำหรับช่วงการเปลี่ยนแปลง. เพียงชี้ DigitalSignOptions ไปที่ PFX ของ ML‑DSA แล้วผลลัพธ์ก็เป็นลายเซ็น ML‑DSA
การอ่านใบรับรองกลับจากผลลัพธ์เป็นสิ่งที่ควรทำขณะที่มีหลายใบรับรองกำลังใช้งาน:
var created = result.Succeeded.OfType<DigitalSignature>().FirstOrDefault();
return created?.Certificate?.Subject ?? "(no certificate returned)";
เลือกระดับด้วยตัวเลขแทนความคิดเห็น
ML‑DSA มีสามชุดพารามิเตอร์, สอดคล้องกับหมวดความปลอดภัยของ NIST ระดับ 2, 3 และ 5. ระดับที่แข็งแรงกว่าหมายถึงขนาดใหญ่กว่า — ทั้งคีย์และลายเซ็น — และวิธีที่สมเหตุสมผลในการตัดสินใจคือการลงนามเอกสารของคุณเองสามครั้งและดูผล:
var levels = new Dictionary<string, string>
{
["ML-DSA-44"] = MlDsa44Pfx,
["ML-DSA-65"] = MlDsa65Pfx,
["ML-DSA-87"] = MlDsa87Pfx
};
ตัวอย่างจะเขียนสำเนาที่ลงนามหนึ่งไฟล์ต่อระดับและบันทึกขนาดของแต่ละไฟล์, ดังนั้นการตัดสินใจเป็นการวัดผลแทนการอ้างอิงตารางจากสเปค. สำหรับสัญญาเดียว ความแตกต่างอาจไม่เด่นชัด; แต่สำหรับคลังเอกสารหลายล้านไฟล์ที่ลงนามแล้ว มันเป็นคำถามเรื่องความจุที่ควรถามก่อนที่จะมาตรฐานระดับสูงสุด
ML‑DSA‑65 เป็นค่าเริ่มต้นที่สมเหตุสมผลเมื่อไม่มีนโยบายกำหนดไว้. โปรไฟล์เช่น CNSA 2.0 ระบุ ML‑DSA‑87 อย่างชัดเจน, และ ML‑DSA‑44 มีเหตุผลเฉพาะเมื่อขนาดสำคัญกว่าขอบเขต
การตรวจสอบต้องใช้เพียงใบรับรองสาธารณะ
เรื่องการกระจายยังคงเหมือนกับ RSA, ซึ่งเป็นข่าวดีข้อที่สอง:
var options = new DigitalVerifyOptions(certificatePath);
if (password != null)
{
options.Password = password;
}
VerificationResult result = signature.Verify(options);
ผู้รับต้องการไฟล์ .cer ของผู้ลงนามและไม่มีอะไรอื่น. ผลลัพธ์จะเป็น valid ก็ต่อเมื่อลายเซ็นตรงกับเนื้อหาและใบรับรองตรงกันตามหมายเลขซีเรียลและ thumbprint, ดังนั้นเอกสารที่ลงนามโดยฝ่ายอื่นจะล้มเหลวในการตรวจสอบ — ซึ่งตัวอย่างพิสูจน์โดยการรันการตรวจสอบสองครั้ง, ครั้งหนึ่งด้วยใบรับรองที่ถูกต้องและอีกครั้งด้วยใบรับรองของคนอื่น
ข้างเคียง: คาดหวัง vs. ผลลัพธ์จริง
| สิ่งที่แผนการย้ายระบบสมมติ | สิ่งที่ 26.9 ต้องการจริง | |
|---|---|---|
| การเปลี่ยนแปลงโค้ด | ชั้นนามธรรมเหนือการลงนาม | เส้นทาง PFX ที่แตกต่าง |
| พื้นผิว API | วิธีการหลังควอนตัมใหม่ | DigitalSignOptions, ไม่เปลี่ยน |
| การเลือกระดับ | การกำหนดค่าของไลบรารี | ใบรับรองที่คุณโหลด |
| การตรวจสอบ | เครื่องมือใหม่สำหรับผู้รับ | .cer สาธารณะของผู้ลงนาม |
| งานบนแพลตฟอร์ม | การจัดการคีย์ตาม OS | ไม่มี — ไลบรารีจัดการภายใน |
| ความครอบคลุมฟอร์แมต | ทุกฟอร์แมต | ฟอร์แมต Word เท่านั้น (สำหรับตอนนี้) |
แถวสุดท้ายเป็นแถวที่จำกัดการวางแผนและนำไปสู่ส่วนที่ซื่อสัตย์ของบทความนี้
สิ่งที่ยังทำงานไม่ได้
สองข้อจำกัดที่ควรรู้ก่อนสัญญาอะไร
ความครอบคลุมฟอร์แมตในเวอร์ชัน 26.9 มีแค่ Word — DOCX, DOC, ODT และตระกูล Word อื่น ๆ. PDF, สเปรดชีตและพรีเซนเทชันไม่สามารถลงนามด้วย ML‑DSA ได้. สำหรับสายงานที่เริ่มจาก PDF รุ่นนี้เหมาะสำหรับการทำต้นแบบและวัดผลมากกว่าการย้ายระบบ
การสนับสนุน validator เป็นอีกข้อ. ยังไม่มีตัวระบุ XML‑DSig มาตรฐานสำหรับ ML‑DSA, ดังนั้น Microsoft Word อาจไม่รายงานลายเซ็นว่าเป็น valid แม้ว่ามันจะถูกต้องตามหลักการเข้ารหัสและตรวจสอบได้อย่างถูกต้องผ่าน API. นี่เป็นช่องว่างของมาตรฐานไม่ใช่ข้อบกพร่อง, และหมายความว่าการตรวจสอบต้องทำในโค้ดของคุณเองแทนที่จะเป็นผู้ตรวจที่เปิดไฟล์และดูแบนเนอร์
นอกจากนี้ยังมีรายละเอียดของแพลตฟอร์มที่ไม่ต้องทำอะไร: .NET ไม่สามารถอ่านคีย์ ML‑DSA ได้ทุกที่, รวมถึง Linux บน .NET 8. เมื่อไม่สามารถอ่านได้, GroupDocs.Signature จะอ่านใบรับรองผ่านเอนจินของ Word แทน, ดังนั้นการสร้างเดียวกันสามารถทำงานบนแล็ปท็อปของนักพัฒนาและคอนเทนเนอร์ Linux ได้โดยไม่ต้องเขียนโค้ดเงื่อนไข
คุ้มค่าที่จะทำตอนนี้หรือไม่, เมื่อพิจารณาข้อจำกัดเหล่านี้?
ใช่, ด้วยสองเหตุผลที่ไม่เกี่ยวกับโค้ด. การจัดหาใบรับรองใช้เวลานาน — CA สาธารณะยังค่อย ๆ ปล่อยใบรับรอง ML‑DSA — ดังนั้นงานด้านองค์กรจะได้ประโยชน์จากการเริ่มต้นแต่เนิ่น ๆ. และ “เราสามารถสร้างลายเซ็นหลังควอนตัมได้วันนี้หรือไม่” เป็นคำถามที่ทีมคอมพลายเริ่มถาม; การตอบด้วยเอกสารที่ลงนามแล้วแทนแผนเป็นสิ่งที่คุ้มค่ากับบ่ายหนึ่งของเวลา
สิ่งที่ตัวอย่างพิสูจน์จริง ๆ
สี่วิธี, ทำตามลำดับ, โดยรหัสออก (exit code) เชื่อมกับผลลัพธ์. มันลงนามสัญญาด้วย ML‑DSA‑65 และพิมพ์ subject ของใบรับรองที่ใช้. มันลงนามสัญญาเดียวกันในสามระดับและพิมพ์ขนาดที่ได้. มันตรวจสอบไฟล์ที่ลงนามสองครั้ง — ครั้งหนึ่งด้วยใบรับรองสาธารณะของผู้ลงนาม (คาดว่าจะสำเร็จ) และอีกครั้งด้วยใบรับรองของผู้ลงนามคนอื่น (คาดว่าจะล้มเหลว). จากนั้นจะแสดงลายเซ็นดิจิทัลที่พบในไฟล์ผลลัพธ์
การตรวจสอบครั้งที่สองเป็นส่วนที่ควรคัดลอก. รูทีนที่เคยแสดงแค่อินพุตที่ถูกต้องไม่ได้บอกอะไรเกี่ยวกับการปฏิเสธอินพุตที่ไม่ถูกต้อง, และสำหรับลายเซ็น นั่นคือคำถามทั้งหมด
ตัวอย่างจากโลกจริง: สัญญา 30 ปี
คลังเก็บระยะยาวเป็นที่ที่แนวคิดนี้หยุดเป็นทฤษฎี. สัญญาที่ลงนามวันนี้และเก็บไว้เป็นเวลา 30 ปีต้องสามารถตรวจสอบได้ตลอดช่วงเวลาที่คริปโตกราฟีเปลี่ยนแปลง, และ “เก็บข้อมูลตอนนี้, ถอดรหัสภายหลัง” เป็นโมเดลภัยคุกคามที่บันทึกไว้สำหรับวัสดุประเภทนี้โดยเฉพาะ
สำหรับคลังเช่นนั้น การดำเนินการที่เป็นประโยชน์ในวันนี้คือการทำสองเส้นทาง: ใช้ RSA สำหรับฟอร์แมตที่ ML‑DSA ยังไม่ครอบคลุม, เริ่มลงนามผลลัพธ์ Word ด้วย ML‑DSA‑65 หรือ 87, และบันทึกว่าอัลกอริทึมใดใช้กับแต่ละเอกสารเพื่อให้การตรวจสอบในอนาคตสามารถแยกแยะได้โดยไม่ต้องเปิดไฟล์
สิ่งหนึ่งที่ต้องแก้ในตัวอย่างก่อนคัดลอก
ที่เก็บโค้ดมาพร้อมกับใบรับรอง ML‑DSA ที่เซ็นด้วยตนเองเพื่อให้การสาธิตทำงานได้ทันที, ซึ่งหมายถึงไฟล์ PFX สี่ไฟล์และรหัสผ่านที่กำหนดไว้ใน documents/. สำหรับใบรับรองทดสอบที่ใช้ครั้งเดียวและมีอายุแค่ภายในตัวอย่างนั้นก็พอใช้
แต่ไม่ควรนำรูปแบบนี้ไปใช้ในที่เก็บของคุณเอง. ควรสร้างใบรับรองทดสอบในเวลารันแทน, เช่นเดียวกับตัวอย่าง certificate‑validity ของ GroupDocs, หรือเก็บไว้ไกลออกจากการควบคุมเวอร์ชัน. คีย์ที่คอมมิตไว้ยากต่อการเพิกถอนและมักอยู่ได้นานกว่าการสาธิตที่เขียนไว้
สรุป
ส่วนที่มีค่าใช้จ่ายสูงของการย้ายระบบหลังควอนตัมคือใบรับรอง, นโยบายและ validator. ส่วนของโค้ด, อย่างน้อยสำหรับเอกสาร Word ใน .NET, คือการใช้ PFX ที่แตกต่างและการเรียก DigitalSignOptions เดียวกัน. คัดลอกตัวอย่าง, ชี้ไปที่สัญญาของคุณเอง, แล้วคุณจะได้ไฟล์ที่ลงนามสามไฟล์, ผลการตรวจสอบสองครั้งและการเปรียบเทียบขนาดในไม่กี่นาที — ซึ่งเป็นฐานที่ดีกว่าสำหรับแผนการย้ายระบบมากกว่าการประมาณค่า