Quan điểm của một kỹ sư mật mã về các mốc thời gian tính ...

Quan điểm của tôi về mức độ khẩn cấp trong việc triển khai mật mã chống lượng tử đã thay đổi so với chỉ vài tháng trước. Bạn có thể đã nghe điều này từ tôi một cách riêng tư trong những tuần gần đây, nhưng đã đến lúc công khai báo hiệu và biện minh cho sự thay đổi suy nghĩ này.

Trong một thời gian đã có những tin đồn về tiến bộ dự kiến và không mong đợi đối với máy tính lượng tử có liên quan đến mật mã, nhưng trong tuần vừa qua chúng ta đã có hai trường hợp công khai về điều đó.

Đầu tiên, Google đã xuất bản một bài báo đánh giá lại một cách đáng kể số lượng qubit logic và cổng cần thiết để phá vỡ đường cong elliptic 256-bit như NIST P-256 và secp256k1, điều này làm cho cuộc tấn công có thể thực hiện được trong vài phút trên các kiến trúc xung nhịp nhanh như qubit siêu dẫn. Họ kỳ lạ¹ đóng khung nó xung quanh tiền điện tử và mempool, hàng hóa đã được giải cứu hoặc thứ gì đó, nhưng ý nghĩa quan trọng hơn nhiều là các cuộc tấn công MitM WebPKI thực tế.

Ngay sau đó, một bài báo khác từ Oratomic cho thấy các đường cong elliptic 256-bit có thể bị phá vỡ chỉ với 10.000 qubit vật lý nếu bạn có kết nối không cục bộ, như nguyên tử trung tính dường như cung cấp, nhờ vào việc sửa lỗi tốt hơn. Cuộc tấn công này sẽ chậm hơn, nhưng ngay cả một khóa bị phá vỡ mỗi tháng cũng có thể thảm khốc.

Họ có một biểu đồ tuyệt vời trên trang 2 (Babbush và cộng sự là bài báo của Google, mà họ có lẽ đã có quyền truy cập xem trước):

biểu đồ chi phí qubit vật lý theo thời gian

Nhìn chung, có vẻ như mọi thứ đang diễn ra: phần cứng ngày càng tốt hơn, thuật toán ngày càng rẻ hơn, yêu cầu sửa lỗi ngày càng thấp.

Thành thật mà nói, tôi không thực sự biết tất cả các vật lý trong những bài báo đó có nghĩa là gì. Đó không phải là công việc của tôi và không phải là chuyên môn của tôi. Công việc của tôi bao gồm đánh giá rủi ro thay mặt cho những người dùng đã giao phó sự an toàn của họ cho tôi. Điều tôi biết là những gì ít nhất một số chuyên gia thực sự đang nói với chúng ta.

Heather Adkins và Sophie Schmieg đang nói với chúng ta rằng “biên giới lượng tử có thể gần hơn chúng ta tưởng” và 2029 là thời hạn của họ. Đó là trong 33 tháng, và không ai đặt ra một mốc thời gian tham vọng như vậy cho đến tháng này.

Scott Aaronson nói với chúng ta rằng “lời cảnh báo rõ ràng nhất mà [ông ấy] có thể đưa ra công khai ngay bây giờ về sự cấp bách của việc di chuyển sang các hệ thống mật mã hậu lượng tử” là sự song song mơ hồ với việc nghiên cứu phân hạch hạt nhân ngừng diễn ra công khai từ năm 1939 đến năm 1940.

Các mốc thời gian được trình bày tại RWPQC 2026, chỉ vài tuần trước, đã chặt chẽ hơn nhiều so với vài năm trước, và đã lỗi thời một phần. Câu nói đùa trước đây là máy tính lượng tử đã 10 năm nữa sẽ xuất hiện trong 30 năm. Vâng, điều đó không còn đúng nữa, các mốc thời gian đã bắt đầu tiến triển.

Nếu bạn đang nghĩ “à, điều này có thể tồi tệ, hoặc có thể không có gì cả!” Tôi cần bạn nhận ra rằng điều đó có sức mạnh loại bỏ ngay lập tức như thế nào. Ván cược không phải là “bạn có chắc 100% là CRQC sẽ tồn tại vào năm 2030 không?”, mà là ván cược “bạn có chắc 100% là CRQC SẼ KHÔNG tồn tại vào năm 2030 không?” Tôi đơn giản là không thấy làm thế nào một người không chuyên có thể nhìn vào những gì các chuyên gia đang nói và quyết định “tôi biết rõ hơn, thực tế có < 1% cơ hội.” Hãy nhớ rằng bạn đang đặt cược bằng mạng sống của người dùng.²

Nói cách khác, ngay cả khi kết quả có khả năng xảy ra nhất là không có CRQC trong đời chúng ta, thì điều đó cũng hoàn toàn không liên quan, bởi vì người dùng của chúng ta không chỉ muốn có cơ hội tốt hơn mức trung bình³ về sự an toàn.

