Chuyển đổi sang Mật mã học hậu lượng tử – Những gì thực sự thay đổi?

Reading Time: 12 minutes

Chuyển đổi sang Mật mã học hậu lượng tử không phải chỉ là thay đổi cấu hình đơn thuần. Đây là ba bài toán chồng lên nhau, tuy nhiên phần lớn đội ngũ kỹ thuật chỉ mới nhìn thấy lớp đầu tiên.

Chuỗi bài viết này tới từ một trong những thành viên của đội ngũ CyStack Canada – Giáo sư, Tiến sĩ Sumit Giri. Đây là những kinh nghiệm cá nhân được ông đúc rút và truyền tải, và được đội ngũ CyStack tại Việt Nam dịch thuật. Bạn có thể xem thêm các nội dung liên quan của ông tại blog cá nhân hoặc khám phá thêm các nội dung trong chuỗi bài này

Trong Phần 1 của loạt bài này, tôi đã trình bày nền tảng toán học của ML-KEM và ML-DSA – các bài toán lưới (lattice) làm cơ sở cho chúng, lý do quá trình chuẩn hóa của NIST kéo dài tám năm, và tại sao mối đe dọa từ máy tính lượng tử đã hiện hữu trước khi một cỗ máy đủ mạnh về mật mã thực sự xuất hiện. Nếu chưa đọc, bài đó giải thích “tại sao”. Bài này nói về “thay đổi gì”.

Gần đây tôi có một buổi thuyết trình tại TASK 2026 về PQC trong thực tiễn. Quá trình chuẩn bị buộc tôi phải vượt ra khỏi việc đọc paper và bắt đầu suy nghĩ nghiêm túc về những gì chuyển đổi thực sự đòi hỏi từ một đội kỹ thuật. Điều tôi nhận ra: phần lớn cách đặt vấn đề trong ngành – “chỉ cần cập nhật cipher suite” – mới chỉ mô tả lớp nông nhất của bài toán.

Bài viết này phân tích ba cấp độ phức tạp khi chuyển đổi sang Mật mã học hậu lượng tử, các thay đổi API cụ thể trong ML-DSA sẽ phá vỡ pipeline ký số hiện tại, và lý do crypto agility là đầu tư hạ tầng chứ không phải cột mốc dự án.

Vấn đề không nằm ở thuật toán mà ở giả định

Phần lớn hệ thống coi thuật toán mật mã là thuộc tính cố định – chọn một lần, đúc vào mã nguồn, chỉ xem lại khi có sự cố. RSA-2048 nằm trong cấu hình TLS. ECDSA P-256 nằm trong pipeline ký mã (code signing). AES-128 nằm trong tầng mã hóa cơ sở dữ liệu. Không ai động đến chúng suốt nhiều năm vì chúng vẫn hoạt động và không có lý do rõ ràng nào để thay đổi.

Chính sự giả định rằng sự ổn định mật mã là một ưu điểm – khiến việc chuyển đổi PQC trở nên khó khăn. Mô hình mối đe dọa (threat model) có hai dòng thời gian vận hành độc lập:

Dòng thời gian thứ nhất là thời điểm xuất hiện máy tính lượng tử đủ năng lực mật mã (CRQC – Cryptographically Relevant Quantum Computer). Các ước tính rất khác nhau. Phần lớn nhà nghiên cứu nghiêm túc đặt mốc từ 10 đến 20 năm. Dòng thời gian này chưa chắc chắn, và đó cũng là điều mọi người tranh cãi.

Dòng thời gian thứ hai là cửa sổ phơi nhiễm dữ liệu. Dòng này không có gì bất định. Hồ sơ y tế có yêu cầu lưu trữ hàng thập kỷ. Thông tin liên lạc quốc phòng được phân mật còn lâu hơn. Hồ sơ kiểm toán tài chính, hợp đồng dài hạn, sở hữu trí tuệ – tất cả đều có thời hạn bảo mật vượt xa mọi ước tính hợp lý về thời điểm CRQC xuất hiện.

Giao điểm hai dòng thời gian này mới là bài toán thực sự. Kẻ tấn công không cần máy tính lượng tử ngay hôm nay. Chúng chỉ cần ghi lại traffic mã hóa của bạn bây giờ rồi chờ đợi. Kiểu tấn công này có tên – Harvest Now, Decrypt Later (Thu thập trước, giải mã sau) – và chính là lý do NSA đưa ra cảnh báo chuyển đổi đầu tiên từ năm 2015, chín năm trước khi NIST công bố bộ chuẩn PQC hoàn chỉnh đầu tiên.

