วิธีจัดการกับตัวสร้าง SecureRandom ที่ช้าจะทำอย่างไร

ถ้าคุณต้องการตัวเลขที่แข็งแกร่งใน Java SecureRandomคุณใช้ น่าเสียดายที่SecureRandomอาจช้ามาก ถ้ามันใช้/dev/randomบน Linux มันสามารถบล็อกรอเอนโทรปีเพียงพอที่จะสร้างขึ้น คุณจะหลีกเลี่ยงบทลงโทษการแสดงได้อย่างไร?

มีใครใช้Uncommon Mathsเป็นวิธีการแก้ปัญหานี้หรือไม่?

ใครช่วยยืนยันว่าปัญหาประสิทธิภาพนี้ได้รับการแก้ไขใน JDK 6 หรือไม่

หากคุณต้องการข้อมูลสุ่มที่แท้จริงคุณต้องรอ ซึ่งรวมถึงเมล็ดพันธุ์สำหรับSecureRandomPRNG คณิตศาสตร์ที่ผิดปกติไม่สามารถรวบรวมข้อมูลแบบสุ่มที่แท้จริงได้เร็วกว่าSecureRandomแม้ว่ามันจะสามารถเชื่อมต่ออินเทอร์เน็ตเพื่อดาวน์โหลดข้อมูลเมล็ดพันธุ์จากเว็บไซต์ใด ๆ ก็ตาม ฉันเดาว่านี่ไม่น่าจะเร็วกว่า/dev/randomที่มีอยู่

ถ้าคุณต้องการ PRNG ให้ทำสิ่งนี้:

SecureRandom.getInstance("SHA1PRNG");

สิ่งที่ได้รับการสนับสนุนสตริงขึ้นอยู่กับSecureRandomผู้ให้บริการ SPI แต่คุณสามารถระบุพวกเขาโดยใช้และSecurity.getProviders()Provider.getService()

ซุนชอบ SHA1PRNG ดังนั้นจึงมีวางจำหน่ายอย่างแพร่หลาย มันไม่เร็วโดยเฉพาะอย่างยิ่งเมื่อ PRNGs ไป แต่ PRNGs จะเป็นเพียงตัวเลขที่คดเคี้ยวไม่ใช่การปิดกั้นการวัดเอนโทรปีทางกายภาพ

ยกเว้นว่าถ้าคุณไม่ได้โทรหาsetSeed()ก่อนที่จะได้รับข้อมูลแล้วจะ PRNG เมล็ดพันธุ์ตัวเองเมื่อครั้งแรกที่คุณโทรหาหรือnext() nextBytes()มันมักจะทำสิ่งนี้โดยใช้ข้อมูลสุ่มจริงจำนวนเล็กน้อยจากระบบ การโทรนี้อาจบล็อก แต่จะทำให้แหล่งที่มาของตัวเลขสุ่มมีความปลอดภัยมากกว่าตัวแปร "แฮชเวลาปัจจุบันพร้อมกับ PID เพิ่ม 27 และหวังว่าจะดีที่สุด" หากทุกอย่างที่คุณต้องการคือตัวเลขสุ่มสำหรับเกมหรือหากคุณต้องการให้สตรีมสามารถทำซ้ำได้ในอนาคตโดยใช้เมล็ดพันธุ์เดียวกันเพื่อการทดสอบเมล็ดพันธุ์ที่ไม่ปลอดภัยยังคงมีประโยชน์

คุณควรเลือก Linux / dev / urandom ที่เร็วขึ้น แต่มีความปลอดภัยน้อยโดยใช้:

-Djava.security.egd=file:/dev/urandom

อย่างไรก็ตามสิ่งนี้ใช้ไม่ได้กับ Java 5 และใหม่กว่า ( Java Bug 6202721 ) วิธีแก้ไขที่แนะนำคือการใช้:

-Djava.security.egd=file:/dev/./urandom

(บันทึกเพิ่มเติม/./)

บน Linux การใช้งานเริ่มต้นสำหรับSecureRandomคือNativePRNG(ซอร์สโค้ดที่นี่ ) ซึ่งมีแนวโน้มที่จะช้ามาก บน Windows ค่าดีฟอลต์คือSHA1PRNGซึ่งคนอื่น ๆ ชี้ให้เห็นว่าคุณสามารถใช้บน Linux ได้หากคุณระบุไว้อย่างชัดเจน

