จะทำให้เอนโทรปีเพียงพอในคอนเทนเนอร์ Docker ได้อย่างไร

เมื่อใดก็ตามที่ฉัน แมว /proc/sys/kernel/random/entropy_avail ภายในคอนเทนเนอร์ Docker ของฉัน (ใช้ Linux 5.10) ฉันได้รับผลลัพธ์เป็นเลขสองหลักซึ่งเห็นได้ชัดว่าต่ำอย่างน่าขันอะไรก็ตามที่ต่ำกว่า 4 หลักถือว่าไม่ดี และการรักษาไว้ใกล้กับ 4096 (สูงสุด) นั้นเหมาะสมที่สุด

ฉันได้อ่านเกี่ยวกับภูตรวบรวมเอนโทรปีที่เรียกว่า ได้แต่คาดว่าล้าสมัยไปแล้วตั้งแต่ Linux kernel 5.6 ดังนั้นฉันจึงไม่แน่ใจว่านั่นเป็นวิธีแก้ปัญหาที่ถูกต้องอีกต่อไป

เหตุใดเอนโทรปีของฉันจึงต่ำมากภายในคอนเทนเนอร์ Docker ที่ใช้เคอร์เนล 5.10 และฉันจะแก้ไขได้อย่างไร

เดิมทีฉันค้นพบสิ่งนี้เมื่อสคริปต์ "คำพูดประจำวัน" ของ Python ยังคงเลือกคำพูดสองสามคำเหมือนเดิม ฉันไม่ได้ทำการ seed โมดูล Random มาตรฐานของ Python ด้วยตนเอง แต่ตามเอกสารและซอร์สโค้ด มันควรจะทำการ seed ตัวเองจากเอนโทรปีของระบบ (โดยตรงผ่าน เกเต็นโทรปี(3) หรือได้รับ สุ่ม(2) หากมีซึ่งฉันคิดว่าพวกเขาจะอยู่ในสภาพแวดล้อม Linux สมัยใหม่ทั่วไปหรือผ่าน /dev/สุ่ม หรือ /dev/urandom หรือถอยกลับไปใช้เวลาของระบบและ PID เป็นทางเลือกสุดท้าย) ดังนั้นฉันเดาว่าเอนโทรปีของฉันต่ำมาก เกเต็นโทรปี(3) กำลังคืนค่าเอนโทรปีที่ไม่ดี? อย่างไรก็ตาม การ seed โมดูล Random ของ Python ด้วยตนเองพร้อมเวลาของระบบจะช่วยแก้ปัญหานั้นได้

อย่างไรก็ตาม ตอนนี้ฉันกังวลว่าเว็บเซิร์ฟเวอร์ของฉันที่ใช้ TLS และเซิร์ฟเวอร์การตรวจสอบสิทธิ์ของฉัน ซึ่งทั้งหมดนี้ทำงานในคอนเทนเนอร์ Docker ที่คล้ายกัน อาจมีค่าเอนโทรปีไม่เพียงพอที่จะสร้างคีย์ที่รัดกุมและแพดแบบใช้ครั้งเดียว และความท้าทาย และอื่นๆ ดังนั้นฉันต้องการทราบวิธีการรับประกันว่าคอนเทนเนอร์ Docker ของฉันได้รับเอนโทรปีเพียงพอที่จะทำงานได้ดี

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

เนื่องจากคุณกำลังพูดคุยกับเคอร์เนล จึงไม่เกี่ยวข้องกับนักเทียบท่าเลย:

$ cat /proc/sys/kernel/random/entropy_avail
3771

$ docker run -it --rm busybox cat /proc/sys/kernel/random/entropy_avail
3781

$ cat /proc/sys/kernel/random/entropy_avail
3800

หากคุณได้รับเอนโทรปีมากขึ้นในโฮสต์ คุณก็จะมีเอนโทรปีมากขึ้นในคอนเทนเนอร์

เกร็ดเล็กเกร็ดน้อยที่คุณเห็นคำพูดเดียวกันของวันเมื่อเร็วๆ นี้ไม่ใช่หลักฐานว่า RNG ของคุณมีปัญหา

ใช้ Python's Random (ไม่ใช่ SystemRandom) สำหรับทุกสิ่งที่ขาดการเข้ารหัสที่สำคัญด้านความปลอดภัย เมล็ดพันธุ์เองโดยปริยาย โปรดทราบว่าจำนวนเต็มที่ไม่ซ้ำอย่างสมเหตุสมผลใดๆ จะทำแบบ seed ซึ่งไม่น่าเป็นไปได้อย่างยิ่งที่คุณภาพของ RNG จะถูกตรวจจับได้โดยการเพาะอีกอันหนึ่ง

แล้ว SystemRandom ล่ะ? นี่คือ API ของ Python สำหรับการรับ RNG เฉพาะแพลตฟอร์มที่ไม่ได้กำหนดไว้ และดีกว่าสำหรับการใช้การเข้ารหัส

บิตสุ่มไม่ใช่ของหายากหรือพิเศษบน Linux นั่นเป็นตำนาน CSPRNG ของเคอร์เนลนั้นดี และเมื่อเริ่มต้นแล้ว สามารถใช้ในโหมด nonblocking (/dev/urandom, getrandom with GRND_NONBLOCK) สำหรับบิตสุ่มจำนวนมาก จริงๆ แล้วตั้งแต่ 5.6 เป็นต้นมา มันเป็นวิธีการทำงาน Linux ไม่มีกลุ่มการบล็อกอีกต่อไป. /dev/random บล็อกเฉพาะตอนบู๊ตก่อนการเริ่มต้นเคอร์เนล rng ในระยะยาวนี่เป็นวิธีแก้ปัญหาที่แท้จริง อัปเกรดเคอร์เนลและโปรแกรมสามารถมีบิตได้มากเท่าที่ต้องการ

ปัญหาคือผู้คนยังคงคิดว่าการบล็อก API นั้นดีกว่า แม้ว่าจะมีการปฏิเสธบริการก็ตาม สิ่งนี้ทำให้เมื่อพูลการบล็อกหมดลง Python แก้ไขปัญหาเกี่ยวกับการหมดพูลการบล็อกในสคริปต์เริ่มต้นระบบ... โดยทำการบล็อก os.urandom() บน Linux. ถอนหายใจ