เมื่อเราเพาะ PRNG ใดๆ เราอาจมีข้อมูลที่ไม่สม่ำเสมอในเอนโทรปีของมัน ตัวอย่างเช่น แหล่งเดียวของการสุ่มที่ปลอดภัยด้วยการเข้ารหัสอาจเป็นชุดของ UUID ในรูปแบบสตริงแบบสุ่ม อย่างไรก็ตาม ในการใช้งาน PRNG ส่วนใหญ่ เราต้องการให้การสุ่มเป็นแบบเดียวกันและมีขนาดคงที่ เพื่อให้ได้สิ่งนั้น เราต้องมีวิธีกลั่นอินพุตให้มีขนาดที่เหมาะสม และฟังก์ชันแฮชก็เป็นวิธีที่ง่ายในการทำเช่นนั้น
เมื่อเรามี PRNG ที่ไม่ใช่การเข้ารหัส อินพุตที่ผู้ใช้ระบุมักจะมีขนาดใดก็ได้ และมักจะเป็นประโยชน์ในการอนุญาตให้ผู้ใช้ระบุเมล็ดพันธุ์โดยพลการ ตัวอย่างเช่น วิดีโอเกมบางเกมอนุญาตให้คุณวาง PRNG ด้วยข้อความตามอำเภอใจเพื่อเล่นซ้ำเกมเดิม และนั่นจะต้องถูกกลั่นให้เป็นอินพุตที่เหมาะสม ซึ่งฟังก์ชันแฮชนั้นเหมาะสม เกลือในกรณีนี้จะไม่มีประโยชน์มากนักเนื่องจากเป้าหมายคือการสร้างผลลัพธ์ที่กำหนดขึ้น
เมื่อเราใช้ CSPRNG อัลกอริทึมที่เราใช้จะเป็นแบบกำหนดขึ้นได้ แต่เราต้องการเพาะด้วยอินพุตที่มีเอนโทรปีเพียงพอเพื่อให้แน่ใจว่าเอาต์พุตนั้นคาดเดาไม่ได้ นั่นคือเป้าหมายของเราคือผลลัพธ์ที่ไม่ได้กำหนด การออกแบบบางอย่างเลือกที่จะบังคับให้อินพุตมีเอนโทรปีเหมือนกัน แต่การออกแบบส่วนใหญ่ใช้ฟังก์ชันการสืบทอดบางประเภท เช่นเดียวกับที่ใช้โดย CTR_DRBG เพื่ออนุญาตอินพุตที่ไม่สม่ำเสมอ บางครั้งอัลกอริทึมเหล่านั้นขึ้นอยู่กับฟังก์ชันแฮช และบางครั้งก็ไม่เป็นเช่นนั้น ตัวอย่างเช่น CTR_DRBG ใช้ฟังก์ชันการรับรหัสแบบบล็อกเพื่อทำให้อัลกอริทึมทั้งหมดใช้งานได้ด้วยการใช้งาน AES เพียงอย่างเดียว HMAC_DRBG ใช้ HMAC ในบทบาทนี้ ซึ่งใช้แฮช
การออกแบบ DRBG อนุญาตให้ใช้สตริงเกลือหรือการกำหนดค่าส่วนบุคคลได้ และมักแนะนำให้ใช้ เกลือคงที่หรือไม่สุ่มจะไม่ปรับปรุงความปลอดภัยหากมีเอนโทรปีไม่เพียงพอ เนื่องจากเราถือว่าเกลือเป็นข้อมูลสาธารณะ แต่ก็มีบริบทที่เป็นประโยชน์ เช่น หาก DRBG หลายตัวต้องถูกเพาะจากอินพุตเอนโทรปีเดียวกัน
มีบางกรณีที่เราใช้การออกแบบ CSPRNG สำหรับผลลัพธ์ที่กำหนดซึ่งแยกไม่ออกจากการสุ่ม และเกลือก็มีประโยชน์ที่นั่น ตัวอย่างเช่น ใน RFC 6979 ซึ่งอธิบาย DSA และ ECDSA เชิงกำหนด เราใช้ HMAC_DRBG เพื่อสร้างค่าสุ่ม $k$. คีย์ส่วนตัวคืออินพุตเอนโทรปีของเราและแฮชของข้อความคือเกลือ และทั้งสองอย่างนี้จำเป็นสำหรับการรักษาความปลอดภัย