NativePRNGแตกต่างจากAESCounterRNGSHA1PRNGและ Uncommons Maths ' ที่ได้รับเอนโทรปีอย่างต่อเนื่องจากระบบปฏิบัติการ (โดยการอ่านจาก) PRNG อื่นไม่ได้รับเอนโทรปีใด ๆ เพิ่มเติมหลังจากการเพาะ/dev/urandom

AESCounterRNG เป็นเรื่องเกี่ยวกับ 10x เร็วกว่าSHA1PRNGซึ่ง IIRC NativePRNGเป็นตัวที่สองหรือสามครั้งเร็วกว่า

หากคุณต้องการ PRNG ที่เร็วกว่าที่ได้รับเอนโทรปีหลังจากการเริ่มต้นให้ดูว่าคุณสามารถค้นหาการนำ Java ไปใช้ของFortunaได้หรือไม่ PRNG หลักของการใช้งาน Fortuna นั้นเหมือนกันกับที่ใช้โดย AESCounterRNG แต่ยังมีระบบที่ซับซ้อนของการรวมทรัพยากรเอนโทรปีและการกลับมาทำงานอัตโนมัติ

Linux distros ส่วนใหญ่ (ส่วนใหญ่ใช้ Debian) จะกำหนดค่า OpenJDK เพื่อใช้/dev/randomสำหรับเอนโทรปี

/dev/random คือโดยคำจำกัดความช้า (และยังสามารถบล็อก)

จากที่นี่คุณมีสองตัวเลือกในการยกเลิกการปิดกั้น:

1. ปรับปรุงเอนโทรปีหรือ
2. ลดความต้องการแบบแผน

ตัวเลือก 1 ปรับปรุงเอนโทรปี

หากต้องการเอนโทรปีมากขึ้นให้/dev/randomลองทำแฮงก์ภูตมันเป็นดีมอนที่รวบรวม HAVEGE เอนโทรปีอย่างต่อเนื่องและทำงานในสภาพแวดล้อมเสมือนจริงเพราะมันไม่จำเป็นต้องใช้ฮาร์ดแวร์พิเศษใด ๆ มีเพียงซีพียูและนาฬิกาเท่านั้น

บน Ubuntu / Debian:

apt-get install haveged
update-rc.d haveged defaults
service haveged start

บน RHEL / CentOS:

yum install haveged
systemctl enable haveged
systemctl start haveged

ตัวเลือก 2 ลดความต้องการแบบแผน

หากด้วยเหตุผลบางอย่างการแก้ปัญหาข้างต้นไม่ได้ช่วยหรือคุณไม่สนใจการสุ่มที่แข็งแกร่งของการเข้ารหัสคุณสามารถเปลี่ยนไปใช้ /dev/urandomใช้งานแทนซึ่งรับประกันได้ว่าจะไม่บล็อก

หากต้องการทำร่วมกันแก้ไขไฟล์jre/lib/security/java.securityในการติดตั้ง Java เริ่มต้นของคุณที่จะใช้/dev/urandom(เนื่องจากข้อผิดพลาดอื่นจะต้องมีการระบุเป็น/dev/./urandom )

แบบนี้:

#securerandom.source=file:/dev/random
securerandom.source=file:/dev/./urandom

จากนั้นคุณไม่จำเป็นต้องระบุในบรรทัดคำสั่ง

หมายเหตุ: หากคุณทำการเข้ารหัสคุณต้องมีเอนโทรปีที่ดี ตรงประเด็น - ปัญหา PRNG ของ Androidลดความปลอดภัยของกระเป๋าเงิน Bitcoin

ฉันมีปัญหาคล้ายกันกับการโทรเพื่อSecureRandomบล็อกประมาณ 25 วินาทีต่อครั้งบนเซิร์ฟเวอร์ Debian ที่ไม่มีหัว ฉันติดตั้งhavegedดีมอนเพื่อให้แน่ใจว่าได้/dev/randomรับการเติมเงินบนเซิร์ฟเวอร์ที่ไม่มีหัวคุณต้องการอะไรแบบนี้เพื่อสร้างเอนโทรปีที่ต้องการ การโทรของฉันไปถึงSecureRandomตอนนี้อาจใช้เวลาเป็นมิลลิวินาที

