Bí ẩn 30 năm của bảng π trong mật mã RC2 đã được giải mã

Trong gần ba thập kỷ, giới mật mã học vẫn treo lơ lửng một câu hỏi tưởng chừng nhỏ nhưng quan trọng: bảng hoán vị 256 byte trong thuật toán RC2 được tạo ra bằng cách nào? Câu trả lời giờ đây đã có, và nó hóa ra lại đơn giản đến bất ngờ.

Câu hỏi bị bỏ ngỏ từ năm 1996

RC2 là thuật toán mã hóa khối do Ron Rivest thiết kế vào cuối thập niên 1980. Để biến khóa người dùng thành khóa nội bộ dài hơn, thuật toán đưa từng byte qua một bảng cố định: các số từ 0 đến 255 xếp theo thứ tự đã bị xáo trộn. Mọi bản triển khai RC2 trên thế giới đều mang cùng 256 con số này.

Ron Rivest, tác giả của RC2 và MD2

Với một bảng như vậy, về lý thuyết, người thiết kế có thể giấu một điểm yếu bên trong. Giới mật mã học chống lại mối nghi ngờ này bằng cách suy ra bảng từ một hằng số công khai như π và công bố cách suy ra, để bất kỳ ai cũng có thể tái tạo và kiểm chứng. Đó là khái niệm "nothing-up-my-sleeve number" - con số không giấu bài trong tay áo. Nhưng chúng chỉ thực sự tạo được niềm tin khi phương pháp tạo ra chúng được công khai.

Tài liệu đặc tả RFC 2268 của Rivest chỉ gọi bảng này là "mảng byte 'ngẫu nhiên' dựa trên các chữ số của π" và in ra mà không kèm theo cách tạo. Khi mã nguồn RC2 bị rò rỉ năm 1996, một kỹ sư tại RSA Data Security đã công khai đặt câu hỏi làm sao xác định được bảng có thực sự đến từ π hay không. Không có câu trả lời nào xuất hiện. Một số bản triển khai như LibTomCrypt đến nay vẫn giữ nguyên dòng chú thích từ mã rò rỉ năm xưa: "có lẽ được suy ra từ π theo cách nào đó".

Áo phun biểu tình thời kỳ kiểm soát xuất khẩu mật mã

Lời giải nằm ở một trò xáo bài

Nghiên cứu của Khalid Hamadeh chỉ ra rằng bảng PITABLE có thể được tái tạo chính xác đến từng vị trí bằng thuật toán xáo bài Fisher–Yates - phương pháp xáo trộn công bằng tiêu chuẩn, vốn chưa bao giờ là bí mật. Điều chưa từng được công bố là nguồn ngẫu nhiên lấy từ đâu.

Cách làm cụ thể: hình dung 256 tấm thẻ đánh số 0 đến 255 xếp theo thứ tự. Lần lượt lấy từng tấm thẻ, từ tấm thứ hai đến tấm cuối, và đổi chỗ nó với một tấm ngẫu nhiên nằm ở vị trí bằng hoặc trước nó. Điểm mấu chốt là mỗi lần rút đọc đúng ba chữ số thập phân của π, bắt đầu từ chữ số 3 đầu tiên.

• Đọc 314, thẻ số 1 đổi chỗ với vị trí 314 mod 2 = 0
• Đọc 159, thẻ số 2 đổi chỗ với vị trí 159 mod 3 = 0
• Đọc 265, thẻ số 3 đổi chỗ với vị trí 265 mod 4 = 1
• Cứ tiếp tục như vậy cho đến hết

Thuật toán còn có bước loại bỏ để giữ tính công bằng: khi số vị trí khả dụng không chia hết 1.000, những lần rút rơi vào nhóm giá trị cao nhất sẽ bị bỏ và đọc thêm ba chữ số mới. Trên toàn bộ quá trình xáo, việc này xảy ra 21 lần, trong đó có hai lần rơi đúng vào chuỗi sáu số 9 tại vị trí thập phân thứ 762 của π - được biết đến với tên gọi điểm Feynman. Tổng cộng phép xáo dùng 828 chữ số.

