NEXUS-Q v4.1.2: công cụ mật mã hậu lượng tử viết bằng Rust

NEXUS-Q banner

Một dự án mã nguồn mở tên NEXUS-Q vừa phát hành phiên bản v4.1.2, được giới thiệu là engine mật mã hậu lượng tử (post-quantum cryptography) viết bằng Rust, dùng để bảo vệ dữ liệu, khóa và danh tính. Điểm đáng chú ý không nằm ở thuật toán — vốn đều là chuẩn đã công bố — mà ở phần kỹ thuật vận hành xung quanh: quản lý vòng đời khóa, kiểm soát chính sách, nhật ký kiểm toán và quy trình phát hành có thể kiểm chứng.

Trạng thái dự án: "Audit-Ready" chứ không phải "Production-Ready"

Theo tài liệu dự án (cập nhật ngày 28/10/2026), NEXUS-Q v4.1.2 là bản phát hành hiện hành, được gọi là "Audit-Ready Release". Dự án nêu rõ ba giới hạn:

• Không tuyên bố sẵn sàng cho môi trường production.
• Không có chứng nhận FIPS.
• Chưa hoàn tất kiểm toán độc lập bên ngoài.

Bên cạnh đó, dự án còn lưu ý rằng việc một gói xuất hiện trên các registry (crates.io, PyPI, npm, Maven Central, NuGet…) chỉ phản ánh kênh phân phối, không phải bằng chứng về nguồn gốc bản dựng (build provenance) cho mọi hệ sinh thái.

Trạng thái CI pipeline

Những gì NEXUS-Q cung cấp

Dự án tách phần lõi mật mã khỏi các lớp giao diện:

• Mã hóa có xác thực cho tệp và luồng dữ liệu, dùng envelope encryption (format F-02).
• Quản lý vòng đời khóa đầy đủ: sinh khóa, luân chuyển (rotation), thu hồi và hủy.
• Chữ ký số và thông tin xác thực có thể kiểm chứng (verifiable credentials).
• Vault mã hóa (format F-01) với cơ chế ghi nguyên tử (atomic writes).
• Policy engine mặc định từ chối (deny-by-default).
• Audit log xác thực bằng HMAC có neo chống quay lui (rollback anchoring).
• Xóa bộ nhớ an toàn (zeroization) khi không còn cần đến bí mật.

Về giao diện, dự án cung cấp thư viện Rust, CLI, server HTTP có xác thực, C ABI và bộ SDK cho nhiều ngôn ngữ: Dart, .NET, Go, Java, Kotlin, PHP, Ruby, Swift và TypeScript/Node.js. Gói Python là extension module dựng bằng PyO3, hiện chỉ có sdist trên PyPI chứ chưa có wheel theo nền tảng.

Thuật toán: chỉ dùng chuẩn, không tự chế

NEXUS-Q nhấn mạnh nguyên tắc không tự phát minh mật mã. Các primitive được triển khai gồm:

• Sinh số ngẫu nhiên: CSPRNG của hệ điều hành, hỗ trợ TRNG kèm kiểm tra sức khỏe và trộn nguồn.
• Băm: SHA-2, SHA-3.
• KDF: Argon2id, HKDF.
• AEAD: AES-256-GCM, ChaCha20-Poly1305.
• KEM: ML-KEM-768, ML-KEM-1024, kết hợp lai (hybrid) với X25519.
• Chữ ký: Ed25519, ML-DSA-65, SLH-DSA-SHAKE-128f.

Đường triển khai mặc định là RustCrypto. Backend native ML-KEM/ML-DSA là tùy chọn (opt-in), nằm sau feature native-backend và vẫn mang trạng thái thử nghiệm, chưa được kiểm toán độc lập.

Trạng thái native runtime

Hiệu năng: con số có ngữ cảnh, không phải lời hứa

Phần benchmark của dự án khá minh bạch về giới hạn. Trong lần đo cục bộ ngày 21/10/2026 trên máy Intel Core i3-N305, backend native tùy chọn so với đối thủ tốt nhất theo từng phép toán (dùng chung RNG của AWS-LC) cho kết quả: 6/9 phép toán nhanh hơn ở cả trung vị (median) và p95; ba phép còn lại gần tương đương.

Đáng chú ý hơn là kết quả trên CI chính thức của bản v4.1.0 (19/10/2026) trên runner AMD EPYC 7763, với 3.000 mẫu mỗi phép toán cho mỗi bản triển khai:

• ML-KEM-768 keygen: 12,90 µs so với 12,33 µs của AWS-LC (tỷ lệ 1,05×).
• ML-DSA-65 sign: 83,22 µs so với 96,57 µs (0,86×) — nhanh hơn đối thủ.
• ML-KEM-1024 decaps: 22,01 µs so với 22,19 µs (0,99×).

Dự án không đưa ra điểm tổng hợp (composite score) và cũng không tự nhận là dẫn đầu hiệu năng toàn cầu.

Những điểm cần lưu ý

Dự án thẳng thắn liệt kê những gì chưa đạt được: kiểm toán độc lập, chứng nhận FIPS 140-3 hoặc Common Criteria, xác minh hình thức (formal verification), khẳng định sẵn sàng production, hay cách ly phần cứng từ backend phần mềm mặc định.

Một ngoại lệ đáng chú ý là cảnh báo phụ thuộc RUSTSEC-2023-0071 liên quan tới thư viện rsa vẫn còn trong cấu hình audit và deny.toml. Các lỗ hổng nghi ngờ được yêu cầu báo cáo riêng tư qua GitHub Security Advisories.

Góc nhìn

Với kỹ sư Việt Nam đang lên kế hoạch chuyển dịch sang mật mã hậu lượng tử, NEXUS-Q là một mẫu tham khảo hữu ích về quy trình kỹ thuật hơn là một sản phẩm để triển khai ngay. Cách dự án tách lõi mật mã khỏi CLI và SDK, ghi rõ ranh giới thị hại (threat model), phân biệt "có trên registry" với "đã được kiểm chứng", và công khai cả những phép toán kém hơn đối thủ là thực hành nên học theo khi xây hệ thống bảo mật nội bộ.

Tuy nhiên, trạng thái "chưa kiểm toán độc lập, chưa chứng nhận FIPS" là rào cản lớn với các hệ thống thuộc diện phải tuân thủ chặt chẽ. Với backend native còn thử nghiệm và đường mặc định vẫn là RustCrypto, đội ngũ kỹ thuật nên coi đây là môi trường để thử nghiệm, đo đạc và đánh giá — không phải thứ thay thế cho chứng nhận bảo mật đối với dữ liệu thật của khách hàng.