หากคุณต้องการการสุ่มที่ "เข้ารหัสลับ" อย่างแท้จริงคุณต้องมีแหล่งเอนโทรปีที่แข็งแกร่ง /dev/randomช้าเพราะต้องรอให้กิจกรรมของระบบรวบรวมเอนโทรปี (อ่านดิสก์แพ็กเก็ตเครือข่ายการเคลื่อนไหวของเมาส์การกดปุ่มเป็นต้น)

วิธีที่เร็วกว่าคือตัวสร้างหมายเลขสุ่มฮาร์ดแวร์ คุณอาจมีหนึ่งในเมนบอร์ดของคุณ; ตรวจสอบเอกสาร hw_randomสำหรับคำแนะนำในการหาว่าคุณมีมันและวิธีการใช้งาน แพคเกจ RNG /dev/randomเครื่องมือรวมถึงภูตที่จะเลี้ยงฮาร์ดแวร์สร้างเอนโทรปีเป็น

หาก HRNG ไม่พร้อมใช้งานในระบบของคุณและคุณยินดีที่จะเสียสละความแข็งแกร่งของเอนโทรปีสำหรับการปฏิบัติงานคุณจะต้องการเมล็ด PRNG ที่ดีพร้อมข้อมูลจาก/dev/randomและให้ PRNG ทำงานเป็นกลุ่ม มีรายการของ PRNG ที่ได้รับการอนุมัติโดย NIST หลายรายการใน SP800-90ซึ่งตรงไปตรงมาเพื่อนำไปใช้

เมื่อใช้ Java 8 ฉันพบว่าการโทรบน Linux SecureRandom.getInstanceStrong()จะให้NativePRNGBlockingอัลกอริทึมแก่ฉัน สิ่งนี้มักจะบล็อกเป็นเวลาหลายวินาทีเพื่อสร้างเกลือสองสามไบต์

ฉันเปลี่ยนเป็นการขออย่างชัดเจนNativePRNGNonBlockingแทนและตามที่คาดไว้จากชื่อจะไม่ถูกบล็อกอีกต่อไป ฉันไม่รู้ว่าสิ่งนี้เกี่ยวข้องกับความปลอดภัยอย่างไร สมมุติว่าเวอร์ชั่นที่ไม่มีการบล็อกไม่สามารถรับประกันปริมาณเอนโทรปีที่ใช้

อัปเดต : โอเคฉันพบคำอธิบายที่ยอดเยี่ยมนี้

new SecureRandom()สรุปเพื่อหลีกเลี่ยงการปิดกั้นการใช้งาน การใช้งานนี้ซึ่งจะไม่ปิดกั้นและเป็นพื้นเป็นที่ปลอดภัย/dev/urandom /dev/randomจากการโพสต์: "เวลาเดียวที่คุณต้องการเรียก / dev / random คือเมื่อเครื่องเริ่มบูทครั้งแรกและเอนโทรปียังไม่ได้สะสม"

SecureRandom.getInstanceStrong() มอบ RNG ที่แข็งแกร่งที่สุดให้คุณ แต่ปลอดภัยที่จะใช้ในสถานการณ์ที่การบล็อกจำนวนมากไม่มีผลกับคุณ

มีเครื่องมือ (อย่างน้อยบน Ubuntu) ที่จะดึงข้อมูลแบบสุ่มเข้าสู่ระบบของคุณ คำสั่งนั้นเรียบง่าย:

rngd -r /dev/urandom

และคุณอาจต้องการ sudo ที่ด้านหน้า หากคุณไม่มีแพ็คเกจ rng-tools คุณจะต้องติดตั้ง ฉันลองสิ่งนี้และมันช่วยฉันได้อย่างแน่นอน!

ที่มา: matt vs world

ผมประสบเดียวกันปัญหา หลังจากที่บาง Googling กับคำค้นหาที่ถูกต้องฉันมาข้ามบทความนี้ดีในDigitalOcean

hasged เป็นโซลูชั่นที่มีศักยภาพโดยไม่ลดทอนความปลอดภัย

ฉันแค่อ้างถึงส่วนที่เกี่ยวข้องจากบทความที่นี่

