AEAD có cung cấp bất kỳ lợi ích nào đối với mật mã thô trong cài đặt này không?

Tôi đang làm việc trên một kho lưu trữ dữ liệu mật mã, nơi các đốm màu cần được xác định và tham chiếu thông qua hàm băm của dữ liệu được mã hóa. Hãy nghĩ cây Merkle với các nút được mã hóa. Trong một cài đặt như vậy mà hàm băm đã thiết lập tính xác thực (giả sử bản thân hàm băm không bị hỏng), có bất kỳ giá trị nào khi sử dụng AEAD thay vì chỉ sử dụng trực tiếp mật mã không?

Tôi tin rằng điều này khác với chủ đề mã hóa-sau đó-MAC cổ điển vì không có hàm băm hoặc MAC nào được lưu trữ cùng với đốm màu để xác thực nó. Thay vào đó, hàm băm là một tham chiếu bên ngoài từ nơi khác đã được xác thực (không bị kẻ tấn công báo động).

Một chi tiết khác ban đầu tôi đã bỏ qua vì nghĩ rằng nó không liên quan, nhưng nhìn nhận lại thì có vẻ như nó đã làm rõ vấn đề: không có khóa đối xứng được chia sẻ trước; khóa có thể được sử dụng trong mật mã thô hoặc AEAD là khóa được lấy từ bí mật tạm thời và khóa công khai của bên nhận thông qua ECDH. Như vậy, bất kỳ kẻ tấn công nào biết khóa công khai đều có thể tạo ra một đốm màu có thẻ AEAD hợp lệ bằng cách sử dụng bí mật tạm thời của riêng họ. Tuy nhiên, giả sử hàm băm không bị hỏng, một đốm màu như vậy sẽ không băm thành giá trị mà bên nhận mong đợi và do đó sẽ không bao giờ được sử dụng.

Nếu đã có các phương tiện để xác thực bản rõ thì thực sự có thể bỏ qua việc xác thực bản rõ hoặc bản mã bằng các phương tiện khác.

Tất nhiên có một số catcha.

Trước hết, không nên sử dụng bản rõ bằng bất kỳ cách nào trước khi giá trị băm xác thực được xác minh.Nếu đây không phải là trường hợp thì kẻ tấn công có thể thay đổi bản rõ, điều đó có nghĩa là bên đó phải chịu nhiều kiểu tấn công bao gồm tiên tri bản rõ hoặc có thể là tiêm lỗi.

Hơn nữa, việc triển khai không được cung cấp bất kỳ thông tin nào về quá trình giải mã. Nếu đúng như vậy, thì việc triển khai có thể trở thành đối tượng của các cuộc tấn công kênh phụ. Tệ hơn nữa, nếu v.d. CBC được sử dụng sau đó áp dụng các lời tiên tri đệm. Vì vậy, sẽ hợp lý hơn khi sử dụng AES-CTR hoặc mật mã luồng chẳng hạn như ChaCha20.

Có thể tránh được hai lỗi thiết kế/triển khai cuối cùng khi sử dụng chế độ xác thực. Vì vậy, có thể có một số cách sử dụng chế độ xác thực ngay cả khi khóa không được tin cậy. Một nhược điểm là các nhà phát triển khác có thể cho rằng chế độ xác thực cung cấp xác thực cần thiết và bắt đầu sử dụng văn bản gốc ngay cả khi thư chưa được xác thực.

Cá nhân tôi sẽ không sử dụng chế độ xác thực cho việc này.

Lưu ý rằng việc xử lý IV ​​không được chỉ định trong giao thức mà bạn mô tả. Nó không cần thiết phải là một phần của hàm băm nếu điều đó bảo vệ bản rõ hơn là bản mã. Tuy nhiên, bạn nên đảm bảo rằng nó là duy nhất cho mỗi thư được mã hóa bằng cùng một khóa (và nếu bạn sử dụng chế độ CBC, thì không thể đoán trước được).

Tôi cũng không biết liệu giao thức có dễ bị tấn công phát lại và tấn công đoán văn bản gốc hay không, nếu hàm băm đã xác thực được sử dụng cho cả nhận dạng và xác thực.

Hàm băm thiết lập tính toàn vẹn, không phải tính xác thực. Thẻ AEAD hoặc MAC của bản mã thiết lập cả tính toàn vẹn và tính xác thực.

Nếu hàm băm là của bản mã, kẻ tấn công có thể chỉ cần sửa đổi bản mã và tính toán một hàm băm mới, vì hàm băm không phụ thuộc vào khóa bí mật.

Nếu hàm băm là bản rõ, bạn sẽ gặp phải những điểm yếu giống như với các sơ đồ "MAC-then-encrypt" khi bạn vi phạm nguyên tắc nguyên tắc diệt vong mật mã.