Chắc chắn, các bài báo về một cái bàn tính và một con chó thì hài hước và có thể làm bạn trông thông minh và đi ngược lại số đông trên các diễn đàn. Nhưng đó không phải là công việc, và những lập luận đó bộc lộ sự thiếu chuyên môn. Như Scott Aaronson đã nói:

Một khi bạn hiểu về khả năng chịu lỗi lượng tử, việc hỏi “thế khi nào bạn sẽ phân tích thừa số 35 bằng thuật toán Shor?” trở nên giống như hỏi các nhà vật lý Dự án Manhattan năm 1943, “thế khi nào các bạn sẽ tạo ra ít nhất một vụ nổ hạt nhân nhỏ?”

Công việc không phải là hoài nghi về những điều chúng ta không chuyên, mà là giảm thiểu các mối đe dọa có thể xảy ra, và có những chuyên gia đáng tin cậy đang cảnh báo chúng ta về một mối đe dọa sắp xảy ra.

Tóm lại, có thể trong 10 năm nữa dự đoán sẽ sai, nhưng tại thời điểm này chúng cũng có thể đúng sớm, và rủi ro đó giờ đây là không thể chấp nhận được.

Bây giờ làm gì

Cụ thể, điều này có nghĩa là gì? Điều đó có nghĩa là chúng ta cần phải triển khai.

Thật không may, chúng ta phải triển khai những gì mình có. Điều đó có nghĩa là chữ ký ML-DSA lớn được nhét vào những vị trí dành cho chữ ký ECDSA nhỏ, như X.509, ngoại trừ Chứng chỉ Cây Merkle cho WebPKI, điều mà may mắn thay đã tiến triển đủ xa.

Đây *không* phải là bài viết tôi muốn viết. Tôi đã có một bản nháp đang chờ xử lý trong nhiều tháng giải thích rằng chúng ta nên triển khai trao đổi khóa PQ ngay bây giờ, nhưng dành thời gian chúng ta còn có để điều chỉnh các giao thức cho chữ ký lớn hơn, bởi vì tất cả chúng đều được thiết kế dựa trên giả định rằng chữ ký là rẻ. Bài viết kia giờ đây đã sai, thật đáng tiếc: chúng ta không còn thời gian nếu cần hoàn thành vào năm 2029 thay vì 2035.

Đối với trao đổi khóa, việc chuyển đổi sang ML-KEM đang diễn ra khá tốt nhưng:

Bất kỳ trao đổi khóa không phải PQ nào giờ đây cũng nên được coi là một sự thỏa hiệp chủ động tiềm ẩn, đáng để cảnh báo người dùng như OpenSSH làm, bởi vì rất khó để đảm bảo tất cả các bí mật được truyền qua kết nối hoặc được mã hóa trong tệp có thời gian tồn tại ngắn hơn ba năm.
Chúng ta cần quên đi các trao đổi khóa không tương tác (NIKEs) trong một thời gian; chúng ta chỉ có KEM (chỉ được xác thực một chiều mà không cần tương tác) trong bộ công cụ PQ.

Không còn lý do gì để triển khai các lược đồ mới không phải là hậu lượng tử. Tôi biết, các cặp đôi rất hay. Tôi biết, mọi thứ PQ đều khó chịu vì kích thước lớn. Tôi biết, chúng ta gần như *vừa mới* tìm ra cách thực hiện ECDSA trên P-256 một cách an toàn. Tôi biết, có thể không có các tương đương PQ thực tế cho chữ ký ngưỡng hoặc mã hóa dựa trên danh tính. Tin tôi đi, tôi biết điều đó thật khó chịu. Nhưng sự thật là vậy.

Hybrid classic + post-quantum authentication làm cho tôi không còn ý nghĩa nữa và sẽ chỉ làm chúng ta chậm lại; chúng ta nên đi thẳng đến ML-DSA-44 thuần túy.⁵ Trao đổi khóa lai hợp lý là dễ dàng, với các khóa tạm thời không cần kiểu hoặc định dạng dây cho khóa riêng kết hợp, và cách đây vài năm, việc phòng ngừa là hợp lý. Xác thực thì không như vậy, và ngay cả với draft-ietf-lamps-pq-composite-sigs-15 với 18 loại khóa kết hợp sắp xuất bản, chúng ta sẽ lãng phí thời gian quý báu để cùng nhau tìm hiểu cách xử lý các khóa kết hợp này và cách hiển thị chúng cho người dùng. Cũng đã hai năm kể từ các bản lai Kyber và chúng ta đã có sự tự tin đáng kể vào các lược đồ Module-Lattice. Chữ ký lai tốn chi phí thời gian và ngân sách phức tạp,⁴ và lợi ích duy nhất là bảo vệ nếu ML-DSA bị phá vỡ cổ điển trước khi CRQCs xuất hiện, điều này có vẻ là sự đánh đổi sai lầm vào thời điểm này.

