- Người nghe thụ động có thể phá vỡ mã hóa này và/hoặc tạo các tin nhắn hợp pháp không?
Trình nghe thụ động sẽ không thể đảo ngược AES, vì vậy việc lấy bản rõ là không thể, trừ khi mỗi phiên được khởi động lại.Tuy nhiên, sơ đồ này sẽ dễ bị tấn công bằng lời tiên tri bằng văn bản gốc. Đọc tiếp.
Đối với việc tạo ra các thông điệp hợp pháp: đó không phải là một cuộc tấn công thụ động.
- Điều này cũng cung cấp xác thực vì không ai ngoại trừ người giữ khóa có thể tạo một thông báo như vậy?
Không. Nếu bạn thực hiện một người đàn ông ở giữa, bạn có thể thay đổi từng chút thông điệp và giữ nguyên phép thuật. Trong chế độ CTR tất cả các bit của bản rõ/bản mã đều độc lập với nhau. Nó cũng cho phép kẻ tấn công thực hiện các cuộc tấn công tiên tri bằng văn bản gốc (bằng cách thay đổi một chút văn bản gốc và sau đó phát hiện cách hệ thống phản hồi với nó).
- Bạn có thể sử dụng IV/nonce với việc thêm 0 vào Bộ đếm không? Tôi có nên thêm bộ đếm vào một số ngẫu nhiên (số này cũng bị đốt cháy tại nhà máy) không?
Miễn là bộ đếm không bao giờ lặp lại chế độ CTR là tương đối an toàn - miễn là nó được sử dụng đúng cách, đây không phải là trường hợp ở đây.
- Đặt gì vào phần đệm, số 0 hoặc số ngẫu nhiên? Nó thậm chí có cần thiết không?
Không, đối với chế độ CTR, việc đệm là không cần thiết.
- Sử dụng số ma thuật theo cách này có hợp lý không? Tôi có cần tạo phép thuật ngẫu nhiên và gửi nó cả không được mã hóa và được mã hóa để người nhận xác thực không?
Bạn thường sử dụng chế độ xác thực để tạo thẻ xác thực. 32 bit thường quá nhỏ, nhưng tùy thuộc vào trường hợp sử dụng, nó có thể đủ cho các hệ thống thời gian thực, v.v.
- Phương pháp chính xác/được thiết lập tốt để mã hóa và xác thực trong cài đặt như vậy là gì?
Nếu bạn chỉ có AES thì chế độ CCM sẽ là chế độ bình thường.
NB
Lược đồ bạn hiện đang mô tả có vẻ phù hợp hơn với mã hóa AES trực tiếp hoặc AES-CBC. Chẳng hạn, nếu bạn đệm và mã hóa bộ đếm, bạn có thể sử dụng nó làm IV cho AES-CBC. Nếu bạn đặt giá trị 02 trong byte đệm của tin nhắn thì bạn sẽ có phần đệm tương thích PKCS#7. Ưu điểm của điều này là các bit trong mã hóa khối AES của tin nhắn giờ đây đều phụ thuộc vào nhau, do đó phép thuật sẽ hoạt động tốt hơn một chút.
Chương trình hiện tại của bạn dường như chỉ giới hạn trong một phiên.Thông thường, bạn sẽ lấy được các khóa phiên mới cho mỗi phiên.
Ngay cả khi chế độ được thay đổi thành CBC, vẫn có một $1 \trên 2^{32}$ khả năng kẻ tấn công tạo một tin nhắn có phép thuật hợp lệ, chỉ bằng cách thử ngẫu nhiên. Phần còn lại của tin nhắn có thể sẽ bị cắt xén, nhưng việc xử lý văn bản bị cắt xén cũng có thể không phải là một ý kiến hay. Có thể thực hiện các biện pháp đối phó bổ sung để chống lại điều đó (tuy nhiên, hầu hết các biện pháp đó có thể dẫn đến các cuộc tấn công DoS).
