Tôi đã vò đầu bứt tai một lúc tại sao TLS 1.3 không bao gồm bất kỳ chế độ mã hóa-sau-MAC (EtM) nào. Tất cả các sự cố trước đây trong TLS đều do MAC rồi mã hóa. Trong khi mã hóa thì MAC tránh được tất cả các sự cố do phần đệm gây ra trong quá khứ vì người nhận có thể xác minh tính toàn vẹn của thông báo mà không cần phải giải mã thông báo trước rồi xử lý phần đệm bị xáo trộn một cách chính xác.
Điều khiến tôi khó chịu về điều này là có khá nhiều bộ điều khiển vi mô có khả năng tăng tốc phần cứng AES tích hợp. Tuy nhiên, một cái gì đó giống như bội số ít mang theo cho GCM thực sự chỉ tồn tại trên CPU máy chủ và máy tính để bàn.
Mặc dù có ChaCha20-Poly1305 sử dụng nó thay vào đó có nghĩa là bạn từ bỏ việc sử dụng phần cứng AES trên bộ điều khiển vi mô. Mặc dù ChaCha20 hoạt động tốt với vi mô 32 bit nhưng nó vẫn sẽ sử dụng nhiều năng lượng hơn phần cứng AES tích hợp và có thể chậm hơn tùy thuộc vào vi mô. Ngoài ra, Poly1305 yêu cầu thực hiện một số phép tính mô-đun số lớn so với rất nhiều hàm băm.
Tôi chỉ đang vò đầu bứt tai vì không có gì sai với EtM. Tôi thậm chí đã tìm thấy một dự thảo IETF AES-CBC-HMAC nơi thực hiện EtM.Tuy nhiên, nó chưa bao giờ vượt qua được bản nháp khiến tôi cảm thấy kỳ quặc.
Chỉnh sửa:
Vì bộ mật mã CCM đã được đề cập. trong khi chạy AES ở chế độ CTR sẽ tránh được các lời tiên tri đệm. Nó không nằm trong bộ mật mã bắt buộc hoặc một trong các NÊN thực hiện các bộ. Nhìn thấy: Bộ mật mã bắt buộc thực hiện Vì vậy, về cơ bản, người ta không thể tận dụng phần cứng AES trên micro mà không có GCM. (ví dụ: nhiều máy chủ tắt CCM theo mặc định và cả Firefox và Chrome đều không bật CCM). Vì vậy, một lần nữa vẫn có vẻ kỳ lạ, không có gì ở giữa ở đây và tôi thực sự không thấy bất kỳ lý do chính đáng nào tại sao và chế độ EtM có vẻ như là một ứng cử viên sáng giá, nhưng một chế độ thậm chí chưa bao giờ được thêm vào tiêu chuẩn.
