Bài viết phân tích vì sao việc nâng cấp từ giao thức ECC lên ECC+PQ (lai ghép) an toàn hơn nhiều so với chuyển hẳn sang PQ đơn lẻ (chỉ dùng hậu lượng tử). Tác giả dẫn chứng hàng loạt lỗ hổng thực tế trong phần mềm ML-KEM/ML-DSA, đồng thời bác bỏ các lập luận cho rằng PQ đơn lẻ đủ an toàn hoặc ECC+PQ quá phức tạp, đắt đỏ. Kết luận nhấn mạnh chi phí thêm ECC là không đáng kể so với lợi ích bảo vệ người dùng khỏi hậu quả của lỗi bảo mật.

Lỗi phần mềm là chuyện thường: Cách đơn giản để so sánh PQ đơn lẻ với ECC+PQ

Trong cuộc tranh luận về tiêu chuẩn mã hóa hậu lượng tử (post-quantum), câu hỏi quan trọng nhất không phải là chọn thuật toán nào, mà là có nên giữ lại lớp bảo vệ ECC cũ bên cạnh các thuật toán mới như ML-KEM, ML-DSA hay không. Một phân tích mới từ nhà mật mã học nổi tiếng d.j. bernstein chỉ ra rằng việc chuyển sang PQ đơn lẻ (solo PQ) sẽ là một thảm họa an ninh khó có thể bào chữa, bởi phần mềm PQ chắc chắn sẽ có lỗi, và không có ai có thể đảm bảo các lỗi đó không bị khai thác.

Nội dung bài viết tập trung vào lập luận thực tế nhất: phần mềm mật mã luôn có bug, và phần mềm PQ còn quá non trẻ so với ECC. Thay vì tin vào những lời hứa hẹn về sự ổn định, chúng ta nên nhìn vào những con số CVE, những lỗ hổng timing attack đã được chứng minh, và câu hỏi đơn giản: tại sao lại loại bỏ một lớp bảo vệ rẻ tiền có thể cứu hàng triệu người dùng chỉ vì một vài dòng mã "thừa"?

Vấn đề không nằm ở lý thuyết mà nằm ở phần mềm

Điểm mấu chốt mà tác giả đưa ra là: các cuộc tấn công vào giao thức PQ thường được nhắc đến như một rủi ro tương lai, nhưng lỗi phần mềm lại là hiện thực hiện hữu ngay bây giờ. Trong nhiều năm qua, đã có hàng trăm lỗ hổng được phát hiện trong các thư viện mật mã. Riêng với các triển khai ML-KEM (Kyber) và ML-DSA (Dilithium), chúng ta đã chứng kiến nhiều bug và rò rỉ timing đáng chú ý:

Năm 2017: Lỗi trong triển khai Dilithium chính thức đầu tiên.
Cuối năm 2023: Hai lỗ hổng timing nổi tiếng là KyberSlash1 và KyberSlash2 tồn tại trong mọi triển khai Kyber tham chiếu từ 2017 tới 2023. Các bản demo khai thác thành công đã được công bố.
Năm 2026: Hàng loạt CVE và lỗi khác trong code ML-DSA xuất hiện ở các thư viện lớn như libcrux, libgcrypt, RustCrypto, wolfSSL.
Ngày 24/6/2026: Các nhà vận động chống ECC+PQ tổ chức một cuộc bỏ phiếu cho phép loại bỏ ECC. Ngay ngày hôm sau, CVE-2026-6330 — một lỗi phần mềm ML-KEM trong WolfSSL — được công bố.

Sự thật là: Phần mềm PQ sẽ thường xuyên có lỗi. Một số lỗi sẽ có thể bị khai thác. ML-KEM và ML-DSA không phải là ngoại lệ kỳ diệu nào cả.

Kiểm thử tốt hơn không có nghĩa là không có lỗi

Những người ủng hộ PQ đơn lẻ thường viện dẫn rằng môi trường kiểm thử hiện đại giúp giảm thiểu rủi ro. Nhưng tác giả chỉ ra rằng ngay cả những bài kiểm tra tiên tiến nhất như trong dự án SUPERCOP — vốn quét 5036 triển khai mật mã khác nhau — cũng chỉ bao phủ một phần nhỏ. Các thư viện thương mại điển hình có test "lỏng lẻo hơn nhiều" so với SUPERCOP.

Một số lỗi thậm chí "sống sót" qua cả kiểm thử tiêu chuẩn, như nghiên cứu tháng 5/2026 về các lỗi ML-DSA cho thấy. Và việc xác minh hình thức (formal verification) — vốn có thể tìm ra mọi bug — lại quá tốn kém: một nhóm lớn đã mất "gần ba năm" để xác minh một phần mềm ML-KEM cụ thể, mà vẫn phải "cắt xén" một số phần quan trọng.

Tranh luận của phe "bỏ ECC" sụp đổ như thế nào

Lập luận 1: "ML-KEM dễ triển khai an toàn hơn ECC"

