Tôi cho rằng việc lấp đầy tất cả các byte được đệm bằng vô nghĩa ngẫu nhiên và byte cuối cùng với số lượng byte được đệm sẽ an toàn hơn nhiều. Tại sao đó không phải là trường hợp trong một tiêu chuẩn đệm được phân phối rộng rãi như vậy? Chẳng phải ví dụ dưới đây an toàn hơn sao?
53 65 63 72 65 74 20 74 65 78 74 2e --> 53 65 63 72 65 74 20 74 65 78 74 2e 5a 2c 12 04
Điều này về cơ bản được gọi là phần đệm ISO 10126, tương thích với phần đệm ANSI X9.23.
Trước hết, cần lưu ý rằng các cuộc tấn công tiên tri đệm chỉ là một phần của tập hợp rộng hơn các cuộc tấn công tiên tri văn bản rõ.Vì vậy, nếu bản rõ được giải mã có thể tạo ra bất kỳ lỗi nào, thì các vấn đề tương tự có thể xuất hiện khi hệ thống đang cố gắng áp dụng bản rõ. Ví dụ, thật dễ dàng để tạo một tấn công oracle văn bản gốc sử dụng lỗi của bộ giải mã XML. Thậm chí dễ dàng hơn: nếu các khối văn bản gốc bao gồm phần đệm từ phía bên tay trái, thì rõ ràng nó cũng sẽ thất bại trước một cuộc tấn công tiên tri phần đệm.
Thứ hai, một bản mã bây giờ sẽ được chấp nhận (tức là không tạo ra lỗi đệm) 1 lần trong số 256/8 = 32 lần (byte cuối cùng có giá trị 01 đến 08) thay vì khoảng một lần trong 256 lần (byte cuối cùng có giá trị 01 hoặc các byte cuối cùng có giá trị 02 02 vân vân.). Điều này ngăn cản việc sử dụng phần đệm cho tính toàn vẹn/tính xác thực của thông báo.
Thứ ba, bạn đã giảm thiểu cuộc tấn công tiên tri đệm, nhưng bạn chưa loại bỏ hoàn toàn nó. Rốt cuộc, byte cuối cùng vẫn cần được đánh giá. Chúng tôi xem xét một mật mã bị phá vỡ nếu bất cứ điều gì có thể được học từ văn bản gốc.
Cuối cùng, bạn vẫn chưa loại bỏ chi phí đệm.
Nếu bạn vẫn giả sử chi phí hoạt động thì bạn cũng có thể thêm thẻ xác thực, được tạo bằng cách sử dụng MAC hoặc mật mã được xác thực. Đây là lý do tại sao chúng ta không quan tâm lắm đến thuộc tính đệm. Chúng tôi có thể sử dụng chế độ không yêu cầu đệm, thêm thẻ xác thực và có chế độ mật mã với các thuộc tính bảo mật tốt hơn, đồng thời hạn chế mở rộng thông báo.
