Không thể có sơ đồ "HMAC mù" an toàn - một dạng tương tự dựa trên HMAC của chữ ký mù - được biết đến (theo tôi hiểu, về cơ bản là do người dùng không thể xác thực chữ ký nhận được đối với khóa công khai cho người ký và do đó không thể chắc chắn rằng người ký không sử dụng nhiều khóa ký và sau đó "bỏ mù" chúng bằng cách xác định khóa nào của chúng hợp lệ cho một chữ ký nhất định).
Tuy nhiên, từ góc độ hiệu suất và chữ ký/kích thước MAC, HMAC thường được ưu tiên hơn so với các chữ ký trong đó trình xác minh nắm giữ khóa đối xứng của người ký được chấp nhận.Chẳng hạn, chữ ký BLS (mù hoặc không) ở chế độ kích thước chữ ký tối thiểu với đường cong BLS12-381 tiêu thụ 384 bit với mục tiêu bảo mật là 128 bit - điều này dường như khá ngắn theo tiêu chuẩn chữ ký. Trong so sánh, có vẻ như, ví dụ, hàm băm 128 bit có thể cung cấp 128 bit bảo mật khi sử dụng HMAC.
Trong tình huống như vậy, sơ đồ xác thực mù "bán HMAC" có hoạt động không? Cái gì đó như:
- Người dùng tạo và ẩn một tin nhắn với sơ đồ chữ ký mù bình thường, gửi cho người ký
- Người ký ký vào thông điệp ẩn, gửi lại cho người dùng
- Người dùng mở khóa nó và xác minh dựa trên khóa công khai của người ký, như với chữ ký mù bình thường - "HMAC mù", như đề xuất và được chứng minh là không an toàn, không có khả năng này, nhưng nó có thể được thực hiện ở đây, vì chữ ký mù được thực hiện với sơ đồ chữ ký mù bình thường, giả định và xác thực dựa trên hàm băm chỉ được sử dụng sau này.
- Người dùng tạo một hàm băm của tin nhắn và chữ ký (chứ không phải của tin nhắn và khóa như trong HMAC) và đính kèm nó vào tin nhắn.
- Người dùng gửi tin nhắn và hàm băm tới người xác minh
- Người xác minh nhận tin nhắn và độc lập ký nó bằng khóa riêng của người ký (được chia sẻ với người xác minh vì các khóa đối xứng nằm trong sơ đồ HMAC).
- Trình xác minh so sánh hàm băm do người dùng cung cấp với hàm mà nó tạo ra
- Nếu các giá trị băm khớp nhau, người dùng đã chứng minh rằng người ký đã ký vào thư mà không thực sự cần phải bao gồm chữ ký dài hơn giá trị băm của nó
Có vẻ như sơ đồ như vậy có thể giảm chi phí lưu trữ và chuyển các chữ ký tương đối dài tới người xác minh.Ngoài ra, có vẻ như các yêu cầu đối với hàm băm có thể ít một cách bất thường - chẳng hạn như một cuộc tấn công tạo ảnh trước vào hàm băm sẽ không gây ra mối đe dọa, vì cả hai bên đều đã biết thông báo được sử dụng để tạo ra nó, cũng như một cuộc tấn công mà một trong hai bên có thể tạo ra xung đột hàm băm (băm chỉ được sử dụng để chứng minh rằng người dùng có chữ ký hợp lệ cho tin nhắn - người dùng sẽ cần biết hàm băm của tin nhắn của họ và một chữ ký hợp lệ để nó thậm chí tìm kiếm xung đột hàm băm dẫn đến cùng một hàm băm để nó khớp với hàm băm do trình xác minh tạo ra). Thực sự, hàm băm chỉ cần được bảo mật để người dùng có thể đoán thành công hàm băm của tin nhắn của họ và chữ ký hợp lệ mà không cần lấy chữ ký đó - tức là, phải đủ khó để thực hiện một hàm băm hợp lệ cho một tin nhắn "trực tuyến" , giao tiếp với người xác minh. Lực lượng băm ngoại tuyến của hàm băm có vẻ không thực tế, vì người dùng không thể kiểm tra dự đoán về hàm băm đối với tin nhắn của họ ngoại tuyến mà không có Mà còn có thể đảo ngược hàm băm thành chữ ký (dài hơn nhiều, ngẫu nhiên hợp lệ) và kiểm tra chữ ký đối với khóa chung - có lẽ họ sẽ làm tốt hơn nếu cố gắng ép buộc một chữ ký hợp lệ hoặc khóa ký cho chữ ký mù bên dưới lược đồ, sau đó tạo ra một hàm băm của nó.
Tôi không thể tìm thấy tham chiếu đến bất kỳ sơ đồ xác thực mù nào hoạt động như thế này. Là một kế hoạch như vậy khả thi? Có bất kỳ lỗ hổng rõ ràng nào trong đó, bảo mật hay không?
TL; DR có thể tránh được các lỗi bảo mật đã biết của sơ đồ HMAC mù mà không có một số hàm ý về kích thước chữ ký của sơ đồ chữ ký mù bằng cách sử dụng sơ đồ chữ ký mù khi ký, nhưng yêu cầu người dùng băm chữ ký và tạo lại chữ ký đó và băm về phía người xác minh bằng khóa riêng của người ký, sau đó so sánh các giá trị băm?
