Một thành phần được chuẩn hóa là điểm khởi đầu để đánh giá, không phải chứng nhận cho toàn bộ ứng dụng nhắn tin.
ML-KEM-768 giúp hai bên thiết lập một bí mật dùng chung, sau đó có thể dùng để bảo vệ tin nhắn. Nó là một thành phần của hệ thống nhắn tin, không phải giao thức trò chuyện hoàn chỉnh, thuật toán mã hóa tin nhắn hay chứng nhận ứng dụng an toàn.
NIST công bố FIPS 203 vào ngày 13 tháng 8 năm 2024, chuẩn hóa ML-KEM và các bộ tham số 512, 768, 1024. Tính bảo mật của chúng dựa trên những bài toán lưới được cho là chống được tấn công lượng tử. “Được cho là chống được” là giả định bảo mật có phân tích hỗ trợ, không phải lời hứa rằng không thể xuất hiện điểm yếu trong tương lai. NIST FIPS 203.
KEM nằm ở đâu trong cuộc trò chuyện mã hóa?
Một cách hữu ích để đọc tuyên bố mã hóa là theo dõi vật liệu khóa:
- Xác thực đúng đối tác dự định liên lạc. Trao đổi khóa với kẻ mạo danh vẫn là trao đổi khóa với sai người.
- Thiết lập vật liệu bí mật dùng chung. KEM đóng góp một bí mật thông qua đóng gói và giải đóng gói.
- Dẫn xuất khóa cho từng mục đích cụ thể. Hàm dẫn xuất khóa tách biệt vật liệu dùng cho các phần khác nhau của giao thức.
- Mã hóa và xác thực tin nhắn. Lược đồ mã hóa có xác thực bảo vệ nội dung và phát hiện sửa đổi trái phép.
- Quản lý phiên theo thời gian. Luân chuyển, xóa khóa, đổi thiết bị và khôi phục quyết định việc xâm nhập về sau có thể làm lộ những gì.
Những bước này giải thích vì sao tiêu chuẩn cho bước hai không thể xác nhận tính an toàn của toàn bộ ứng dụng. Câu hỏi thường gặp về hậu lượng tử của NIST cung cấp bối cảnh triển khai các tiêu chuẩn mới.
Vì sao kết hợp ML-KEM với thỏa thuận khóa cổ điển?
Thiết kế lai dùng thành phần hậu lượng tử bên cạnh thành phần cổ điển, chẳng hạn Diffie–Hellman trên đường cong elliptic. Lợi ích dự kiến là tránh phụ thuộc hoàn toàn vào một trong hai nhóm giả định trong giai đoạn chuyển đổi.
Tuyên bố bảo mật thuộc về toàn bộ cơ chế kết hợp và giao thức, không chỉ danh sách hai thuật toán. Bên đánh giá cần biết đầu vào nào được xác thực, chúng được mã hóa biểu diễn và kết hợp ra sao, ngữ cảnh nào được gắn vào quá trình dẫn xuất, và điều gì xảy ra khi một thành phần lỗi. Nối các bí mật mà không có cấu trúc được đặc tả không phải là lập luận bảo mật.
Với người dùng, câu hỏi thiết thực không phải “Trang cài đặt có ghi an toàn trước lượng tử không?”. Mà là “Những cuộc trò chuyện và phiên bản nào thực sự dùng cấu trúc này, và bằng chứng nào hỗ trợ tuyên bố đó?”.
Livara ghi nhận điều gì?
Tài liệu bảo mật của Livara mô tả các phiên trò chuyện trực tiếp LVR1 dùng vật liệu P-256 cổ điển và ML-KEM-768, với AES-256-GCM cho nội dung. Tài liệu mô tả nhóm riêng tư LGS1 là các chuỗi người gửi được phân phối qua phiên LVR1 theo cặp. Đây là các lớp khác nhau: một tin nhắn nhóm thông thường không nhất thiết là một lượt trao đổi ML-KEM mới cho mỗi người nhận.
Hãy đọc tài liệu đó như mô tả của nhà phát triển. Việc nêu tên các thành phần mật mã chuẩn hóa không chứng minh cách kết hợp riêng của Livara đã được kiểm toán độc lập hoặc mọi bản dựng được cài đều triển khai đúng. Proof Lab nêu rõ giới hạn của minh họa trên trình duyệt: nó không chạy đầy đủ các cơ chế ratchet LVR1/LGS1 và không cấu thành kiểm toán giao thức.
Bảo vệ hậu lượng tử không bao phủ những gì?
| Câu hỏi | Vì sao chỉ ML-KEM không trả lời được |
|---|---|
| Người nhận có thể sao chép tin nhắn của tôi không? | Người nhận nhận nội dung đọc được. |
| Thiết bị của tôi có sạch phần mềm gián điệp không? | Tính toàn vẹn đầu cuối là giả định tin cậy riêng. |
| Bản sao lưu có được bảo vệ không? | Khóa sao lưu và quy tắc khôi phục cần thiết kế riêng. |
| Thay đổi thành viên nhóm có an toàn không? | Quy tắc xác thực, thành viên và thay khóa đều quan trọng. |
| Dịch vụ có giữ lại siêu dữ liệu không? | Mã hóa nội dung không tự động che giấu định tuyến hoặc thời điểm. |
| Cuộc gọi có được bảo vệ giống trò chuyện văn bản không? | Báo hiệu cuộc gọi và dữ liệu media có thể dùng giao thức khác nhau. |
Mô hình đe dọa của Livara cũng phân biệt trò chuyện riêng tư với kênh công khai và thừa nhận khả năng lộ dữ liệu ở cấp thiết bị. Đừng mở rộng tuyên bố về trò chuyện trực tiếp sang mọi khu vực của sản phẩm.
Danh sách kiểm tra khi chọn “nhắn tin FIPS 203”
Yêu cầu bộ tham số và phiên bản giao thức chính xác; mô tả xác thực đối tác và kết hợp khóa; các phiên bản ứng dụng khách được hỗ trợ; hành vi với ứng dụng khách không tương thích; cùng kiểm thử hoặc phát hiện đánh giá gắn với bản triển khai đã phân phối. Nếu nhà cung cấp tuyên bố có xác nhận FIPS, hãy yêu cầu hồ sơ xác nhận liên quan và phạm vi của nó. Chỉ việc dùng thuật toán được mô tả trong tài liệu FIPS không phải bằng chứng sản phẩm hoặc mô-đun đã được xác nhận.
Đừng suy ra thời lượng pin, thông lượng hay độ phản hồi của ứng dụng từ tên bộ tham số. Những điều đó cần phép đo có ghi rõ thiết bị, bản dựng và khối lượng công việc.
Thay đổi hữu ích cho nhắn tin là công cụ mới phục vụ tính bí mật dài hạn. Giá trị của nó phụ thuộc việc tích hợp, triển khai và ranh giới vận hành, không phải thay một nhãn tiếp thị bằng nhãn khác.
