Tôi chưa quen với mật mã,
Vâng, chúng tôi có thể thấy cách bạn sử dụng thuật ngữ.
Tôi chưa quen với mật mã, tôi đang cố gắng thiết kế một môi trường đường dẫn an toàn để truyền tin nhắn nhanh chóng.
Một từ khác cho "đường ống" là "kênh" và việc chuyển thông điệp còn được gọi là "vận chuyển". Vì vậy, bạn cần một kênh an toàn để bảo mật lớp vận chuyển. TLS như tên cho thấy chỉ có vậy.
Để giảm kích thước Khóa, tôi dự định mã hóa tin nhắn bằng khóa phiên AES (cho một phiên hoặc một kỷ nguyên) và trong mỗi phiên, tôi dự định mã hóa từng tin nhắn bằng các khóa nhẹ như DES.
Vì vậy, theo văn bản này, bạn đang mã hóa cả tin nhắn bằng AES và DES? DES sử dụng khóa 56 bit (mặc dù thường được lưu trữ trong 64 bit/8 byte bao gồm cả bit chẵn lẻ). Vì vậy, vâng, các khóa thực sự "nhẹ", nhưng bản thân mật mã thì chắc chắn là không. Bộ ba DES hơi an toàn chậm hơn AES và đó không phải là nhẹ nhất mật mã; hơn nữa, nó yêu cầu khóa 168/192 bit.
Các nhà mật mã học hiện đại tròn mắt khi từ "DES" được lẩm bẩm cho bất kỳ giao thức hoặc giấy tờ mới nào. Một mật mã (luồng) nhẹ hiện đại - như đã đề cập trong các nhận xét - thường có ý nghĩa hơn nhiều.
Nhưng một vấn đề cơ bản mà tôi đang gặp phải là làm thế nào để kênh này có khả năng phục hồi trước sự tấn công của DOS?
Mặc dù bạn có thể thử và thực hiện trước một số thao tác tối thiểu - ví dụ: xác thực MAC qua bộ đếm tin nhắn - khả năng phục hồi chống lại các cuộc tấn công DOS thường được thực hiện ở mức thấp hơn; một khi bạn cần thực hiện mã hóa/giải mã thì cũng có thể như vậy.
Tôi có cần xóa một số tin nhắn hoặc cung cấp dòng thời gian cho tất cả các tin nhắn trong kênh mà sau đó tin nhắn sẽ bị ghi, ví dụ: Thời gian tồn tại?
Bạn có thể sử dụng TTL.Nhưng TTL có vẻ chủ yếu thú vị nếu bạn định chuyển tiếp thư chẳng hạn - và chúng tôi không biết liệu giao thức của bạn có được thiết kế để thực hiện điều đó hay không.
