💡 Ví dụ hoạt động đầy đủ có sẵn trên GitHub:
sign-word-with-ml-dsa-certificates-dotnet

Cách Cũ Là Kế Hoạch Dự Án

Hỏi những gì cần thiết để làm cho việc ký tài liệu trở nên hậu lượng tử và bạn sẽ nhận được một lộ trình: đánh giá các thuật toán, chọn một thư viện, viết lớp trừu tượng cho mã ký, lên kế hoạch giai đoạn ký kép, dự trù ngân sách một quý.

Phần lớn những điều đó vẫn đúng đối với nửa tổ chức - mua chứng chỉ, chính sách, hỗ trợ trình xác thực. Phần mã lại nhỏ hơn so với những gì lộ trình gợi ý, và điều này đáng biết trước khi ai đó dự trù ngân sách một quý cho nó.

Ký ML-DSA là một khả năng của GroupDocs.Signature cho .NET cho phép ký tài liệu Word bằng chứng chỉ dựa trên FIPS 204, tiêu chuẩn chữ ký hậu lượng tử của NIST. Nó xuất hiện trong phiên bản 26.9, và từ góc nhìn của mã gọi, nó là một tệp PFX khác.

Có Một Cách Tốt Hơn

Đây là toàn bộ thay đổi mã:

using var signature = new Signature(sourcePath);

var options = new DigitalSignOptions(pfxPath)
{
    Password = certificatePassword
};

SignResult result = signature.Sign(outputPath, options);

Đó là cùng một lời gọi được sử dụng cho chứng chỉ RSA. Thuật toán là thuộc tính của chứng chỉ, vì vậy không có tùy chọn nào để chọn nó, không cần lớp trừu tượng, và không xuất hiện đường dẫn mã thứ hai cho giai đoạn chuyển đổi. Đặt DigitalSignOptions vào một PFX ML-DSA và đầu ra sẽ là một chữ ký ML-DSA.

Đọc lại chứng chỉ từ kết quả là việc đáng làm khi có nhiều chứng chỉ đang được sử dụng:

var created = result.Succeeded.OfType<DigitalSignature>().FirstOrDefault();
return created?.Certificate?.Subject ?? "(no certificate returned)";

Chọn Mức, Với Số Thay Vì Ý Kiến

ML-DSA có ba bộ tham số, tương ứng với các danh mục bảo mật NIST 2, 3 và 5. Mạnh hơn nghĩa là lớn hơn - cả khóa và chữ ký - và cách hợp lý để quyết định là ký tài liệu của bạn ba lần và quan sát:

var levels = new Dictionary<string, string>
{
    ["ML-DSA-44"] = MlDsa44Pfx,
    ["ML-DSA-65"] = MlDsa65Pfx,
    ["ML-DSA-87"] = MlDsa87Pfx
};

Mẫu tạo một bản sao đã ký cho mỗi mức và ghi lại kích thước của mỗi bản, vì vậy sự đánh đổi là một phép đo chứ không phải một bảng từ thông số kỹ thuật. Đối với một hợp đồng duy nhất, sự khác biệt không đáng chú ý; nhưng đối với một kho lưu trữ hàng triệu tài liệu đã ký, đây là câu hỏi về khả năng lưu trữ đáng cân nhắc trước khi chuẩn hoá ở mức cao nhất.

ML-DSA-65 là mặc định hợp lý khi không có chính sách quy định. Các hồ sơ như CNSA 2.0 chỉ rõ ML-DSA-87, và ML-DSA-44 chỉ có ý nghĩa khi kích thước quan trọng hơn độ dư.

Xác Thực Chỉ Cần Chứng Chỉ Công Khai

Câu chuyện phân phối không thay đổi so với RSA, đây là tin tốt thứ hai:

var options = new DigitalVerifyOptions(certificatePath);
if (password != null)
{
    options.Password = password;
}

VerificationResult result = signature.Verify(options);

Người nhận chỉ cần .cer của người ký và không gì khác. Kết quả chỉ hợp lệ khi chữ ký khớp với nội dung và chứng chỉ khớp theo số sê-ri và dấu vân tay, vì vậy tài liệu ký bởi một bên khác sẽ không vượt qua kiểm tra - điều này mẫu chứng minh bằng cách chạy xác thực hai lần, một lần với chứng chỉ đúng và một lần với chứng chỉ của người khác.

So Sánh Song Song: Dự Kiến vs. Thực Tế

Những gì một kế hoạch di chuyển giả định Những gì 26.9 thực sự yêu cầu
Thay đổi mã lớp trừu tượng cho việc ký đường dẫn PFX khác
Giao diện API phương thức hậu lượng tử mới DigitalSignOptions, không thay đổi
Lựa chọn mức cấu hình thư viện chứng chỉ nào bạn tải
Xác thực công cụ mới cho người nhận .cer công khai của người ký
Công việc nền tảng xử lý khóa theo hệ điều hành không - thư viện tự động xử lý nội bộ
Phạm vi định dạng tất cả định dạng chỉ định dạng Word, hiện tại

Dòng cuối cùng là yếu tố hạn chế kế hoạch, và nó dẫn đến phần trung thực của bài viết này.

Những Điều Chưa Hoạt Động

Hai giới hạn, cả hai đều đáng biết trước khi bạn hứa hẹn bất cứ điều gì.