ตามหลักการ HAVEGE และก่อนหน้านี้อ้างอิงไลบรารีที่เชื่อมโยงได้อนุญาตให้สร้างการสุ่มขึ้นอยู่กับความแปรผันของเวลาประมวลผลโค้ดในโปรเซสเซอร์ เนื่องจากเกือบจะเป็นไปไม่ได้ที่โค้ดหนึ่งชิ้นจะใช้เวลาในการดำเนินการที่แน่นอนแม้ในสภาพแวดล้อมเดียวกันบนฮาร์ดแวร์เดียวกันเวลาของการรันโปรแกรมเดี่ยวหรือหลายโปรแกรมจึงควรเหมาะสมกับแหล่งที่มาแบบสุ่ม การใช้งานแบบแยกส่วนได้รวบรวมแหล่งที่มาแบบสุ่มของระบบของคุณ (โดยปกติ / dev / สุ่ม) โดยใช้ความแตกต่างในตัวนับเวลาของตัวประมวลผล (TSC) ของตัวประมวลผลของคุณหลังจากเรียกใช้ลูปซ้ำ ๆ

ติดตั้งอย่างไร

ทำตามขั้นตอนในบทความนี้ https://www.digitalocean.com/community/tutorials/how-to-setup-additional-entropy-for-cloud-servers-using-haveged

ฉันโพสต์ไว้ที่นี่

ปัญหาที่คุณอ้างถึง/dev/randomไม่ได้เกิดจากSecureRandomอัลกอริธึม แต่เป็นแหล่งที่มาของการสุ่มที่ใช้ ทั้งสองเป็นมุมฉาก คุณควรจะรู้ว่าหนึ่งในสองนั้นกำลังทำให้คุณช้าลง

หน้าคณิตศาสตร์ผิดปกติที่คุณเชื่อมโยงกล่าวอย่างชัดเจนว่าพวกเขาไม่ได้กล่าวถึงแหล่งที่มาของการสุ่ม

คุณสามารถลองใช้ผู้ให้บริการ JCE ที่แตกต่างกันเช่น BouncyCastle เพื่อดูว่าการใช้งานของพวกเขาSecureRandomนั้นเร็วกว่าหรือไม่

การค้นหาสั้น ๆยังเผยให้เห็นแพตช์ Linux ที่แทนที่การใช้งานเริ่มต้นด้วย Fortuna ฉันไม่รู้อะไรมากเกี่ยวกับสิ่งนี้ แต่คุณสามารถตรวจสอบได้

ฉันควรจะพูดถึงว่าในขณะที่มันอันตรายมากที่จะใช้ดำเนินการไม่ดีSecureRandomขั้นตอนวิธีการและ / หรือแหล่งสุ่มคุณสามารถม้วนของผู้ให้บริการ JCE SecureRandomSpiของคุณเองด้วยการดำเนินงานที่กำหนดเอง คุณจะต้องผ่านกระบวนการกับซันเพื่อให้ผู้ให้บริการลงนาม แต่จริงๆแล้วมันค่อนข้างตรงไปตรงมา พวกเขาเพียงต้องการให้คุณส่งแฟกซ์แบบฟอร์มโดยระบุว่าคุณรับรู้ถึงข้อ จำกัด การส่งออกของสหรัฐฯในไลบรารี crypto

ใช้การสุ่มแบบปลอดภัยเป็นแหล่งเริ่มต้นสำหรับอัลกอริธึมที่เกิดซ้ำ คุณสามารถใช้ Twers Mersenne สำหรับการทำงานเป็นกลุ่มแทนที่จะเป็นหนึ่งใน UncommonMath ซึ่งผ่านมาได้ระยะหนึ่งและพิสูจน์แล้วว่าดีกว่า prng อื่น ๆ

http://en.wikipedia.org/wiki/Mersenne_twister

ตรวจสอบให้แน่ใจว่าได้รีเฟรชในตอนนี้และจากนั้นสุ่มปลอดภัยที่ใช้สำหรับการเริ่มต้นตัวอย่างเช่นคุณอาจมีหนึ่งสุ่มปลอดภัยที่สร้างขึ้นต่อลูกค้าโดยใช้หนึ่งเครื่องกำเนิดไฟฟ้าแบบสุ่มปลอม mersenne twister หลอกต่อลูกค้าได้รับการสุ่มสูงพอ

ตามเอกสารประกอบอัลกอริทึมที่แตกต่างกันที่ใช้โดย SecureRandom คือตามลำดับของการตั้งค่า:

• บนระบบ * NIX ส่วนใหญ่
  1. NativePRNG
  2. SHA1PRNG
  3. NativePRNGBlocking
  4. NativePRNGNonBlocking
