Giải thích mã hóa AES từ đầu

Tóm lại một câu: AES là thuật toán mã khối tiêu chuẩn toàn cầu — nó xáo trộn các khối 16 byte dưới khóa 128, 192 hoặc 256 bit — còn chế độ bạn chạy nó (GCM, CBC, CTR, ECB) quyết định cách các khối được nối với nhau, IV dùng để làm gì, và có phát hiện được việc bị giả mạo hay không; hãy chọn GCM trừ khi bạn có lý do không làm vậy.

Bản thân AES là gì (FIPS 197)

Mã khối. AES (thiết kế Rijndael, được NIST chuẩn hóa năm 2001 thành FIPS 197) mã hóa đúng 16 byte mỗi lần. Độ dài khóa của bạn — 16, 24 hoặc 32 byte — chọn AES-128, -192 hoặc -256 và số vòng nội bộ (10, 12, 14). Mỗi vòng trộn khối với các khóa vòng được dẫn xuất từ khóa của bạn qua bảng thế, dịch hàng và trộn cột. Không có tấn công thực tế nào phá vỡ chính thuật toán: các lỗi thực tế hầu hết đến từ chế độ, IV hoặc quản lý khóa sai, và đó là nội dung phần còn lại của trang này.

Vì sao cần chế độ? Vì thông điệp hiếm khi dài đúng 16 byte. Chế độ nối các lần mã hóa khối lại với nhau: ECB chỉ mã hóa từng khối độc lập; CBC XOR mỗi khối với bản mã trước đó; CTR mã hóa một bộ đếm rồi XOR với dữ liệu như mã dòng; GCM xây trên CTR và thêm thẻ xác thực. AES giữ nguyên — chế độ thay đổi mọi thứ về đảm bảo bạn nhận được.

Khóa và mật khẩu. Khóa AES là 16, 24 hoặc 32 byte ngẫu nhiên. Mật khẩu do người dùng nhập thì không như vậy: tùy chọn Password của trang này dẫn xuất một khóa đúng chuẩn bằng PBKDF2-HMAC-SHA256 (mặc định 600.000 vòng lặp, mức nền OWASP 2023 — xem HMAC Generator để biết chi tiết KDF). Không bao giờ dùng trực tiếp chuỗi mật khẩu làm khóa AES: entropy của nó chỉ là một phần nhỏ so với độ dài.

So sánh bốn chế độ

Chế độ	IV / nonce	Tính toàn vẹn	Ghi chú
GCM	12 byte, duy nhất cho mỗi thông điệp	Có — thẻ 96..128 bit	AEAD: mặc định được khuyến nghị ở mọi nơi (TLS 1.3, SSH, định dạng tệp). Cũng nhận AAD.
CBC	16 byte, không đoán trước được	Không	Đệm PKCS#7; cổ điển nhưng cần MAC đi kèm. Lỗi oracle đệm là cái bẫy kinh điển của CBC.
CTR	bộ đếm ban đầu 16 byte	Không	Không đệm, hoạt động như mã dòng, truy cập ngẫu nhiên; tái sử dụng nonce với cùng khóa làm lộ phép XOR của hai bản rõ.
ECB	không có	Không	Các khối giống nhau → bản mã giống nhau. Minh họa “chim cánh cụt ECB”. Chỉ để tương thích.

Quy tắc IV trong một đoạn. IV không phải bí mật — hãy gửi nó cùng bản mã — nhưng quy tắc về tính duy nhất khác nhau: CBC cần IV không đoán trước được; GCM và CTR chỉ yêu cầu không bao giờ tái sử dụng cùng một nonce với cùng khóa (tái sử dụng nonce trong GCM còn tệ hơn: nó làm lộ khóa xác thực). Nút Random IV của trang dùng bộ sinh số ngẫu nhiên an toàn của trình duyệt; nút Toàn số 0 chỉ để tái tạo vector kiểm thử, không dùng cho thông điệp thật.

