Nhược điểm của kích thước khối rất lớn trong mật mã khối là gì?

Vấn đề đệm: Nếu một người sử dụng chế độ mật mã khối như CBC, thì họ cần đệm và hãy nhớ rằng đệm luôn được áp dụng bất kể kích thước. Ngay cả khi kích thước $65536*k$ sau đó một khối đầy đủ mới được yêu cầu. Không rõ làm thế nào một người có thể áp dụng phần đệm PKCS#7 vì nó hỗ trợ các khối lên tới 256 byte. Có những phần đệm dễ dàng khác để áp dụng như thêm 1 sau đó là số 0 rồi mã hóa kích thước phần đệm.

Trong mật mã hiện đại, chúng tôi không sử dụng các chế độ đệm, chúng tôi đang sử dụng các chế độ như chế độ AES-GCM và ChaCha20-Poly1305 là các chế độ mã hóa được xác thực bằng mái chèo.

Số vòng: Nếu chúng ta xem xét Rijndael yêu cầu một vòng bổ sung cho mỗi 32 khối, thì một mật mã khối tương tự sẽ yêu cầu 2048 vòng để đạt được mức độ bảo mật tương tự (hãy nhớ rằng đây thực sự là một ước tính sơ bộ). Điều này tạo ra độ trễ cho đầu ra đầu tiên. Chậm hơn ~148 lần so với đầu ra đầu tiên của AES-256. Mặc dù độ trễ này có thể không quan trọng đối với việc nhắn tin trên Signal, nhưng có những nơi độ trễ không phù hợp.

Vấn đề về kích thước khóa: Trong SPN, chúng tôi sử dụng khóa để x-hoặc các giá trị làm tròn. Nếu kích thước khóa nhỏ hơn kích thước khối, đây thực sự là một vấn đề bảo mật có thể dẫn đến các khả năng mới của các cuộc tấn công tuyến tính và vi sai. Do đó, người ta cần tạo, trao đổi truyền và lưu trữ khóa có kích thước 65536 bit.

Vấn đề triển khai: trong khi dành thời gian triển khai liên tục trên phần mềm sang một bên, trong phần cứng, kích thước như vậy sẽ cần nhiều diện tích hơn để triển khai. Điều này sẽ làm tăng chi phí triển khai và sẽ yêu cầu nhiều năng lượng hơn so với các mật mã khối có kích thước nhỏ hơn.

Vấn đề kích thước tin nhắn: đối với các tin nhắn ngắn hơn kích thước khối, điều này rất phổ biến trong cơ sở dữ liệu, nếu chế độ CBC được sử dụng, điều này sẽ tạo ra vấn đề về kích thước. Có với chế độ dựa trên CTR, người ta có thể giảm thiểu điều này, tuy nhiên, người ta sẽ dành nhiều thời gian hơn để mã hóa/giải mã so với các mật mã có kích thước khối ngắn hơn.

Đăng lượng tử: Không có lợi thế này về hậu lượng tử vì AES-256 đã được bảo mật trước thuật toán tối ưu của Grover.

Chúng ta có cần mật mã khối lớn hơn 128-bit không?

Đúng. Ví dụ: nếu AES được chuẩn hóa chính xác như Rijndael, thì các vấn đề về nonce ngẫu nhiên của AES-GCM sẽ không còn là vấn đề đối với chúng tôi nữa. Nonces ngẫu nhiên có kích thước 256 sẽ an toàn khi va chạm dưới cùng một khóa.

Chúng tôi có mật mã khối lớn hơn 256 bit không?

Có, ChaCha20 thân thiện với CPU có đầu ra 512 bit ở chế độ CTR. Với XChaCha20, nó có khả năng bảo vệ tốt trước các va chạm nonce với kích thước nonce 192-bit của nó.