Vì sao bí mật tồn tại lâu đến vậy

Năm 2014, Rivest xác nhận rằng hàm băm MD2 của ông cũng dùng chính trò xáo bài này để tạo bảng π. Tuy nhiên MD2 đọc số chữ số thay đổi tùy theo mỗi lần rút: một chữ số khi có tối đa 10 vị trí để chọn, hai chữ số khi lên tới 100, ba chữ số khi vượt quá. Áp nguyên quy tắc của MD2 vào RC2 chỉ khớp được 1 trong 256 vị trí - không khác gì đoán mò. Vì thế, phép thử hiển nhiên nhất sẽ khiến người ta tưởng hai bảng không liên quan gì đến nhau.

Khác biệt duy nhất cần thay đổi là luôn đọc ba chữ số mỗi lần.

Kiểm chứng bằng con số, không bằng niềm tin

Kết quả không phải sự trùng hợp ngẫu nhiên. Có khoảng 10^507 cách sắp xếp khác nhau của 256 con số. Quá trình tìm kiếm đã thử khoảng 100.000 phương án - bốn nguồn chữ số, bảy cách rút số, sáu thứ tự xáo bài, 300 điểm xuất phát, cùng cả bảng và nghịch đảo của nó - và chỉ duy nhất một phương án khớp hoàn toàn: phương án đơn giản nhất.

Phương pháp	Số vị trí khớp
Thuật toán chuẩn: π thập phân từ số 3 đầu, ba chữ số mỗi lần	256/256
Bỏ bước loại bỏ	29/256
Chữ số hex của π theo cặp	2/256
Quy tắc chữ số của MD2	1/256
Bắt đầu chậm một chữ số	1/256
Áp dụng lên các chữ số của e	0/256

Đáng chú ý, khi được hỏi "bảng PITABLE của RC2 được tạo ra từ π như thế nào" vào tháng 10/2026, phần tổng quan AI của Google đã mô tả một phương pháp hex - và ví dụ của nó bắt đầu bằng 24 3f 6a trong khi bảng công bố bắt đầu bằng d9 78 f9.

Bảng thứ hai cũng có lời giải

Mục 6 của RFC 2268 in thêm một bảng hoán vị thứ hai, gọi là bảng phiên bản, dùng để mã hóa độ dài khóa hiệu dụng từ 1 đến 255 bit. RFC chỉ nói rằng nó "không phải bảng xuất hiện trong giai đoạn mở rộng khóa" mà không giải thích gì thêm. Hóa ra đây chính là thuật toán trên, nhưng xuất phát từ chữ số thứ năm của π (5926…) thay vì chữ số đầu. Nó khớp cả 256 vị trí, cũng dùng 828 chữ số với 21 lần loại bỏ.

Như vậy, cả hai bảng trong RFC đều có thể được sinh ra bởi một bộ sinh duy nhất, chạy từ hai điểm xuất phát khác nhau.

Bối cảnh lịch sử: một thuật toán ra đời trong kìm kẹp

Vào thập niên 1980, Mỹ kiểm soát việc xuất khẩu mật mã mạnh chẳng khác gì kiểm soát vũ khí, và NSA là cơ quan thẩm định kỹ thuật. Lotus Development đang chuẩn bị bán Notes - ứng dụng doanh nghiệp tích hợp mã hóa, phát triển bởi công ty Iris Associates của Ray Ozzie - nhưng không xin được giấy phép xuất khẩu với thuật toán chuẩn DES.

Trụ sở NSA tại Fort Meade, Maryland

Theo ghi chép của Steven Levy, NSA đồng ý đánh giá một thuật toán thay thế vào giữa năm 1987. Lotus thuê Rivest, ông thiết kế RC2 chỉ trong vài tuần. Rivest gửi thiết kế cho NSA, và cơ quan này yêu cầu "vài chỉnh sửa nhỏ". Ozzie, người dẫn dắt đàm phán, đã hỏi thẳng Rivest:

