Tại sao mật mã khối chủ yếu được sử dụng làm mật mã dòng?
Chế độ CTR không cần phần đệm như chế độ CBC đã gây ra nhiều cuộc tấn công trong nhiều năm được gọi là cuộc tấn công tiên tri đệm [1] [2]. Cuối cùng, CBC bị xóa khỏi TLS, TLS 1.3 chỉ có mật mã chế độ CTR (rfc 8446).
+---------------------------------+-------------+
| Mô tả | Giá trị |
+---------------------------------+-------------+
| TLS_AES_128_GCM_SHA256 | {0x13,0x01} |
| | |
| TLS_AES_256_GCM_SHA384 | {0x13,0x02} |
| | |
| TLS_CHACHA20_POLY1305_SHA256 | {0x13,0x03} |
| | |
| TLS_AES_128_CCM_SHA256 | {0x13,0x04} |
| | |
| TLS_AES_128_CCM_8_SHA256 | {0x13,0x05} |
+---------------------------------+-------------+
Các cuộc tấn công và quyết định của TLS đã làm tăng việc sử dụng chế độ CTR. Hãy nhớ rằng hầu hết tất cả bảo mật internet đều dựa trên TLS. Theo khảo sát của SSLlabs, %46,6 trang web chấp nhận TLS 1.3 ( Hỗ trợ giao thức )
Cả chế độ CTR lẫn CBC hay CFB (tất cả các hoạt động ở chế độ lưu trữ) đều không có MAC theo thiết kế. Để có máy mac, hãy sử dụng HMAC hoặc sử dụng GCM, CCM, Poly1305, v.v.
Nếu chúng ta nói về chế độ về mặt lý thuyết thì CBC và CTR chỉ có thể cung cấp Ind-CPA. Ngoài cái này cần tính toàn vẹn cho Ind-CCAx. Mặt khác, mã hóa được xác thực (GCM,CCM,Poly1305) cung cấp bảo mật cao hơn Ind-CCAx,
Điều này không làm giảm kích thước khối thuật toán hiệu quả xuống 1 bit khi một bit được ánh xạ tới một bit khác tùy thuộc vào các bit luồng khóa?
Chà, nếu bạn sử dụng CBC và áp dụng phần đệm, thì bạn thực thi nhiều nội dung hơn là loại bỏ các bit không cần thiết của khối. Trong cả hai trường hợp, số khối được mã hóa gần như giống nhau (ngoại trừ nếu khối đã đầy, thì đối với PKCS#7, người ta cần thêm một khối). Sau đó, áp dụng phần đệm và bỏ phần đệm là các chức năng bổ sung để áp dụng. Chế độ CTR cần x-hoặc luồng.
Như đã lưu ý trong các nhận xét, chế độ CTR có khả năng song song hóa cao, thậm chí cho phép truy cập ngẫu nhiên hoặc lưu trữ trước luồng. Các màn trình diễn OpenSLL bên dưới trên máy của tôi
tốc độ mởssl -evp aes-128-cbc aes-128-ctr
| loại |
16 byte |
64 byte |
256 byte |
1024 byte |
8192 byte |
16384 byte |
| aes-128-cbc |
818912.47k |
1365115.22k |
1404590.75k |
1409671.85k |
1410523.14k |
1411497.98k |
| aes-128-ctr |
561928.57k |
1899517.87k |
3908505.17k |
5220669.78k |
5835377.32k |
5876869.80k |
Như chúng ta có thể thấy, ngoại trừ các tin nhắn rất ngắn CTR đánh bại CBC trong AES-NI.
Sẽ không tốt hơn nếu giữ kích thước khối của mật mã?
Không
Chúng ta phải đối phó với phần đệm và các vấn đề không an toàn của nó, tại sao không loại bỏ nó hoàn toàn khi chúng ta có chế độ CTR.
Nó cũng tăng kích thước dữ liệu lên tối đa 16 byte cho AES.
Chế độ CTR theo thiết kế sử dụng PRF thay vì PRP (mật mã khối là của PRP), điều này cung cấp nhiều chức năng hơn để sử dụng - tương tự như khi chúng tôi sử dụng ChaCha20. Trong chế độ CBC, chúng tôi phải sử dụng PRP.
Tất nhiên, không có gì là hoàn hảo! Mỗi chế độ đều có ưu và nhược điểm. Tùy thuộc vào bối cảnh, người ta có thể thích cái này hơn cái khác. Theo lẽ thường, trong mật mã hiện đại, chúng tôi thích các chế độ mã hóa được xác thực như AES-GCM (có thể với SIV) và ChaCha20-Poly1305 (xChaCha20-1305 tốt hơn cho các nonce 192 bit).