Nhiều chuyên gia như Filippo Valsorda, Sophie Schmieg hay Mark Schultz-Wu đã đưa ra tuyên bố không có bằng chứng rằng code lattice dễ viết đúng hơn code ECC. Tác giả cho rằng điều này không đúng với thực tế mã nguồn, và quan trọng hơn, nó hoàn toàn không giải quyết vấn đề:

Giả sử 10% thư viện ML-KEM có lỗi khai thác được. Nhiều người dùng trong số đó sẽ được "cứu" bởi lớp ECC. Ngay cả khi ai đó phóng đại rằng ECC có tới 50% khả năng bị lỗi, lớp ECC vẫn cứu được nửa còn lại. Điều này hoàn toàn biện minh cho việc giữ ECC.

Lập luận 2: "ECC+PQ quá phức tạp, làm chậm triển khai"

Đây là một trong những lập luận yếu nhất. Trên thực tế, Cloudflare đã công bố vào tháng 9/2025 rằng khoảng 95% kết nối HTTPS hậu lượng tử của họ dùng X25519MLKEM768 (lai ghép). Điều này cho thấy việc chọn ECC+PQ không hề khó: chỉ cần dùng X25519 đã phổ biến và nối thêm kết quả ML-KEM vào.

Các lựa chọn chính thức từ IETF cho TLS gồm 3 combo rất đơn giản: X25519MLKEM768, SecP256r1MLKEM768, SecP384r1MLKEM1024 — mỗi loại chỉ thêm vài dòng code so với việc triển khai ML-KEM đơn lẻ.

Lập luận 3: "ECC không giúp gì khi tấn công lượng tử xuất hiện (CRQC)"

Đây là một sai lầm logic rất lớn. Ngay cả khi có máy tính lượng tử, việc trì hoãn tấn công thêm một năm cũng tạo thêm giá trị to lớn. Ai cũng muốn dữ liệu của mình được bảo mật lâu hơn, kể cả sau khi CRQC xuất hiện. Ngoài ra, các ước tính cho thấy chi phí tấn công ECC trên máy lượng tử là rất cao — IBM dự kiến đầu tư 10 tỷ USD cho một cỗ máy nghiêm túc. Ngay cả khi chi phí giảm theo thời gian, mỗi năm cỗ máy đó chỉ phá được khoảng 2^15 khóa ECC, trong khi TLS đã sử dụng hơn 2^50 khóa mỗi năm. Tức là chỉ một phần rất nhỏ mục tiêu bị ảnh hưởng.

Lập luận 4: "Chúng ta không đủ tiền để chạy ECC+PQ"

Tác giả gọi lập luận này là "không thể vượt qua bài kiểm tra tiếng cười". Chi phí của X25519 hoặc Ed25519 là không đáng kể so với ML-KEM/ML-DSA:

ML-KEM-512 (tùy chọn nhỏ nhất): khóa 800 byte, bản mã 768 byte.
X25519: chỉ thêm 32 byte khóa và 32 byte bản mã.

Một ví dụ minh họa: Paul Wouters từng kể câu chuyện về "giao dịch tần suất cao" cần solo PQ để giảm độ trễ. Nhưng ngay lập tức có 5 phản hồi chỉ ra rằng việc thiết lập phiên (handshake) diễn ra trước giờ giao dịch, nên chuyện thêm vài microsecond là hoàn toàn vô nghĩa. Wouters đã không bao giờ trả lời.

Phần kết: Một lựa chọn quá rõ ràng

Bài viết kết thúc bằng lời kêu gọi hành động khẩn thiết. Tác giả nhấn mạnh ba điểm chính:

ML-KEM và ML-DSA sẽ có lỗi phần mềm, và nhiều lỗi trong số đó có thể bị khai thác.
Giữ lớp ECC trong ECC+PQ là một tấm lưới an toàn rẻ tiền, giúp giảm thiểu thiệt hại từ những lỗi này.
Chi phí để thêm ECC là không đáng kể, vì vậy không có lý do chính đáng nào để loại bỏ nó.

Hãy nhìn vào những con số: Các thư viện mật mã có khoảng 1 CVE trên 1000 dòng code. Một triển khai ML-KEM điển hình có hơn 1000 dòng. Có hàng chục thư viện hỗ trợ ML-KEM khác nhau ngoài kia. Câu hỏi không phải là "liệu có thư viện nào bị khai thác không", mà là "khi nào thì chuyện đó xảy ra, và ai sẽ phải chịu trách nhiệm".

Với những bằng chứng về lỗi KyberSlash, các CVE liên tiếp trong năm 2026, và phân tích chi phí rõ ràng, thông điệp cuối cùng rất đơn giản: Hãy giữ ECC, đừng để những lời hứa hẹn về một thế giới PQ hoàn hảo đánh lừa bạn. Cuộc bỏ phiếu tại IETF về việc có cho phép solo PQ hay không vẫn đang mở — và đây là thời điểm để các kỹ sư bảo mật lên tiếng.