• บนระบบ Windows
  1. SHA1PRNG
  2. ใช้ Windows PRNG

เมื่อคุณถามเกี่ยวกับ Linux ฉันจะเพิกเฉยต่อการติดตั้ง Windows และ SunPKCS11 ซึ่งมีเฉพาะใน Solaris เท่านั้นเว้นแต่คุณจะติดตั้งด้วยตัวคุณเองแล้วคุณจะไม่ถามคำถามนี้

ตามเอกสารเดียวกันเหล่านั้นขั้นตอนวิธีการเหล่านี้ใช้คืออะไร

SHA1PRNG การ
เริ่มต้นเริ่มต้นทำได้ในขณะนี้ผ่านการรวมกันของคุณสมบัติของระบบและอุปกรณ์รวบรวมเอนโทรปีของ java.security

NativePRNG
nextBytes()ใช้การ/dev/urandom
generateSeed()ใช้งาน/dev/random

NativePRNGBlocking
nextBytes()และการgenerateSeed()ใช้งาน/dev/random

NativePRNGNon การล็อค
nextBytes()และการgenerateSeed()ใช้งาน/dev/urandom

ซึ่งหมายความว่าถ้าคุณใช้SecureRandom random = new SecureRandom()มันจะลงรายการนั้นจนกว่าจะพบรายการที่ใช้งานได้ซึ่งโดยทั่วไปจะเป็น NativePRNG และนั่นหมายความว่ามันเมล็ดตัวเองจาก/dev/random(หรือใช้ว่าถ้าคุณสร้างเมล็ดอย่างชัดเจน) จากนั้นใช้/dev/urandomสำหรับการรับไบต์ถัดไป, ints, double, booleans สิ่งที่มีคุณ

เนื่องจาก/dev/randomกำลังบล็อก (จะบล็อกจนกว่าจะมีเอนโทรปีเพียงพอในพูลเอนโทรปี) ซึ่งอาจขัดขวางประสิทธิภาพการทำงาน

วิธีแก้ปัญหาหนึ่งที่ใช้สิ่งที่ต้องการได้สร้างเอนโทรปีเพียงพอโซลูชั่นอื่นใช้/dev/urandomแทน ในขณะที่คุณสามารถตั้งค่าว่าสำหรับ JVM ทั้งเป็นทางออกที่ดีจะทำมันเช่นนี้เฉพาะโดยใช้SecureRandom SecureRandom random = SecureRandom.getInstance("NativePRNGNonBlocking")โปรดทราบว่าวิธีการที่สามารถโยน NoSuchAlgorithmException ถ้า NativePRNGNonBlocking ดังนั้นได้เตรียมที่จะย้อนกลับไปเริ่มต้น

SecureRandom random;
try {
    random = SecureRandom.getInstance("NativePRNGNonBlocking");
} catch (NoSuchAlgorithmException nsae) {
    random = new SecureRandom();
}

นอกจากนี้ทราบว่าในระบบระวัง * อื่น ๆอาจจะทำงานแตกต่างกัน/dev/urandom

คือ/dev/urandomสุ่มเพียงพอหรือไม่

ภูมิปัญญาดั้งเดิมมีเพียงว่ามัน/dev/randomสุ่มพอ อย่างไรก็ตามเสียงบางอย่างแตกต่างกัน ใน"วิธีที่ถูกต้องในการใช้ SecureRandom"และ"Myths about / dev / urandom"เป็นที่ถกเถียงกันอยู่ว่า/dev/urandom/ดี

ผู้ใช้มากกว่าในการรักษาความปลอดภัยข้อมูลสแต็คเห็นด้วยกับที่ โดยทั่วไปถ้าคุณต้องถาม/dev/urandomก็ดีสำหรับวัตถุประสงค์ของคุณ

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

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

อย่าประนีประนอมกับการสร้างตัวเลขสุ่ม จุดอ่อนที่ทำให้ความปลอดภัยของคุณลดลง

ฉันไม่เห็นเครื่องกำเนิดไฟฟ้าแบบปรมาณู COTS จำนวนมาก แต่มีหลายแผนสำหรับพวกเขาหากคุณต้องการข้อมูลสุ่มจำนวนมาก เว็บไซต์หนึ่งที่มีสิ่งที่น่าสนใจให้ดูเสมอรวมถึง HotBits คือJohn Walker's Fourmilab