NIST IR 8547, hiện ở dạng bản nháp, đặt ra các mốc chính sách cụ thể: RSA và ECDSA bị loại bỏ dần (deprecated) cho hệ thống mới vào năm 2030 và bị cấm hoàn toàn vào năm 2035. Tháng 1 năm 2026, CISA ban hành hướng dẫn số 14306, yêu cầu các cơ quan liên bang Mỹ chỉ mua sản phẩm hỗ trợ PQC ở những danh mục đã có sẵn giải pháp – dịch vụ đám mây, máy chủ web, trình duyệt và mã hóa thiết bị đầu cuối đều nằm trong danh sách này.

 

Đây không chỉ là câu chuyện chính sách của riêng Mỹ. Trung tâm An ninh mạng Canada (Canadian Centre for Cyber Security) đã công bố lộ trình chuyển đổi PQC cho Chính phủ Canada với các mốc cụ thể tương đương: các bộ ngành liên bang phải xây dựng kế hoạch chuyển đổi PQC ban đầu trước tháng 4 năm 2026, hoàn tất chuyển đổi hệ thống ưu tiên cao trước cuối năm 2031, và hoàn tất toàn bộ hệ thống còn lại trước cuối năm 2035.

Quan điểm của Trung tâm rất rõ ràng – mọi tổ chức quản lý hệ thống CNTT đều phải chuyển đổi để đạt an toàn lượng tử, và PQC chuẩn hóa là con đường được khuyến nghị. Với các bộ ngành liên bang Canada và mọi tổ chức trong chuỗi cung ứng, hạn chót lập kế hoạch không còn xa. Chính là tháng này.

Khung thời gian để bắt đầu lập kế hoạch không phải đang dần khép lại. Với một số loại dữ liệu, thời gian đó dường như đã kết thúc.

Ba tầng phức tạp khi chuyển đổi

Khi chuẩn bị bài thuyết trình, tôi kỳ vọng câu chuyện chuyển đổi sẽ đơn giản: thay tên thuật toán trong cấu hình, biên dịch lại, kiểm thử, xong. Thực tế lại ẩn sâu ba tầng, và phần lớn đội ngũ dừng lại ở tầng đầu tiên.

Tầng 1 – Cấu hình và API (phần dễ)

Với các endpoint TLS chạy OpenSSL 3.5 – phát hành tháng 4 năm 2025, phiên bản đầu tiên tích hợp PQC gốc mà không cần bản vá bên thứ ba. Việc bật trao đổi khóa hậu lượng tử dạng hybrid thực sự chỉ đơn giản là thay đổi cấu hình.

# nginx.conf – bật trao đổi khóa hybrid ML-KEM-768 + X25519
ssl_ecdh_curve X25519MLKEM768:X25519;

Đây là toàn bộ thay đổi cho một máy chủ web. Mã ứng dụng không đổi. Phiên bản giao thức TLS không đổi. Client không hỗ trợ X25519MLKEM768 sẽ tự động fallback về X25519. Đây là điểm khởi đầu đúng cho mọi lộ trình chuyển đổi PQC, và có thể triển khai được ngay hôm nay.

Tương đương với curl:

curl --curves X25519MLKEM768 https://your-server.com

Tầng chiều sâu này quan trọng, nhưng chỉ bao phủ một kịch bản duy nhất: trao đổi khóa TLS tại endpoint hiện đại với phần mềm cập nhật. Càng đào sâu hơn, các cơ chế dần trở nên phức tạp hơn.

Tầng 2 – Luồng dữ liệu và kích thước (Khi ràng buộc thực sự xuất hiện)

Các thuật toán Mật mã học hậu lượng tử tạo ra khóa và chữ ký lớn hơn đáng kể so với thuật toán cổ điển tương đương. Đây là ràng buộc kiến trúc ảnh hưởng đồng thời nhiều tầng hạ tầng.

Thành phần	Cổ điển	PQC	Hệ số
Khóa công khai (X25519 vs ML-KEM-768)	32 byte	1.184 byte	37×
Chữ ký (ECDSA P-256 vs ML-DSA-65)	64 byte	3.309 byte	52×
TLS ClientHello (cổ điển vs hybrid)	~250 byte	~1.600 byte	6×
Chuỗi chứng chỉ TLS (ECDSA vs ML-DSA)	~3 KB	~17 KB	5×