"Làm sao ông biết họ không làm gì đó để làm yếu nó đi?"

Rivest đánh giá các đề xuất là hợp lý về mặt kỹ thuật và chấp nhận. Tài liệu của Levy không nói rõ đó là những chỉnh sửa gì.

Năm 1989, NSA đề nghị cấp phép xuất khẩu RC2 với khóa giới hạn 32 bit. Năm 1992, một thỏa thuận cho phép phê duyệt xuất khẩu nhanh với phần mềm bán lẻ dùng RC2 hoặc RC4 có khóa tối đa 40 bit, với điều kiện RSA và các bên được cấp phép giữ bí mật thiết kế. RC2 được bán ra toàn cầu trong các sản phẩm thương mại trong khi phần lõi, gồm cả bảng hoán vị, vẫn chưa được công bố.

Ý nghĩa thực sự của kết quả

Cần tách bạch ba khẳng định. Đã được chứng minh bằng tính toán: thuật toán trên tái tạo chính xác cả hai bảng công bố, và bất kỳ ai cũng có thể tự kiểm tra bằng script công khai. Được ủng hộ mạnh nhưng chưa chứng minh: đây chính là phương pháp, hoặc rất gần với phương pháp mà Rivest đã dùng. Chưa xác lập: chính xác Rivest đã đi đến quy tắc này như thế nào, liệu ông có thử các quy tắc hay điểm xuất phát khác trước khi chọn nó không.

Điểm cuối cùng quan trọng với câu hỏi "nothing up my sleeve". 256 phần tử không được chọn thủ công từng cái một mà tuân theo một quy tắc ngắn áp lên π - điều này thu hẹp đáng kể khả năng chọn lựa có chủ đích, nhưng không xóa bỏ hoàn toàn. Về nguyên tắc, người thiết kế vẫn có thể đã thử vài quy tắc đơn giản rồi giữ lại một; việc bảng thứ hai có điểm xuất phát khác cho thấy những lựa chọn như vậy từng được thực hiện.

Kết quả này không ảnh hưởng đến độ bảo mật của RC2. Thuật toán đã bị khuyến nghị ngừng dùng từ lâu, dù vẫn tồn tại trong các tệp chứng chỉ PKCS #12 cũ. Biết được nguồn gốc của một bảng công khai không làm nó yếu đi hay mạnh lên.

Một thí nghiệm về AI và những bài toán bị lãng quên

Kết quả này đến từ một thí nghiệm dùng tác nhân AI cho những bài toán bị bỏ quên nhưng có đáp án kiểm chứng được chính xác. Tháng 10/2026, Anthropic báo cáo rằng mô hình Claude của họ đã truy ra nguồn gốc hạt giống của các đường cong elliptic NIST. Hamadeh thiết lập một quy trình thu thập các câu hỏi tồn đọng lâu năm, xếp hạng theo khả năng tự kiểm chứng của lời giải, rồi giao những bài hứa hẹn nhất cho các tác nhân lập trình AI.

Bảng của RC2 là kết quả đầu tiên. Claude lập luận rằng nếu một trong các bảng π của Rivest đã được giải thích thì bảng kia có thể giải được bằng cùng phương pháp, và tìm ra quy tắc ba chữ số. Codex của OpenAI viết bản triển khai độc lập thứ hai, và một lượt quét sau đó tìm ra bảng RC2 thứ hai. Tất cả đều có thể tự kiểm chứng: script trong kho mã tính π và đối chiếu cả hai bảng với RFC trong chưa đầy một giây.

Với độc giả quan tâm đến an ninh thông tin tại Việt Nam, câu chuyện này là lời nhắc nhở rằng các thuật toán cũ vẫn âm thầm hiện diện trong nhiều hệ thống, tệp tin và giao thức kế thừa. Việc hiểu rõ nguồn gốc các hằng số mật mã - dù chỉ để thỏa mãn trí tò mò - chính là nền tảng của văn hóa minh bạch mà ngành bảo mật luôn theo đuổi.