Kịch bản
Sử dụng AES 256 với chế độ CBC. (Xác thực được thực hiện riêng. Bỏ qua ở đây.)
Mục tiêu (giải thích thêm sau)
Để tránh gửi IV không được mã hóa.
Nhưng vì điều này đang được thực hiện bằng cách sử dụng .NET có chức năng buộc chúng tôi phải sử dụng IV, nên chúng tôi không thể chỉ thêm 16 byte ngẫu nhiên vào trước rồi loại bỏ 16 byte đầu tiên sau khi giải mã.
Kế hoạch
Thêm 16 byte ngẫu nhiên ("IV1"), và bên cạnh đó, hãy sử dụng 16 byte có giá trị bằng 0 làm IV ("IV0"). Sau đó gửi bản mã mà không có 16 byte đầu tiên.
Việc giải mã sẽ được thực hiện bởi người nhận trước tiên xác định khối đầu tiên của bản mã sẽ là (đối với khóa AES đó, cho bất kỳ tin nhắn) bằng cách mã hóa thứ gì đó theo cách đã nói ở trên (chỉ được thực hiện một lần cho mỗi khóa) và lấy 16 byte đầu tiên của bản mã thu được.
Sau đó, họ thêm các byte đó vào bản mã đã cắt-nhận-được để lấy bản mã chưa cắt ban đầu, sau đó giải mã nó bằng IV ("IV0") trong số 16 byte giá trị 0 (tức là chúng sử dụng chức năng giải mã của .NET, cung cấp cho nó IV cần thiết là 16 số 0 đó).
Sau đó, chúng loại bỏ 16 byte đầu tiên của kết quả (được nhận từ .NET sau khi .NET loại bỏ 16 byte đầu tiên đầu tiên là IV) vì đó là 16 byte ngẫu nhiên được thêm vào trước ("IV1").
Nhưng tại sao?
Giao tiếp IV trong bản rõ mang lại lợi thế cho kẻ tấn công vũ phu - chúng chỉ có thể giải mã một khối (16 byte) và so sánh nó với IV để kiểm tra xem khóa có đúng không. (Có lẽ có nhiều kênh tấn công hơn mà tôi không biết.)
Vì vậy, câu hỏi của tôi là
Kế hoạch này có vẻ ổn, hay có một số cạm bẫy trong đó?