Đệm. CBC và ECB cần đủ khối, nên đệm PKCS#7 thêm từ 1 đến 16 byte, mỗi byte có giá trị bằng độ dài phần đệm. Đó là lý do bản mã CBC có thể dài thêm tối đa 16 byte và vì sao giải mã bằng khóa sai thường báo lỗi đệm. CTR và GCM hoạt động như mã dòng và không cần đệm — độ dài bản mã đúng bằng độ dài bản rõ (thử mẫu ở chế độ CTR: 43 byte vào, 43 byte ra).

CFB và OFB (hai chế độ cổ điển còn lại) không được cài đặt trên trang này: chúng hoạt động như mã dòng giống CTR nhưng không có ưu điểm gì hơn, và chủ yếu còn tồn tại trong các giao thức cũ.

GCM bổ sung gì (AEAD, thẻ, AAD)

Mã hóa có xác thực. GCM = mã hóa CTR + bộ xác thực GHASH trên bản mã, IV và AAD. Thẻ đầu ra là dấu vân tay của tất cả: thay đổi một bit của bản mã, IV hoặc AAD là thẻ không còn khớp, nên bên nhận có thể chứng minh thông điệp còn nguyên vẹn và đến từ người giữ khóa. CBC+HMAC chỉ đạt được điều tương tự nếu ghép đúng cách (mã hóa rồi MAC) — GCM đạt điều đó ngay từ thiết kế.

AAD. Dữ liệu xác thực bổ sung được truyền ở dạng rõ nhưng vẫn được thẻ bảo vệ: tiêu đề giao thức, tên tệp, mã định danh thuật toán. Bên nhận phải cung cấp đúng các byte AAD giống hệt, nếu không kiểm tra thẻ sẽ thất bại — đó chính là mục đích.

Độ dài thẻ. Thẻ 128 bit mặc định là khuyến nghị; thẻ ngắn hơn (96..120 bit) đổi khả năng chống giả mạo lấy kích thước nhỏ hơn. Dưới 96 bit, các chứng minh bảo mật của GCM suy giảm nhanh, đó là lý do trang này dừng ở mức đó.

Thảm họa nonce. Tái sử dụng nonce GCM 12 byte với cùng khóa làm lộ phép XOR của hai bản rõ và khóa phụ xác thực — sau đó có thể giả mạo mọi thông điệp tương lai dùng khóa đó. Các hệ thống không đảm bảo được tính duy nhất nên dùng biến thể chịu được lạm dụng nonce (AES-GCM-SIV, RFC 8452).

Giá trị neo — tái tạo chúng trên trang này

Dòng đầu tiên là ví dụ FIPS 197 nổi tiếng với một khối; các dòng còn lại được tạo bằng một triển khai native độc lập (OpenSSL qua Node.js) và được kiểm tra lại trên các engine của trang này. Dán khóa, IV và dữ liệu vào trang để tái tạo từng dòng.

Trường hợp	Đầu vào	Kết quả mong đợi
AES-128 một khối (theo kiểu FIPS 197)	key `000102..0f`, plaintext `00112233..ff`	69c4e0d86a7b0430d8cdb78070b4c55a
AES-128-GCM	key `000102..0f`, IV `606162..6b`, plaintext `0011..ef` ×2	ct 275f095bedfda377063fee326128892188377b410698ed03a022b9971bb4bdbe, tag 87ea7770714048977de2fd8dac645ecf
AES-256-GCM, giống nhưng AAD `deadbeef`	key `000102..1f`	ct eacab966ff15e518f48f5390be502fbc2756ccee0dcfff36a282c50bf5593ae7, tag aead900e895c88252d0388d7aefce5c8
AES-256-CBC	key `000102..1f`, IV `101112..1f`, plaintext `0011..ef` ×2	0e2392dd6f690b44a5a1b4fdff3b7f83cb9ab59d9900119cc5f83e062d95fb643b1a94b514ea2f3b95f84c900b5c98a8
AES-256-CTR (cùng đầu vào với CBC ở trên)	43-byte plaintext → 43-byte ciphertext	e9d2cdb9f661359178ed366dfa3a4671f8e20efd723f090eb7d1d524d480fd3c