Mỗi con số đều kéo theo hệ quả cụ thể.

ClientHello dài 1.600 byte có thể vượt giới hạn MTU trong môi trường mạng bị ràng buộc, gây phân mảnh IP (IP fragmentation) trước khi phiên TLS được thiết lập. RFC 9242 (IKEv2 Intermediate Exchange) ra đời chính vì vấn đề này xuất hiện khi triển khai VPN với PQ key share.

Khóa công khai ML-KEM-768 dài 1.184 byte vượt xa dung lượng bộ đệm (buffer) của phần lớn module bảo mật phần cứng (HSM) hiện tại. HSM được thiết kế cho khóa ECC 32–64 byte. Hầu hết cần nâng cấp firmware hoặc phần cứng để xử lý tài liệu PQ – và với một số thiết bị cũ, lộ trình nâng cấp hiện không tồn tại. Đây là ràng buộc phổ biến nhất mà tôi nghe từ các khách hàng đang thực hiện kế hoạch chuyển đổi.

Chuỗi chứng chỉ ML-DSA nặng 17 KB hiện đang được các nhà khoa học xử lý. Nhóm làm việc TLS của IETF đang thảo luận các cơ chế nén và loại bỏ chứng chỉ (certificate compression and suppression). Cho đến khi các cơ chế này được triển khai rộng rãi, chứng chỉ PQ vẫn tạo ra chi phí phụ trội đáng kể cho mỗi kết nối mà nén cổ điển không thể bù đắp hoàn toàn.

Tầng 3 – Loại ứng dụng (Một thuật toán không phù hợp cho tất cả)

Thuật toán phù hợp phụ thuộc vào hệ thống. Không phải mọi tải công việc (workload) đều nên dùng chung một thuật toán PQC, tương tự không phải mọi tải công việc đều dùng chung một mật mã đối xứng (symmetric cipher)

Loại hệ thống	KEM	Chữ ký	Ghi chú
Máy chủ web / API gateway	X25519-ML-KEM-768 (hybrid)	ML-DSA-65	Bắt đầu từ đây
Ký mã / firmware	n/a	SLH-DSA-128s hoặc LMS	Vòng đời dài, tần suất thấp
IoT bị ràng buộc tài nguyên	ML-KEM-512	ML-DSA-44	Kiểm tra chịu tải RAM/flash trước
VPN / IKEv2	ML-KEM qua RFC 9370	ML-DSA	Triển khai được ngay
Thời gian thực / độ trễ thấp	ML-KEM-768	Tránh SLH-DSA	Đo được benchmark end-to-end

SLH-DSA (SPHINCS+) là một trường hợp rất đặc biệt: khóa công khai chỉ chiếm 32 byte – tưởng như rất phù hợp. Nhưng thuật toán này có chữ ký dài đến 7.856 byte và tốc độ ký chỉ khoảng 90 thao tác/giây. Điều này phù hợp tuyệt vời cho các tác vụ ký tần suất thấp, vòng đời dài: chứng chỉ CA gốc, neo tin cậy firmware (firmware trust anchor), ký phát hành phần mềm. Tuy nhiên, giải pháp lại không phù hợp cho bất kỳ hệ thống nào yêu cầu ký với tần suất cao, như chứng chỉ TLS trong PKI bận rộn hay ký yêu cầu API trong kiến trúc microservice.

API của ML-DSA thay đổi và pipeline ký số PQC bị phá vỡ

Đây là phần gây bất ngờ nhiều nhất cho các kỹ sư từng nghe rằng chuyển đổi sang Mật mã hậu lượng tử đơn thuần là thay đổi cấu hình. Chuyển từ ECDSA sang ML-DSA đòi hỏi cập nhật mọi điểm gọi hàm ký (signing call site) trong mã nguồn. Khi kỹ sư bỏ sót, lỗi lặng (silent failure) sẽ xuất hiện, khiến cho các kỹ sư không lần được ra lỗi nằm ở đâu.

Thay đổi giao diện (interface) rất cụ thể. Hàm ký ECDSA nhận hai đối số: thông điệp (message) và khóa riêng (private key). Hàm ký ML-DSA nhận ba đối số: thông điệp, khóa riêng, và một tham số bắt buộc mới – chuỗi ngữ cảnh (context string).

# Hai đối số của ECDSA
signature = ecdsa_sign(message, private_key)
# Đầu ra: 64 byte, bất biến – cùng message luôn cho ra cùng chữ ký