Phạm vi định dạng chỉ hỗ trợ Word trong 26.9 - DOCX, DOC, ODT và các định dạng khác trong họ Word. PDF, bảng tính và bản trình chiếu không thể ký bằng ML-DSA. Đối với quy trình ưu tiên PDF, bản phát hành này chỉ phù hợp cho việc tạo mẫu và đo lường hơn là di chuyển.

Hỗ trợ trình xác thực là vấn đề còn lại. Hiện chưa có định danh XML‑DSig tiêu chuẩn cho ML-DSA, vì vậy Microsoft Word có thể không báo chữ ký là hợp lệ dù nó về mặt mật mã là đúng và xác thực chính xác qua API. Đó là khoảng trống tiêu chuẩn chứ không phải lỗi, và nó có nghĩa là việc xác thực phải được thực hiện trong mã của bạn thay vì người xem mở file và nhìn vào biểu ngữ.

Cũng có một chi tiết nền tảng không cần hành động: .NET không thể đọc khóa ML-DSA ở mọi nơi, bao gồm Linux trên .NET 8. Khi không thể, GroupDocs.Signature sẽ đọc chứng chỉ qua engine Word, vì vậy bản dựng giống nhau có thể chạy trên laptop của nhà phát triển và container Linux mà không cần mã điều kiện.

Có Nên Thực Hiện Ngay Bây Giờ, Khi Xét Đến Những Giới Hạn Đó?

Có, vì hai lý do không liên quan đến mã. Việc mua chứng chỉ chậm - các CA công cộng vẫn đang triển khai phát hành ML-DSA - vì vậy công việc phía tổ chức có lợi khi bắt đầu sớm. Và “chúng ta có thể tạo chữ ký hậu lượng tử hôm nay không” là câu hỏi mà các đội tuân thủ đang bắt đầu đặt ra; khả năng trả lời bằng một tài liệu đã ký thay vì một kế hoạch đáng giá thời gian buổi chiều.

Mẫu Thực Sự Chứng Minh Gì

Bốn phương pháp, chạy theo thứ tự, với mã thoát liên kết với kết quả.
Nó ký hợp đồng bằng ML-DSA-65 và in ra chủ đề của chứng chỉ đã được sử dụng.
Nó ký cùng một hợp đồng ở ba mức và in ra kích thước kết quả.
Nó xác thực tệp đã ký hai lần - một lần với chứng chỉ công khai của người ký, mong đợi thành công, và một lần với chứng chỉ của người ký khác, mong đợi thất bại.
Sau đó nó liệt kê các chữ ký số được tìm thấy trong đầu ra.

Xác thực thứ hai là phần đáng sao chép.
Một quy trình chỉ từng được chứng minh với đầu vào hợp lệ không cho bạn biết liệu nó có từ chối đầu vào không hợp lệ hay không, và đối với chữ ký, đó là toàn bộ câu hỏi.

Ví Dụ Thực Tế: Hợp Đồng Ba Mươi Năm

Các kho lưu trữ dài hạn là nơi vấn đề này không còn là lý thuyết. Một hợp đồng ký hôm nay và được giữ trong ba mươi năm phải vẫn có thể xác thực qua bất kỳ thay đổi nào trong lĩnh vực mật mã trong khoảng thời gian đó, và “thu thập ngay, giải mã sau” là mô hình đe dọa đã được ghi lại cho loại tài liệu này.

Đối với một kho lưu trữ như vậy, bước thực tế hôm nay là song song: giữ RSA cho các định dạng mà ML-DSA chưa hỗ trợ, bắt đầu ký đầu ra Word bằng ML-DSA-65 hoặc 87, và ghi lại thuật toán đã dùng cho mỗi tài liệu để cuộc kiểm toán trong tương lai có thể phân biệt chúng mà không cần mở file.

Một Điều Cần Sửa Trong Mẫu Trước Khi Sao Chép

Kho lưu trữ cung cấp các chứng chỉ ML-DSA tự ký nên bản demo chạy ngay mà không cần cấu hình, nghĩa là có bốn tệp PFX và một mật khẩu được mã cứng nằm trong documents/. Đối với một chứng chỉ thử nghiệm dùng một lần chỉ hợp lệ trong mẫu đó, điều này là ổn.

Đây không phải là mẫu nên mang vào kho của bạn. Thay vào đó, tạo chứng chỉ thử nghiệm tại thời gian chạy, như mẫu certificate‑validity của GroupDocs, hoặc giữ chúng ra khỏi hệ thống kiểm soát phiên bản hoàn toàn. Một khóa đã commit khó thu hồi và thường tồn tại lâu hơn bản demo mà nó được viết cho.

Kết Luận

Các phần tốn kém của việc di chuyển hậu lượng tử là chứng chỉ, chính sách và trình xác thực. Phần mã, ít nhất đối với tài liệu Word trong .NET, chỉ là một PFX khác và cùng một lời gọi DigitalSignOptions. Sao chép mẫu, trỏ nó tới một trong các hợp đồng của bạn, và bạn sẽ có ba tệp đã ký, hai kết quả xác thực và một so sánh kích thước trong vài phút - đây là nền tảng tốt hơn cho kế hoạch di chuyển so với một ước tính.

Tài Nguyên Bổ Sung