So sánh AES-256 và ChaCha20: Chọn thuật toán nào khi triển khai?

Nếu bạn là lập trình viên hoặc quản trị hệ thống cần chọn giữa AES-256 và ChaCha20, quy tắc thực dụng là: dùng AES-256-GCM khi hệ thống chạy trên CPU có tăng tốc AES hoặc phải tuân thủ chuẩn FIPS; dùng ChaCha20-Poly1305 (hoặc XChaCha20-Poly1305) cho thiết bị không có tăng tốc phần cứng, ứng dụng di động, hoặc khi bạn muốn giảm rủi ro do quản lý nonce. Về độ an toàn của thuật toán, hai lựa chọn tương đương; cái quyết định an toàn là cách bạn dùng chúng. Bài này tập trung vào các quyết định triển khai và những lỗi thường gặp.

Nếu cần hiểu cấu trúc bên trong của hai thuật toán, hãy đọc trước bài so sánh cấu trúc và độ an toàn của AES-256 và ChaCha20.

Câu hỏi để ra quyết định

1. Có yêu cầu tuân thủ FIPS 140 hoặc quy định tương tự không? Nếu có, chọn AES-GCM trong mô-đun mật mã đã được chứng nhận.
2. Phần cứng đích có tăng tốc AES không? Máy chủ x86 và ARM hiện đại hầu như đều có; vi điều khiển, thiết bị IoT giá rẻ và một số điện thoại đời cũ thì không.
3. Bạn sinh nonce thế nào? Nếu buộc phải sinh nonce ngẫu nhiên cho số lượng thông điệp rất lớn với cùng khóa, XChaCha20-Poly1305 hoặc AES-GCM-SIV an toàn hơn AES-GCM thuần.
4. Có thư viện uy tín hỗ trợ trên nền tảng của bạn không? Chọn thuật toán mà thư viện bạn dùng hỗ trợ tốt nhất, đã được kiểm định.

Bảng gợi ý theo tình huống

Luôn dùng mã hóa xác thực (AEAD)

Đừng dùng AES-CBC hay ChaCha20 thuần mà không có xác thực. Mã hóa không xác thực cho phép kẻ tấn công sửa bản mã, và nhiều lỗ hổng nổi tiếng như padding oracle bắt nguồn từ đó. AES-GCM và ChaCha20-Poly1305 đều là AEAD: vừa mã hóa vừa tạo thẻ xác thực, đồng thời cho phép gắn dữ liệu bổ sung (như tiêu đề, mã định danh bản ghi) được xác thực nhưng không mã hóa. Khi giải mã, nếu thẻ không khớp, hãy từ chối toàn bộ và không dùng bất kỳ phần dữ liệu nào.

Nonce: nơi phần lớn lỗi xảy ra

Quy tắc vàng

Không bao giờ dùng lại một nonce với cùng một khóa. Với cả GCM và ChaCha20-Poly1305, lặp nonce làm lộ XOR của hai bản rõ và có thể cho phép giả mạo thẻ xác thực. Với GCM, hậu quả đặc biệt nghiêm trọng vì kẻ tấn công có thể khôi phục khóa xác thực.

Các chiến lược sinh nonce

• Bộ đếm: an toàn nếu bạn đảm bảo bộ đếm không bao giờ quay lại, kể cả khi khởi động lại hay chạy nhiều tiến trình song song. Đây là cách TLS làm.
• Ngẫu nhiên 96 bit (GCM, ChaCha20 IETF): chấp nhận được khi số thông điệp với một khóa còn ở mức vừa phải; với khối lượng rất lớn, xác suất trùng tăng lên, cần xoay vòng khóa thường xuyên.
• Ngẫu nhiên 192 bit (XChaCha20): không gian đủ lớn để sinh ngẫu nhiên mà không phải lo trùng trong thực tế.
• Thuật toán kháng lạm dụng nonce (AES-GCM-SIV): nếu lỡ lặp nonce, chỉ lộ việc hai bản rõ giống nhau chứ không mất toàn bộ bảo mật.

Chọn thư viện thay vì tự cài đặt

Đừng tự viết AES hay ChaCha20. Các lựa chọn phổ biến:

• libsodium: API đơn giản, mặc định an toàn, hỗ trợ XChaCha20-Poly1305 và AES-256-GCM khi có phần cứng.
• Thư viện chuẩn của ngôn ngữ: gói crypto của Go, thư viện cryptography của Python, Web Crypto API trong trình duyệt (hỗ trợ AES-GCM).
• Tink: thư viện của Google thiết kế để khó dùng sai, có quản lý khóa và xoay vòng tích hợp.
• OpenSSL, BoringSSL: mạnh nhưng API cấp thấp, dễ dùng sai nếu không cẩn thận.

Cấu hình TLS cho máy chủ

Trong TLS 1.3, cả ba bộ mã AES-128-GCM, AES-256-GCM và ChaCha20-Poly1305 đều nên được bật. Một số máy chủ hỗ trợ cơ chế ưu tiên ChaCha20 khi client tự xếp nó lên đầu, dấu hiệu cho thấy client không có tăng tốc AES. Cách này phục vụ tốt cả máy tính lẫn điện thoại. Với TLS 1.2, chỉ giữ các bộ mã ECDHE kèm AEAD, tắt bộ mã CBC và RC4. Nền tảng TLS được giải thích trong bài chứng chỉ SSL/TLS hoạt động như thế nào.

Quản lý khóa quan trọng hơn chọn thuật toán

• Sinh khóa bằng bộ sinh số ngẫu nhiên an toàn mật mã, không dùng mật khẩu trực tiếp làm khóa; nếu cần, dẫn xuất qua Argon2 hoặc HKDF phù hợp ngữ cảnh.
• Lưu khóa trong KMS, HSM hoặc kho khóa của hệ điều hành, không lưu trong mã nguồn hay biến môi trường dùng chung.
• Xoay vòng khóa định kỳ và theo lượng dữ liệu đã mã hóa.
• Áp dụng mã hóa phong bì cho dữ liệu lớn, như mô tả trong bài mã hóa dữ liệu trên đám mây.
• Ghi kèm phiên bản thuật toán và mã định danh khóa với mỗi bản mã để dễ chuyển đổi về sau.

Danh sách kiểm tra trước khi đưa vào sản xuất

1. Đang dùng AEAD, không phải chế độ không xác thực.
2. Chiến lược nonce đã được ghi rõ và kiểm thử, kể cả khi chạy song song.
3. Thư viện mật mã được cập nhật, nằm trong danh sách được cộng đồng tin dùng.
4. Khóa không xuất hiện trong nhật ký, thông báo lỗi hay bản sao lưu không mã hóa.
5. Lỗi giải mã được xử lý thống nhất, không tiết lộ chi tiết cho người dùng cuối.

Làm đúng các điểm trên, bạn có thể yên tâm với cả AES-256 lẫn ChaCha20, và chọn giữa chúng chỉ còn là chuyện hiệu năng và tuân thủ.