# Ba đối số của ML-DSA, context string là tham số mới và bắt buộc
signature = mldsa_sign(message, private_key, context_string)
# Đầu ra: 3.309 byte (ML-DSA-65), luôn luôn có sự biến động

Chuỗi ngữ cảnh dài tối đa 255 byte chưa từng có tiền lệ, trong bất kỳ lược đồ cổ điển nào. Các wrapper hiện tại giả định hàm ký hai đối số sẽ không lỗi lúc biên dịch – những sẽ lỗi lúc chạy, im lặng, phụ thuộc vào cách thư viện xử lý đối số thiếu. Ở một số phiên bản, context mặc định là rỗng và vẫn ký bình thường, tạo ra chữ ký hợp lệ nhưng cho sai ngữ cảnh. Ở bản khác, thư viện ném lỗi (throw). Cả hai trường hợp cho ra các hành vi không mong muốn cho kỹ sư mật mã học.

Đây là ba hệ quả quan trọng cần biết trước khi nghĩ tới các pipeline ký số:

Tính không tất định (Non-determinism): ECDSA với RFC 6979 là các mật mã học tất định – cùng thông điệp và khóa luôn sinh ra cùng chữ ký. ML-DSA có cơ chế lấy mẫu loại bỏ (rejection sampling) bên trong, nên cùng đầu vào sẽ cho ra các chữ ký hợp lệ khác nhau. Bởi vậy, thực nghiệm so sánh chữ ký byte-by-byte sẽ fail. Test cần được viết lại theo hướng xác minh toán học – gọi hàm verify, không so sánh đầu ra.

Chế độ pre-hash mang OID riêng: Nếu bạn có mô hình tách hash trên một hệ thống và ký trên HSM – phổ biến trong pipeline ký tần suất cao khi dữ liệu quá lớn để truyền – mô hình đó cần thiết kế lại hoàn toàn. HashML-DSA là thuật toán riêng biệt với OID riêng, không phải chế độ của ML-DSA. Không thể tách hash khỏi quá trình ký qua ranh giới tin cậy (trust boundary) như ECDSA cho phép.

Phạm vi tấn công side-channel rộng hơn: Các thao tác nhạy cảm của ECDSA đã được hiểu rõ và giới hạn chặt – phép nhân vô hướng (scalar multiplication) là mục tiêu chính. Lấy mẫu loại bỏ và các phép biến đổi NTT của ML-DSA cần được bảo vệ side-channel trong phần lớn quá trình tính toán. Độ trễ do vậy cũng cao hơn trong các triển khai phần cứng an toàn, và cần kiểm tra đặc tính thời gian (timing characteristics) của nhà cung cấp HSM trước khi triển khai.

# Kiểm tra phiên bản OpenSSL có hỗ trợ ML-DSA (tối thiểu 3.5+)
openssl list -signature-algorithms | grep -i mldsa

# Tạo cặp khóa ML-DSA-65
openssl genpkey -algorithm ML-DSA-65 -out mldsa65_private.pem
openssl pkey -in mldsa65_private.pem -pubout -out mldsa65_public.pem

# Ký file
openssl dgst -sign mldsa65_private.pem -out signature.bin message.txt

# Xác minh – trả về "Verified OK" nếu hợp lệ
openssl dgst -verify mldsa65_public.pem -signature signature.bin message.txt

Tính linh hoạt của Mật mã học

Phần tạo ra nhiều câu hỏi theo dõi nhất trong buổi thuyết trình chính là tính linh hoạt của Mật mã học (crypto agility). Tôi muốn nói chính xác khái niệm này nghĩa là gì, vì khái niệm này thường được mô tả như một khát vọng mơ hồ trong tài liệu nhà cung cấp và các buổi hội thảo.

Crypto agility là khả năng thay thế thuật toán mật mã trong hệ thống đang chạy mà không cần thiết kế lại hệ thống đó. NIST định nghĩa khái niệm này trong CSWP 39. RFC 7696 hợp thức hóa khái niệm này. Lý do tính linh hoạt này quan trọng vượt xa PQC được nêu rõ trong hướng dẫn tháng 1/2026 của CISA. NIST IR 8547 lên lịch loại bỏ RSA và ECDSA vào năm 2030 và cấm hoàn toàn vào năm 2035. Tuy vậy, chỉ cần một đột phá phân tích mật mã (cryptanalytic break) xuất hiện, toàn bộ lịch trình triển khai được thúc đẩy không cần qua chính sách nào.

