aes/

Trước hết hãy xem đã chọn đúng định dạng chưa: cùng 32 ký tự, chọn string là 32 byte, chọn hex mới là 16 byte. Khóa AES phải dài 16, 24 hoặc 32 byte; trừ ECB và GCM, IV phải dài đúng 16 byte. Công cụ này không tự bù số 0 hay cắt bớt, số byte hiện tại được hiển thị cạnh tiêu đề của ô Khóa và IV. Khi chọn string, số byte được tính theo bộ ký tự đã chọn, một chữ Hán trong UTF-8 chiếm 3 byte. Nếu backend xử lý mật khẩu trước, ví dụ bù số 0 hoặc băm, hãy tính ra các byte cuối cùng trước rồi nhập vào ở định dạng hex hoặc base64.

Nghĩa là khối cuối cùng sau khi giải mã không khớp với quy tắc padding đã chọn. Thường là một trong các mục khóa, IV, chế độ hoặc kiểu padding không giống lúc mã hóa, cũng có thể do bản mã được sao chép chưa đầy đủ. Hãy đối chiếu từng tham số với bên mã hóa; chọn sai định dạng khóa hoặc định dạng bản mã (hex hay base64) cũng gây ra lỗi này. ZeroPadding và NoPadding không kiểm tra padding nên sẽ không báo lỗi này, nhưng nếu tham số sai thì kết quả sẽ là chuỗi ký tự lộn xộn.

Hãy kiểm tra IV trước. Khi bản mã dài hơn một khối, nếu IV sai ở chế độ CBC và CFB thì chỉ khối 16 byte đầu tiên bị lỗi, phần phía sau vẫn bình thường và cũng không báo lỗi padding; biểu hiện là đầu văn bản bị loạn chữ còn phần sau đúng. Nếu có thông báo kết quả không phải văn bản hợp lệ, cũng có thể bộ ký tự không khớp với bên mã hóa, ví dụ bên kia dùng GBK. Đổi định dạng đầu ra sang hex để xác nhận trước xem bản thân các byte giải mã ra có đúng không.

Nghĩa là một trong các mục khóa, IV, AAD, độ dài Tag không giống lúc mã hóa, hoặc bản mã đã bị sửa. Công cụ này coi đoạn cuối của dữ liệu đầu vào là Tag, độ dài theo tùy chọn "Độ dài Tag" (mặc định 128 bit, tức 16 byte), nên bản mã và Tag phải được nhập liền nhau; nếu bên kia gửi Tag riêng thì hãy nối nó vào sau bản mã trước. Định dạng AAD mặc định là hex, khi nhập nội dung dạng string nhớ đổi định dạng; nếu lúc mã hóa không dùng AAD thì khi giải mã cũng phải để trống.

Hãy đối chiếu theo thứ tự: chế độ và padding, định dạng và số byte của khóa và IV, bộ ký tự, định dạng đầu vào và đầu ra. Bản rõ ở định dạng string không bị cắt khoảng trắng đầu cuối, thừa một dấu xuống dòng ở cuối đã là dữ liệu khác. Ở đây CTR, CFB, OFB cũng được bù theo kiểu padding đã chọn, nên khi chọn PKCS5Padding thì bản mã dài hơn bản rõ; nếu backend dùng NoPadding thì ở đây cũng phải chọn NoPadding. CFB ở đây là phản hồi nguyên khối 128 bit, nên sẽ không khớp nếu bên kia dùng CFB8.

Cứ theo định dạng đầu ra của bên kia: toàn ký tự 0-9, a-f là hex; có chữ hoa lẫn chữ thường, dấu +, / hoặc kết thúc bằng = là base64. Khi giải mã, chọn sai không phải lúc nào cũng báo lỗi ngay, vì mọi ký tự hex đều là ký tự base64 hợp lệ, chỉ là giải ra các byte sai, cuối cùng hiện thành lỗi "không phải bội số của 16" hoặc "padding không hợp lệ". Base64 dùng - và _ (dạng an toàn cho URL) hoặc thiếu dấu = vẫn nhận được; khoảng trắng, dấu hai chấm và tiền tố 0x trong hex sẽ bị bỏ qua.

Chỉ lưu trong localStorage của trình duyệt trên thiết bị này, không tải lên, mã nguồn trang không có bất kỳ yêu cầu mạng nào. Sau mỗi lần mã hóa hoặc giải mã thành công sẽ ghi một mục, giữ tối đa 20 mục; nếu đầu vào hoặc kết quả vượt quá 20.000 ký tự thì không ghi. Mỗi mục có tham số, IV, AAD, đầu vào và kết quả, cùng một dấu vân tay 8 ký tự tính từ khóa (chuỗi ký tự sau dấu # trong mục, dùng để phân biệt có phải cùng một khóa hay không), không lưu bản thân khóa, nên sau khi bấm "Điền lại" bạn phải nhập lại khóa. Có thể xóa riêng từng mục; trên máy tính dùng chung, dùng xong hãy bấm "Xóa lịch sử".

Không. Ở đây không có nút tạo, khóa và IV phải tự nhập. Cùng bản rõ, khóa, IV và tham số thì kết quả mã hóa lần nào cũng giống nhau, chỉ có padding ISO10126 trộn thêm byte ngẫu nhiên nên kết quả mới khác. Khi cần giá trị ngẫu nhiên, bạn có thể tự tạo, ví dụ lệnh openssl rand -hex 16 trên dòng lệnh sẽ in ra 16 byte, chọn định dạng hex rồi điền vào là được.