Đây là một câu hỏi thú vị và nó phụ thuộc vào tình huống mà bạn có thể giải mã bằng khóa "sai".
Nếu hai phím $k_1$ và $k_2$ được tạo độc lập và $c$ là một bản mã được tạo trung thực theo $k_1$, sau đó giải mã $c$ Dưới $k_2$ sẽ dẫn đến một lỗi, ngoại trừ với xác suất không đáng kể. Nếu đây không phải là trường hợp, nó sẽ dẫn đến một cuộc tấn công chống lại bảo mật AEAD (kẻ tấn công chỉ gửi một bản mã dưới một khóa được chọn độc lập). Phân tích này đề cập đến trường hợp giải mã "ngẫu nhiên" hoặc "ngẫu nhiên" bằng khóa sai.
Tuy nhiên, điều này không bao gồm trường hợp $k_1, k_2, c$ đều được tạo ra một cách bất lợi. (Có thể kẻ tấn công cho bạn thấy $c$ và $k_1$, và kể từ khi $c$ giải mã thành công theo $k_1$ bạn kết luận sai rằng ai đó có khóa khác không thể chấp nhận $c$.) Các định nghĩa thông thường của AEAD không ngăn cản điều đó.Có các lược đồ AEAD tự nhiên (bao gồm cả AES-GCM) nơi có thể tạo ra các $k_1, k_2, c$ như vậy mà $c$ giải mã mà không có lỗi trong cả hai $k_1$ và $k_2$. Thuộc tính này thực sự có thể gây ra sự cố cho một số ứng dụng của AEAD, như thỏa thuận khóa được xác thực bằng mật khẩu và báo cáo lạm dụng trong tin nhắn được mã hóa.
Nếu nó là khó khăn để đưa ra bất kỳ $k_1, k_2, c$ ở đâu $c$ giải mã mà không có lỗi trong cả hai $k_1$ và $k_2$, sau đó chúng tôi nói rằng lược đồ là cam kết chính. Đôi khi thuộc tính cam kết khóa yêu cầu cung cấp một số giá trị bổ sung (ngoài bản mã và khóa thông thường) để giúp liên kết khóa với bản mã. Mã hóa cam kết khóa được nghiên cứu đây và đây.