Nếu lựa chọn PQC được hard-code vào logic ứng dụng, mỗi lần cập nhật đều đòi hỏi phải thay đổi mã nguồn, chu kỳ kiểm thử, và triển khai. Thay vào đó, hãy cho đây là một biến bất định sau một giao diện provider, chỉ cần thay đổi cấu hình về sau.

# KHÔNG ĐẠT – Thuật toán hard-code, không có khả năng chuyển đổi
from cryptography.hazmat.primitives.asymmetric import ec
private_key = ec.generate_private_key(ec.SECP256R1())

# ĐẠT – Thuật toán lấy từ config, thay đổi được mà không sửa code
import config
from crypto_provider import get_kem_algorithm

kem = get_kem_algorithm(config.get("kem_algorithm", "X25519MLKEM768"))
public_key, private_key = kem.generate_keypair()

Năm mô hình biến khái niệm crypto agility thành hiện thực:

Cô lập logic mật mã sau giao diện provider. OpenSSL provider, JCA trong Java, CNG trong Windows – tất cả tồn tại để biến việc chọn thuật toán thành quyết định lúc chạy (runtime) thay vì lúc biên dịch (compile-time). Tên thuật toán nên nằm trong cấu hình, không phải trong mã nguồn.

Nhúng định danh thuật toán vào mọi đối tượng khóa và chứng chỉ. Phía nhận tài liệu mật mã phải xác định được thuật toán nào đã sử dụng mà không cần phối hợp ngoài băng (out-of-band). OID trong chứng chỉ X.509 làm đúng điều này – cần mở rộng sang cả định dạng lưu trữ khóa nội bộ, trình quản lý bí mật (secrets manager), và nhãn khóa HSM.

Hỗ trợ thương lượng hybrid trong giao thức. TLS 1.3, IKEv2 (RFC 9370), và SSH đều có cơ chế thương lượng thuật toán tích hợp sẵn. Bật nhiều nhóm (group). Để giao thức chọn phương án mạnh nhất mà cả hai bên hỗ trợ. Cách này đồng thời cho tương thích ngược với client hiện tại và khả năng chuyển đổi cho client mới.

Tự động hóa vòng đời khóa và chứng chỉ. Crypto agility thất bại ở quy mô lớn nếu việc luân chuyển (rotation) đòi hỏi can thiệp thủ công. Các trình quản lý chứng chỉ – HashiCorp Vault, EJBCA, cert-manager trong Kubernetes – cần được đánh giá và cập nhật hỗ trợ OID PQ trước khi bạn cần luân chuyển, không phải sau.

Duy trì Crypto SBOM. Liệt kê toàn bộ phụ thuộc mật mã theo từng dịch vụ: tên thư viện, phiên bản, thuật toán, loại khóa, phiên bản giao thức. Các công cụ như semgrep với bộ quy tắc chuyên biệt mật mã, testssl.sh cho quét endpoint TLS, và phần mở rộng CycloneDX SBOM có thể tự động hóa phần lớn công việc này. Tài liệu đó chính là checklist khi một thuật toán bị loại bỏ – thiếu nó, bạn sẽ phải phát hiện mức độ ảnh hưởng một cách bị động dưới áp lực.

Bước tiếp theo

Ba tầng phân tích ở trên – cấu hình và API, luồng dữ liệu và kích thước, loại ứng dụng – đại diện cho công việc xác định phạm vi (scoping) cần hoàn thành trước khi chạm vào bất kỳ dòng mã nào. Các mô hình crypto agility là khoản đầu tư kỹ thuật giúp quá trình chuyển đổi bền vững qua nhiều vòng thay đổi thuật toán, không chỉ lần này.

Phần 3 của loạt bài này đi vào thực hành: chạy một kết nối TLS hậu lượng tử trực tiếp đến máy chủ production của Google bằng Docker, đọc đầu ra bắt tay (handshake output), và kết quả đo hiệu năng thực tế khi so sánh ML-KEM và ML-DSA với thuật toán cổ điển trên cùng một máy.

Kết nối qua LinkedIn hoặc GitHub. Nếu bạn đang thực hiện chuyển đổi PQC và có câu hỏi cụ thể về đánh giá HSM, vòng đời chứng chỉ, hay tích hợp cho ngôn ngữ lập trình cụ thể, tôi luôn sẵn sàng trao đổi.

Read the English version / Đọc phiên bản tiếng Anh