Trong mã hóa đối xứng, may mắn là chúng ta không cần làm gì. Có một quan niệm sai lầm phổ biến rằng bảo vệ khỏi Grover yêu cầu khóa 256 bit, nhưng điều đó dựa trên sự hiểu biết cực kỳ đơn giản hóa về thuật toán. Một mô tả chính xác hơn là với độ sâu mạch là 2⁶⁴ cổng logic (số lượng cổng xấp xỉ mà các kiến trúc máy tính cổ điển hiện tại có thể thực hiện tuần tự trong một thập kỷ) chạy Grover trên không gian khóa 128 bit sẽ yêu cầu kích thước mạch là 2¹⁰⁶. Tôi không biết có tiến bộ nào về điều này, và thực tế có những chứng minh cũ rằng Grover là tối ưu và sự tăng tốc lượng tử của nó không song song hóa được. Các yêu cầu khóa 256 bit không cần thiết là có hại khi đi kèm với các yêu cầu PQ thực sự khẩn cấp, vì chúng làm mờ các mục tiêu tương tác và chúng có nguy cơ làm chậm việc triển khai mật mã PQ bất đối xứng.

Trong lĩnh vực của tôi, chúng ta sẽ phải bắt đầu suy nghĩ về việc điều gì sẽ xảy ra khi một nửa các gói mật mã trong thư viện chuẩn của Go đột nhiên không an toàn, và làm thế nào để cân bằng rủi ro tấn công hạ cấp và khả năng tương thích ngược. Đây là lần đầu tiên trong sự nghiệp của chúng ta đối mặt với điều gì đó như thế này: SHA-1 đến SHA-256 không hề gây xáo trộn bằng,⁶ và ngay cả điều đó cũng mất rất nhiều thời gian với các cuộc tấn công hạ cấp bất ngờ thỉnh thoảng xảy ra.

Môi trường thực thi đáng tin cậy (TEEs) như Intel SGX và AMD SEV-SNP và chứng thực phần cứng nói chung đều bị hỏng. Tất cả các khóa và gốc của chúng không phải là PQ và tôi chưa nghe nói về bất kỳ tiến bộ nào trong việc triển khai các khóa PQ, điều này ở tốc độ phần cứng có nghĩa là chúng ta buộc phải chấp nhận rằng chúng có thể không kịp và không thể dựa vào được. Tôi đã phải đánh giá lại toàn bộ một dự án vì điều này, và tôi có lẽ sẽ hạ cấp chúng xuống mức "phòng thủ theo chiều sâu" trong bộ công cụ của mình.

Các hệ sinh thái có danh tính mật mã (như atproto và, vâng, tiền điện tử) cần bắt đầu di chuyển rất sớm, bởi vì nếu CRQCs xuất hiện trước khi chúng hoàn thành, chúng sẽ phải đưa ra những quyết định cực kỳ khó khăn, chọn giữa việc để người dùng bị xâm phạm và làm hỏng chúng.

Mã hóa tệp đặc biệt dễ bị tấn công lưu trữ ngay bây giờ-giải mã sau, vì vậy chúng ta có lẽ sẽ phải bắt đầu cảnh báo và sau đó báo lỗi đối với các loại người nhận age không phải PQ sớm. Thật không may, chỉ mới vài tháng kể từ khi chúng ta thêm người nhận PQ, trong phiên bản 1.3.0.⁷

Cuối cùng, tuần này tôi bắt đầu dạy một khóa học tiến sĩ về mật mã tại Đại học Bologna, và tôi sẽ đề cập đến RSA, ECDSA và ECDH chỉ như các thuật toán cũ, bởi vì đó là cách mà các sinh viên đó sẽ gặp chúng trong sự nghiệp của họ. Tôi biết, nghe có vẻ kỳ lạ. Nhưng nó là như vậy.

Để di chuyển PQ sẵn sàng hay không sẵn sàng hơn, hãy theo dõi tôi trên Bluesky tại @filippo.abyssdomain.expert hoặc trên Mastodon tại @filippo@abyssdomain.expert.

Bức tranh

Trên đường trở về từ một hội nghị AtmosphereConf 2026 tuyệt vời, tôi đã nhìn thấy cực quang đầu tiên của mình, từ cửa sổ hướng bắc của một chiếc Boeing 747.

Công việc của tôi được thực hiện nhờ Geomys, một tổ chức của các nhà bảo trì Go chuyên nghiệp, được tài trợ bởi Ava Labs, Teleport, Tailscale, và Sentry. Thông qua các hợp đồng giữ chỗ của chúng tôi, họ đảm bảo tính bền vững và độ tin cậy cho công việc bảo trì mã nguồn mở của chúng tôi và có một đường dây trực tiếp đến chuyên môn của tôi và của các nhà bảo trì Geomys khác. (Tìm hiểu thêm trong thông báo Geomys.) Đây là một vài lời từ một số người trong số họ!

