เมื่อใดควรใช้ / dev / random vs / dev / urandom

ฉันควรใช้/dev/randomหรือ/dev/urandom?

ในสถานการณ์ใดที่ฉันจะชอบอีกสถานการณ์หนึ่ง

TL; DR

ใช้/dev/urandomเพื่อวัตถุประสงค์ในทางปฏิบัติมากที่สุด

คำตอบที่ยาวขึ้นอยู่กับรสชาติของ Unix ที่คุณใช้งานอยู่

ลินุกซ์

ประวัติศาสตร์/dev/randomและ/dev/urandomทั้งคู่ได้รับการแนะนำในเวลาเดียวกัน

ในฐานะที่เป็น @DavidSchwartz ชี้ให้เห็นในความคิดเห็นการใช้/dev/urandomเป็นที่ต้องการในกรณีส่วนใหญ่ เขาและคนอื่น ๆ ยังได้ให้ลิงก์ไปยังMyths ที่/dev/urandomยอดเยี่ยมเกี่ยวกับบทความที่ฉันแนะนำให้อ่านเพิ่มเติม

สรุป:

• manpageเป็นความเข้าใจผิด
• ทั้งสองถูกป้อนโดยCSPRNG เดียวกัน เพื่อสร้างการสุ่ม ( ไดอะแกรม 2 และ 3 )
• /dev/random บล็อกเมื่อมันหมดเอนโทรปี
• ปริมาณของเอนโทรปีถูกประมาณอย่างระมัดระวัง แต่ไม่นับ
• /dev/urandomจะไม่บล็อกการอ่านจาก/dev/randomสามารถหยุดการดำเนินการได้
• ในบางกรณีที่เกิดขึ้นไม่บ่อยนักหลังจากการบู๊ตCSPRNGอาจมีเอนโทรปีไม่เพียงพอที่จะทำการหยอดเมล็ดอย่างถูกต้องและ/dev/urandomอาจไม่ให้คุณภาพแบบสุ่มที่มีคุณภาพสูง
• เอนโทรปีใช้งานต่ำไม่มีปัญหาหาก CSPRNG เริ่มทำงานอย่างถูกต้อง
• CSPRNG กำลังได้รับการบรรจุซ้ำอย่างต่อเนื่อง
• ใน Linux 4.8 ขึ้นไป/dev/urandomจะไม่ทำให้หมดสิ้นพูลเอนโทรปี (ใช้โดย/dev/random) แต่ใช้เอาต์พุต CSPRNG จากอัปสตรีม
• /dev/urandomใช้

ข้อยกเว้นกฎ

ใน Cryptography Stack Exchange จะใช้/dev/randomเมื่อใด/dev/urandomใน Linux @otus มีสองกรณีการใช้งาน :

1. /dev/urandomไม่นานหลังจากที่บูตบนอุปกรณ์เอนโทรปีต่ำถ้าพอเอนโทรปียังไม่ได้สร้างขึ้นอย่างถูกต้องเมล็ด

2. สร้างแผ่นข้อมูลแบบครั้งเดียวด้วยความปลอดภัยทางทฤษฎีข้อมูล

หากคุณกังวลเกี่ยวกับ (1) คุณสามารถตรวจสอบเอนโทรปีที่มีอยู่ใน/dev/random

ถ้าคุณทำ (2) คุณจะรู้แล้ว :)

หมายเหตุ: คุณสามารถตรวจสอบว่าการอ่านจาก / dev / สุ่มจะปิดกั้นแต่ระวังสภาพการแข่งขันที่เป็นไปได้

ทางเลือก: ใช้ไม่ได้!

@otus ยังชี้ให้เห็นว่าgetrandom()ระบบจะอ่าน/dev/urandomและบล็อกเฉพาะเมื่อเอนโทรปีของเมล็ดเริ่มต้นไม่พร้อมใช้งาน

มีปัญหาเกี่ยวกับการเปลี่ยนแปลง/dev/urandomที่จะใช้getrandom()แต่มันก็เป็นไปได้ว่าใหม่อุปกรณ์ที่มีการสร้างขึ้นตาม/dev/xrandomgetrandom()

MacOS

มันไม่สำคัญหรอกอย่างที่ Wikipedia พูดว่า :

macOS ใช้Yarrow 160 บิตจาก SHA1 ไม่มีความแตกต่างระหว่าง / dev / random และ / dev / urandom; ทั้งประพฤติตัวเหมือนกัน iOS ของ Apple ยังใช้ยาร์โรว์

