ในการเข้ารหัส แฮชมักใช้เป็นตัวยึดสำหรับข้อความต้นฉบับ การใช้แฮชทำให้เราใช้ข้อความต้นฉบับได้อย่างมีประสิทธิภาพ ตัวอย่างเช่น เมื่อเซ็นข้อความยาว เราจะแฮชข้อความยาว จากนั้นเรียกใช้อัลกอริทึมลายเซ็นบนแฮชนั้น หากเราคิดว่าอัลกอริทึมลายเซ็นนั้นแข็งแกร่ง (และมีเพียงข้อความที่สร้างแฮชเท่านั้นที่จะตรวจสอบได้) และเราคิดว่าเป็นการยากที่จะหาข้อความที่สองที่สร้างแฮชเดียวกัน (ดังนั้นจึงต้องเป็นข้อความดั้งเดิมนั้น ลงนามแล้ว) จากนั้นระบบทั้งหมดก็แข็งแกร่ง
ด้วยเหตุนี้ เราจึงไม่พิจารณาถึง 'การรั่วไหลของข้อมูล' เมื่อพูดถึงฟังก์ชันแฮช นั่นคือ โดยทั่วไป เราไม่กังวลว่าการตรวจสอบผลลัพธ์แฮชจะทำให้ข้อมูลเกี่ยวกับข้อความต้นฉบับรั่วไหลหรือไม่ แต่เรากังวลเกี่ยวกับความยากลำบากในการค้นหาข้อความที่สร้างแฮชนั้น (ทั้งการต้านทานพรีอิมเมจ การต้านทานพรีอิมเมจที่สอง หรือการต้านทานการชนกัน) เนื่องจากสิ่งนั้นเกี่ยวข้องโดยตรงกับสมมติฐานด้านความปลอดภัยที่เราต้องการโดยทั่วไปจากฟังก์ชันแฮช
ที่กล่าวว่า หากมีใครพบการรั่วไหลใน (เช่น) SHA3 เช่น โดยการตรวจสอบแฮช เราสามารถระบุความยาวของข้อความได้ นั่นเป็นเรื่องที่น่าเป็นห่วงทีเดียว (และเราน่าจะเริ่มเลิกใช้ SHA3 ); บางครั้งเราต้องการถือว่าฟังก์ชันแฮชของเราเป็นออราเคิลแบบสุ่ม และนั่นจะบ่งบอกว่าฟังก์ชันแฮชไม่ได้ทำหน้าที่เหมือน [1] อย่างไรก็ตาม โอกาสของการรั่วไหลดังกล่าวดูเหมือนจะไม่น่าเป็นไปได้
[1]: ใช่ ฉันรู้ว่าการโจมตีแบบขยายความยาวแสดงว่า SHA-2 ไม่ได้ทำหน้าที่เหมือนคำพยากรณ์แบบสุ่ม ซึ่งเป็นที่เข้าใจกันดี และเราแค่หลีกเลี่ยงการใช้ SHA-2 ในลักษณะที่ใช้ได้กับการโจมตีเฉพาะนั้น