Những lỗi thường gặp

Dùng ECB vì nó không cần IV. Sự tiện lợi này chính là cái bẫy: các mẫu khối lộ thẳng vào bản mã (mã hóa một bitmap và bạn vẫn thấy được hình ảnh). ECB chỉ chấp nhận được với một khối đơn lẻ hoặc khóa ngẫu nhiên đúng 16 byte — trong thực tế, không bao giờ nên chọn nó.
Tái sử dụng nonce/IV. Với GCM hoặc CTR dùng chung một khóa, đây là lỗi duy nhất làm hỏng mọi thứ cùng lúc. Các hệ thống dựa trên bộ đếm (nút Random IV của trang này) tồn tại để khiến điều đó không thể xảy ra.
Coi IV là bí mật. Không phải vậy. Hãy lưu trữ hoặc truyền nó cùng bản mã. Giấu IV không mang lại lợi ích gì và dễ dẫn đến tái sử dụng.
Dùng mật khẩu làm khóa. "hunter2hunter2hunter2hunter2" dài 32 byte nhưng không có 256 bit entropy — đó là một từ trong từ điển cộng thêm phần đệm. Hãy dẫn xuất khóa bằng PBKDF2 (có sẵn trên trang này) hoặc tạo khóa ngẫu nhiên.
Cho rằng CBC phát hiện được việc bị giả mạo. Lật một bit trong bản mã CBC thì giải mã vẫn “thành công” nhưng bản rõ đã bị hỏng âm thầm. Chỉ thẻ của GCM (hoặc HMAC tường minh) mới làm cho việc giả mạo lộ ra.
So sánh bản mã GCM để kiểm tra bằng nhau. Với nonce ngẫu nhiên, cùng một bản rõ được mã hóa khác nhau mỗi lần — đó là tính năng. Mã hóa tất định là một công cụ khác, chuyên dụng hơn.

Câu hỏi thường gặp

AES-128 còn an toàn không, hay tôi cần 256? Cả hai đều an toàn trước các kẻ tấn công thực tế; các cuộc tấn công đã biết chỉ làm giảm một phần nhỏ biên an toàn. AES-256 quan trọng chủ yếu với dữ liệu bí mật dài hạn và khả năng chống lượng tử (thuật toán Grover làm giảm một nửa độ mạnh khóa, khiến AES-256 tương đương khoảng 128 bit).

Vì sao openssl enc không hỗ trợ GCM? Lệnh enc có trước AEAD và không có chỗ để mang thẻ xác thực; OpenSSL 3.3 đã thêm lệnh aesgcm riêng. Kết quả GCM của trang này giữ thẻ trên một dòng riêng để bạn có thể di chuyển cả hai một cách rõ ràng.

Bọc khóa (AES-KW) là gì? Chế độ chuyên dụng để mã hóa các khóa khác theo từng khối 64 bit cố định và có kiểm tra toàn vẹn riêng. Trang này không cung cấp chế độ này vì đầu vào và đầu ra có dạng của khóa, không phải dạng của thông điệp — dùng sai là chuyện thường gặp.

Vì sao bản mã CTR có độ dài bằng bản rõ, còn bản mã CBC dài hơn? CTR và GCM hoạt động như mã dòng (không đệm); CBC/ECB đệm đến đủ một khối 16 byte theo PKCS#7. Chênh lệch độ dài là có chủ đích, không phải lỗi.

Tôi có thể giải mã dữ liệu được mã hóa ở nơi khác không? Có, nếu bạn biết chính xác chế độ, khóa, IV (và với GCM là thẻ xác thực). Các dòng kết quả của trang này ghi lại đầy đủ các thông số đó để bạn chuyển tham số giữa các công cụ — khung OpenSSL phía trên hiển thị các dòng lệnh tương ứng.

Mã hóa / Giải mã AES