FreeBSD

มันไม่สำคัญหรอกอย่างที่Wikipedia พูดว่า :

/dev/urandomเป็นเพียงลิงก์ไปยัง/dev/randomและบล็อกเท่านั้นจนกระทั่ง seeded ถูกต้อง

ซึ่งหมายความว่าหลังจากบูตแล้ว FreeBSD นั้นฉลาดพอที่จะรอจนกระทั่งมีการรวบรวมเอนโทรปีของเมล็ดเพียงพอก่อนที่จะส่งกระแสสุ่มที่ไม่มีวันจบสิ้น

NetBSD

ใช้/dev/urandomสมมติว่าระบบของคุณอ่านอย่างน้อยหนึ่งครั้ง/dev/randomเพื่อให้แน่ใจว่ามีการเริ่มต้นที่เหมาะสม

อาร์เอ็น (4) manpage กล่าวว่า :

/dev/urandom ไม่บล็อกเลย

/dev/randomบางครั้งบล็อก จะบล็อกตั้งแต่เริ่มต้นหากระบบทราบว่าสถานะของระบบนั้นสามารถคาดเดาได้

แอปพลิเคชันควรอ่านจาก / dev / urandom เมื่อพวกเขาต้องการข้อมูลที่สร้างแบบสุ่มเช่นคีย์การเข้ารหัสหรือเมล็ดสำหรับการจำลอง

ระบบควรได้รับการออกแบบให้อ่านอย่างน้อยหนึ่งครั้งจาก / dev / random เมื่อบู๊ตก่อนเรียกใช้บริการใด ๆ ที่พูดคุยกับอินเทอร์เน็ตหรือต้องใช้การเข้ารหัสเพื่อหลีกเลี่ยงการสร้างคีย์ที่คาดเดาได้

ตามเนื้อผ้าความแตกต่างเพียงอย่างเดียวระหว่าง/dev/urandomและ/dev/randomเป็นสิ่งที่เกิดขึ้นเมื่อเคอร์เนลคิดว่าไม่มีเอนโทรปีในระบบ - /dev/randomล้มเหลวปิด, /dev/urandomล้มเหลวเปิด คนขับรถทั้งสองได้รับการจัดหาเอนโทรปีจากadd_disk_randomness(), และadd_interrupt_randomness() add_input_randomness()ดู/drivers/char/random.cเฉพาะ

แก้ไขเพื่อเพิ่ม: ตั้งแต่ Linux 4.8 /dev/urandomได้รับการทำใหม่เพื่อใช้ CSPRNG

ดังนั้นเมื่อใดที่คุณไม่ควรปิด สำหรับการใช้งานการเข้ารหัสใด ๆ โดยเฉพาะการเพาะ DRBG มีกระดาษที่ดีมากที่อธิบายผลของการใช้/dev/urandomเมื่อสร้างคีย์ RSA และไม่มีเอนโทรปีเพียงพอ อ่านการทำ Ps และ Qs ของคุณ

นี่เป็นคำตอบที่ "ฉันก็เหมือนกัน" แต่มันก็ทำให้คำแนะนำของ Tom Hale แข็งแกร่งขึ้น มันใช้กับลินุกซ์อย่างเต็มที่

• ใช้ /dev/urandom
• อย่าใช้ /dev/random

ตาม Theodore Ts'o ในรายชื่อผู้รับจดหมาย Linux Kernel Crypto /dev/randomได้รับการคัดค้านเป็นเวลาสิบปี จากRe: [RFC PATCH v12 3/4] ตัวสร้างหมายเลขสุ่ม Linux :

แทบไม่มีใครใช้ / dev / สุ่ม มันเป็นอินเทอร์เฟซที่เลิกใช้แล้ว อินเทอร์เฟซหลักที่แนะนำมานานกว่าทศวรรษคือ / dev / urandom และตอนนี้ getrandom (2)

เราทดสอบเป็นประจำ/dev/randomและพบว่ามีความล้มเหลวบ่อยครั้ง การทดสอบดำเนินการสามขั้นตอน: (1) การระบายน้ำ/dev/randomโดยขอ 10K ไบต์ในโหมดที่ไม่ปิดกั้น; (2) ร้องขอ 16 ไบต์ในโหมดบล็อก (3) พยายามบีบอัดบล็อกเพื่อดูว่ามีการสุ่ม (การทดสอบของคนจนหรือไม่) การทดสอบใช้เวลาไม่กี่นาที