ดูเหมือนว่าคุณควรมีความชัดเจนเกี่ยวกับข้อกำหนด RNG ของคุณ ความต้องการเข้ารหัสลับ RNG ที่แข็งแกร่งที่สุด (เท่าที่ฉันเข้าใจ) จะเป็นเช่นนั้นแม้ว่าคุณจะรู้ว่าอัลกอริทึมที่ใช้สร้างมันและคุณรู้ว่าตัวเลขสุ่มที่สร้างขึ้นก่อนหน้านี้ทั้งหมดคุณไม่สามารถรับข้อมูลที่เป็นประโยชน์เกี่ยวกับตัวเลขสุ่มใด ๆ ในอนาคตโดยไม่ต้องใช้พลังในการคำนวณที่ไม่สามารถทำได้

หากคุณไม่ต้องการการรับประกันแบบสุ่มเต็มรูปแบบอาจมีการแลกเปลี่ยนประสิทธิภาพที่เหมาะสม ฉันมักจะเห็นด้วยกับคำตอบของ Dan Dyerเกี่ยวกับ AESCounterRNG จาก Uncommons-Maths หรือ Fortuna (หนึ่งในผู้แต่งคือ Bruce Schneier ผู้เชี่ยวชาญในวิทยาการเข้ารหัส) ฉันไม่เคยใช้อย่างใดอย่างหนึ่ง แต่ความคิดที่ปรากฏมีชื่อเสียงได้อย่างรวดเร็วก่อน

ฉันจะ คิดว่าถ้าคุณสามารถสร้างเมล็ดเริ่มต้นสุ่มเป็นระยะ ๆ (เช่นวันละครั้งหรือชั่วโมงหรืออะไรก็ตาม) คุณสามารถใช้รหัสกระแสเร็วเพื่อสร้างตัวเลขสุ่มจากชิ้นต่อเนื่องของกระแส (ถ้ากระแสตัวเลขใช้ XOR เพียงแค่ ผ่านในกระแสของค่า null หรือคว้าบิต XOR โดยตรง) eStream ของECRYPTโครงการมีข้อมูลที่ดีมากมายรวมถึงการวัดประสิทธิภาพ สิ่งนี้จะไม่รักษาเอนโทรปีระหว่างจุดที่คุณเติมใหม่ดังนั้นถ้ามีคนรู้หนึ่งในตัวเลขสุ่มและอัลกอริทึมที่คุณใช้เทคนิคอาจเป็นไปได้ด้วยกำลังการคำนวณจำนวนมากเพื่อทำลายการเข้ารหัสและ เดาสถานะภายในของมันเพื่อให้สามารถทำนายตัวเลขสุ่มในอนาคต แต่คุณต้องตัดสินใจว่าความเสี่ยงและผลที่ตามมานั้นเพียงพอที่จะพิสูจน์ค่าใช้จ่ายในการรักษาเอนโทรปีหรือไม่

แก้ไข: นี่คือบางส่วนของหลักสูตรการเข้ารหัสลับใน RNG ที่ฉันพบใน 'สุทธิที่มีความเกี่ยวข้องกับหัวข้อนี้มาก

หากฮาร์ดแวร์ของคุณรองรับลองใช้ Java RdRand Utilityซึ่งฉันเป็นผู้เขียน

เป็นไปตามRDRANDคำสั่งของ Intel และเร็วกว่าประมาณ 10 เท่าSecureRandomและไม่มีปัญหาเกี่ยวกับแบนด์วิดท์สำหรับการใช้งานในปริมาณมาก

โปรดทราบว่าการติดตั้งนี้ใช้งานได้เฉพาะกับซีพียูเหล่านั้นที่ให้คำแนะนำ (เช่นเมื่อrdrandตั้งค่าตัวประมวลผล) คุณต้องสร้างอินสแตนซ์ของมันผ่านตัวRdRandRandom()สร้าง ไม่มีProviderการใช้งานที่เฉพาะเจาะจง

สิ่งอื่นที่ควรดูคือคุณสมบัติ securerandom.source ในไฟล์ lib / security / java.security

อาจมีประโยชน์ด้านประสิทธิภาพการใช้ / dev / urandom มากกว่า / dev / random โปรดจำไว้ว่าหากคุณภาพของตัวเลขสุ่มมีความสำคัญอย่าทำให้ความปลอดภัยลดลง