Teleport — Trong năm năm qua, các cuộc tấn công và xâm phạm đã chuyển từ phần mềm độc hại và vi phạm bảo mật truyền thống sang việc xác định và xâm phạm các tài khoản và thông tin xác thực người dùng hợp lệ bằng kỹ thuật xã hội, đánh cắp thông tin đăng nhập hoặc lừa đảo. Teleport Identity được thiết kế để loại bỏ các mẫu truy cập yếu thông qua giám sát truy cập, giảm thiểu bề mặt tấn công bằng các yêu cầu truy cập và xóa các quyền không sử dụng thông qua các đánh giá truy cập bắt buộc.

Ava Labs — Chúng tôi tại Ava Labs, nhà bảo trì AvalancheGo (khách hàng được sử dụng rộng rãi nhất để tương tác với Avalanche Network), tin rằng việc bảo trì và phát triển bền vững các giao thức mật mã mã nguồn mở là rất quan trọng đối với việc áp dụng rộng rãi công nghệ blockchain. Chúng tôi tự hào hỗ trợ công việc cần thiết và có tác động này thông qua việc tài trợ liên tục cho Filippo và nhóm của anh ấy.

Toàn bộ bài báo hơi kỳ quặc: nó có một bằng chứng không tiết lộ cho một mạch lượng tử chắc chắn sẽ được suy ra lại và cải tiến trước khi phần cứng thực tế để chạy nó tồn tại. Họ dường như tin rằng đây là về việc tiết lộ có trách nhiệm, vì vậy tôi cho rằng đây chỉ là các nhà vật lý không chuyên gia trong lĩnh vực của chúng ta giống như chúng ta không phải là chuyên gia trong lĩnh vực của họ. ↩
“Bạn” đang làm rất nhiều việc trong câu này, nhưng đối tượng của bài đăng này hơi khác thường đối với tôi: tôi đang nói chuyện với các đồng nghiệp của mình và những người ra quyết định kiểm soát hành động triển khai mật mã hậu lượng tử. ↩
Một người xem đã phản đối xác suất thành công của kẻ tấn công là 1/536.870.912 (0,0000002%, 2⁻²⁹) sau 2⁶⁴ công việc, và điều này là đúng, vì trong mật mã học chúng ta thường nhắm đến 2⁻³². ↩
Một ngoại lệ nhỏ là nếu bạn *đã* có khả năng truyền nhiều chữ ký từ nhiều khóa công khai trong giao thức của mình, bạn có thể cân nhắc "poor man’s hybrid signatures" (chữ ký lai kiểu người nghèo) bằng cách chỉ yêu cầu 2 trong số 2 chữ ký từ một khóa công khai cổ điển và một khóa PQ thuần túy. Một số hệ sinh thái tlog có thể chọn con đường này, nhưng đó là *chỉ* bởi vì chi phí được giảm đáng kể nhờ sự hỗ trợ hiện có cho các nhóm ký n-of-m lồng nhau. ↩
Tại sao lại là ML-DSA-44 khi chúng ta thường sử dụng ML-KEM-768 thay vì ML-KEM-512? Bởi vì ML-KEM-512 là Cấp 1 (Level 1), trong khi ML-DSA-44 là Cấp 2 (Level 2), nên nó đã có một chút biên độ an toàn trước các cải tiến phân tích mật mã nhỏ. ↩
Vì SHA-256 là một sự thay thế plug-in tốt hơn cho SHA-1, vì SHA-1 có bề mặt tấn công nhỏ hơn nhiều so với RSA và ECC, và vì SHA-1 không *hỏng nặng* đến vậy: nó vẫn giữ được khả năng chống tiền ảnh (preimage resistance) và vẫn có thể được sử dụng trong HMAC và HKDF. ↩
Sự chậm trễ phần lớn là do quyết định không may của tôi khi chờ đợi sự sẵn có của các người nhận HPKE lai, điều này lại phụ thuộc vào CFRG, mà tổ chức này đã mất *gần hai năm* để chọn một chuỗi nhãn ổn định cho X-Wing (tháng 1 năm 2024) cùng với ML-KEM (tháng 8 năm 2024), mặc dù không có bất kỳ thay đổi nào trong thiết kế. IETF lẽ ra nên có một buổi xem xét nội bộ về vấn đề này, nhưng tôi nghi ngờ chúng ta sẽ thấy điều đó. ↩

Quan điểm của một kỹ sư mật mã về các mốc thời gian tính toán lượng tử

Bây giờ làm gì

Bức tranh