ปัญหานั้นแย่มากในระบบ Debain (i686, x86_64, ARM และ MIPS) เราขอให้ GCC Compile Farm ติดตั้งrng-toolsแพคเกจสำหรับเครื่องทดสอบ จากInstall rng-tools บน gcc67 และ gcc68 :

ฉันต้องการขอให้ติดตั้งเครื่องมือ rng บน gcc67 และ gcc68 พวกเขาเป็นระบบ Debian และ / dev / random ได้รับความทุกข์ทรมานจากการสูญเสียเอนโทรปีโดยไม่ต้องใช้เครื่องมือ rng เมื่อทำการทดสอบไลบรารีที่ใช้อุปกรณ์ทรมาน

BSDs และ OS X ปรากฏขึ้นตกลง ปัญหาคือ Linux แน่นอน

มันอาจจะเป็นมูลค่าการกล่าวขวัญ Linux ไม่ได้บันทึกความล้มเหลวของตัวสร้าง พวกเขาไม่ต้องการให้รายการเติมบันทึกของระบบ ในวันที่ความล้มเหลวส่วนใหญ่เงียบและไปตรวจไม่พบโดยผู้ใช้ส่วนใหญ่

สถานการณ์ควรเปลี่ยนแปลงเร็ว ๆ นี้เนื่องจากเคอร์เนลกำลังจะพิมพ์ข้อความความล้มเหลวอย่างน้อยหนึ่งข้อความ จาก[PATCH] สุ่ม: คำเตือนคอมไพเลอร์เงียบและแก้ไขการแข่งขันในรายชื่อผู้รับจดหมายเคอร์เนล crypto:

depends on DEBUG_KERNELโดยเฉพาะฉันเพิ่ม ซึ่งหมายความว่าคำเตือนที่มีประโยชน์เหล่านี้จะกระตุ้นผู้พัฒนาเคอร์เนลเท่านั้น นี่อาจเป็นสิ่งที่เราต้องการ หากผู้พัฒนาที่เกี่ยวข้องหลายรายเห็นคำเตือนที่มาจากระบบย่อยเฉพาะพวกเขาจะมีแรงจูงใจมากขึ้นในการแก้ไข ผู้ใช้ทั่วไปเกี่ยวกับเมล็ดกระจายไม่ควรเห็นคำเตือนหรือสแปมเลยเนื่องจากผู้ใช้ทั่วไปไม่ได้ใช้ DEBUG_KERNEL

ฉันคิดว่ามันเป็นความคิดที่ดีที่จะระงับข้อความทั้งหมดจากมุมมองด้านวิศวกรรมความปลอดภัย

ผู้คนจำนวนมากไม่เรียกใช้ debug kernels ผู้ใช้ส่วนใหญ่ที่ต้องการหรือจำเป็นต้องทราบปัญหาจะไม่เกิดขึ้น ลองพิจารณาเหตุผลที่เราเรียนรู้เกี่ยวกับปัญหาของ systemd นั้นเกิดจาก dmesg

การระงับข้อความทั้งหมดสำหรับการกำหนดค่าทั้งหมดจะทำให้เกิดเครือข่ายที่กว้างเกินความจำเป็น การกำหนดค่าที่อาจตรวจจับได้และการแก้ไขที่มีแนวโน้มจะไม่มีการสังเกต หากปัญหาไม่ได้มาสู่แสงสว่างแสดงว่าไม่สามารถแก้ไขได้

ฉันรู้สึกว่าเคอร์เนลกำลังตัดสินใจเชิงนโยบายสำหรับบางองค์กร สำหรับผู้ที่มีฮาร์ดแวร์ที่ไม่สามารถแก้ไขได้อย่างมีประสิทธิภาพแล้วองค์กรต้องตัดสินใจว่าจะทำอย่างไรบนพื้นฐานของความเสี่ยง พวกเขาอาจตัดสินใจที่จะอยู่กับความเสี่ยงหรือพวกเขาอาจตัดสินใจที่จะรีเฟรชฮาร์ดแวร์ อย่างไรก็ตามหากไม่มีข้อมูลเกี่ยวกับปัญหาพวกเขาอาจไม่รู้ด้วยซ้ำว่ามีรายการที่ดำเนินการได้

การประนีประนอมในที่สุดก็มาถึงในเธรดอย่างน้อยหนึ่ง dmesg ต่อโมดูลการโทร