Mật mã luồng tạo luồng khóa được kết hợp (thường là XOR-ed) với văn bản gốc - giống như luồng khóa cho OTP. AES-CTR (và các chế độ dẫn xuất như AES-GCM) có thể tạo luồng khóa bảo mật bằng máy tính mà bạn đang tìm kiếm.
- yêu cầu độ dài chỉ là vấn đề trong hệ thống kinda này?
Đối với một OTP hoàn toàn an toàn, đó có thể là vấn đề duy nhất (nếu bạn không bao gồm tính toàn vẹn/tính xác thực, kích thước và tần suất tin nhắn, v.v.). Tuy nhiên, đây cũng là một vấn đề không thể giải quyết về mặt lý thuyết, vì sẽ mất bao nhiêu bit nếu bạn muốn tăng kích thước khóa - nói cách khác, không thể tăng kích thước khóa ở cả hai bên mà không phá hủy tính bảo mật của khóa. OTP.
- chúng ta không thể thỏa hiệp tốc độ một chút (trong quá trình kéo dài) để đổi lại nhận được một khái niệm bảo mật mạnh mẽ như vậy, khiến cho việc tính toán trở nên không liên quan?
tính toán Là không liên quan đến AES-128 (hoặc AES-256 nếu bạn yêu cầu mật mã an toàn lượng tử), giả sử rằng nó không được sử dụng cho một cuộc tấn công cụ thể khác với vũ phu.
- chúng ta thậm chí không thể loại bỏ phần AES mà thay vào đó đặt otp ở giữa như một lớp khác? (lưu ý rằng vì sẽ có khái niệm mạnh mẽ hơn nên đổi lại nó có thể giảm giới hạn thấp của kích thước khóa AES)
Không, tôi cho rằng, mặc dù bạn chưa bao giờ chỉ ra AES được sử dụng ở đâu/như thế nào trong câu hỏi của bạn.
- otp có thể được coi là bảo mật do tối nghĩa không - do đó, lý do rất hay để không sử dụng nó?
Không, khái niệm lý thuyết về OTP hoàn toàn ngược lại. Nó đòi hỏi rất nhiều tài liệu quan trọng để có được sự bảo mật hoàn hảo thay vì (gần như) không có tài liệu quan trọng nào để thay vào đó chỉ ẩn thông báo.
Lưu ý rằng chỉ cần áp dụng bất kỳ chế độ nào trong số này không có nghĩa là giao thức của bạn nhất thiết phải an toàn; như một ví dụ, một cuộc tấn công chẳng hạn như EFAIL dựa vào văn bản gốc đã thay đổi để lọc bất kỳ thư nào từ các ứng dụng email; nói chung, bạn muốn sử dụng chế độ mã hóa được xác thực.
