Trong mật mã, các giá trị băm thường được sử dụng làm trình giữ chỗ cho thông báo gốc; bằng cách sử dụng hàm băm, chúng tôi đang sử dụng thông báo gốc một cách hiệu quả. Ví dụ: khi ký một tin nhắn dài, chúng tôi băm tin nhắn dài và sau đó chạy thuật toán chữ ký trên hàm băm; nếu chúng tôi cho rằng thuật toán chữ ký mạnh (và do đó, chỉ một thông báo tạo ra hàm băm đó mới hợp lệ) và chúng tôi cho rằng khó có thể tìm thấy một thông báo thứ hai tạo ra cùng một hàm băm (do đó, nó phải là thông báo ban đầu đó đã được ký kết), thì toàn bộ hệ thống sẽ mạnh mẽ.
Do đó, chúng tôi thường không xem xét 'rò rỉ thông tin' khi nói về hàm băm; nghĩa là, chúng tôi thường không lo lắng liệu việc kiểm tra đầu ra hàm băm có làm rò rỉ thông tin về thông báo gốc hay không. Thay vào đó, chúng tôi lo lắng về việc khó tìm được thông báo tạo ra hàm băm đó (có thể là khả năng chống tạo ảnh trước, khả năng chống tạo ảnh thứ hai hoặc khả năng chống va chạm), bởi vì điều đó liên quan trực tiếp đến các giả định bảo mật mà chúng ta thường cần từ các hàm băm.
Điều đó nói rằng, nếu ai đó phát hiện ra rò rỉ trong (giả sử) SHA3, chẳng hạn, bằng cách kiểm tra hàm băm, chúng tôi có thể xác định độ dài của thông báo, điều đó sẽ khá đáng lo ngại (và chúng tôi có thể sẽ bắt đầu phản đối SHA3 ); đôi khi chúng tôi muốn coi các hàm băm của mình như một lời tiên tri ngẫu nhiên và điều đó cho thấy rằng nó không hoạt động như một [1]. Tuy nhiên, viễn cảnh rò rỉ như vậy dường như khó xảy ra.
[1]: Có, tôi biết các cuộc tấn công mở rộng độ dài cho thấy SHA-2 không hoạt động như một lời tiên tri ngẫu nhiên; điều đó được hiểu rõ và chúng tôi chỉ tránh sử dụng SHA-2 theo cách có thể áp dụng cuộc tấn công cụ thể đó.
