Score:4

Java: SecureRandom.getInstanceStrong() เทียบกับ SecureRandom() ใหม่

ธง ht

ที่ให้ไว้ สุ่มที่ปลอดภัย ฉันถือว่าคลาสนี้เหมาะสำหรับใช้ในการเข้ารหัส ใหม่ SecureRandom() เพื่อความปลอดภัย (คำตลกๆ รึเปล่า?)

ถ้า ใหม่ SecureRandom() ปลอดภัยอยู่แล้วจะมีประโยชน์อะไรในการใช้งาน SecureRandom.getInstanceStrong() แทน?

นี่เป็นความแตกต่างแบบเดียวกับระหว่าง /dev/urandom และ /dev/สุ่ม?

ฉันกำลังถกเถียงเรื่องนี้ในสถานการณ์ต่อไปนี้ ซึ่งส่วนใหญ่ฉันกังวลเกี่ยวกับการสุ่ม IV (สำหรับใช้กับ AES-GCM):

ส่วนตัวสุดท้าย SecureRandom secureRandom = ใหม่ SecureRandom();

[...]

ไบต์ส่วนตัว [] getIv () {
    int ivLength = 12;
    ไบต์ [] iv = ไบต์ใหม่ [ivLength];
    secureRandom.nextBytes(iv);
    iv กลับ;
}
kelalaka avatar
in flag
[ดูเชิงอรรถ: ขึ้นอยู่กับระบบปฏิบัติการ ใน IOS จะเหมือนกัน](https://crypto.stackexchange.com/a/85545/18298)
kelalaka avatar
in flag
นี่คือการเรียกไลบรารี่เพื่อรับอินสแตนซ์... [SecureRandom.getInstanceStrong()](https://docs.oracle.com/javase/8/docs/api/java/security/SecureRandom.html) ดู [คำตอบของ Maarten ดังนั้น ](https://stackoverflow.com/a/37256739/1820553)
Paul Uszak avatar
cn flag
อีกครั้ง. สุ่ม: ไม่ (สำหรับเคอร์เนลเวอร์ชันเก่าของ ex.NSA) `\dev\random` เป็น TRNG ในขณะที่ `dev\urandom` เป็น PRNG
Gilles 'SO- stop being evil' avatar
GCM IV ไม่จำเป็นต้องสุ่ม ต้องไม่ซ้ำใครเท่านั้น ดังนั้นสำหรับกรณีเฉพาะนี้ มันไม่สำคัญ เหตุผลเดียวที่จะใช้ IV แบบสุ่มสำหรับ GCM คือหากคุณจำ IV ทั้งหมดที่เคยใช้ก่อนหน้านี้ไม่ได้ ดังนั้นคุณจึงต้องพึ่งพาความเป็นเอกลักษณ์ทางสถิติแทน สำหรับสิ่งนั้น แค่มีค่าสุ่มทางสถิติก็เพียงพอแล้ว ไม่จำเป็นต้องสุ่มแบบเข้ารหัสด้วยซ้ำ (ซึ่งเป็นคุณสมบัติที่แข็งแกร่งกว่า รวมถึงความคาดเดาไม่ได้และความเป็นอิสระจากค่าสุ่มอื่นๆ ทั้งหมด)
Paul Uszak avatar
cn flag
@kelalaka นี่เป็นเรื่องยุ่งเหยิงของ Java จริงๆ `securerandom.source=file:/dev/random` ซึ่งบล็อก (ed) แน่นอนดังนั้น หากคุณแยกเซิร์ฟเวอร์แอปออก อาจใช้เวลาห้านาทีในการส่งคืนคำขอ http แม้แต่เว็บไซต์ที่ไม่ใช่ https บ้าๆ บอๆ อย่างเว็บไซต์ของฉัน ซึ่งค่อนข้างน่าประหลาดใจ (อาจเป็นการสร้างคุกกี้)
kelalaka avatar
in flag
สิ่งที่ @Gilles พูดนั้นเป็นความจริง หากเป็นไปได้ ให้ใช้ [AES-GCM-SIV](https://crypto.stackexchange.com/q/82105/18298) เพื่อลดปัญหานี้...
Score:2
ธง in

SecureRandom.getInstanceStrong() จะทำให้แน่ใจว่าจะใช้อัลกอริทึมที่แข็งแกร่ง (securerandom.strongAlgorithms)

  • มีจำหน่ายตั้งแต่ จาวาเวอร์ชัน 8. ตรวจสอบเวอร์ชั่นของคุณก่อนเริ่มใช้งาน

  • ถ้า ไม่มีอัลกอริทึมดังกล่าว ในการเรียกใช้ VM มันจะโยน ไม่มีข้อยกเว้นอัลกอริทึมดังกล่าว.

  • ความล้มเหลวนี้เป็นแนวทางปฏิบัติที่ดีกว่าแทนที่จะใช้ค่าเริ่มต้นในการรักษาความปลอดภัยที่อ่อนแอ

kelalaka avatar
in flag
ยินดีต้อนรับสู่การเข้ารหัส ลิงก์ไปยังการอ้างสิทธิ์หรือบรรทัดรหัสจากแหล่งที่มาจะทำให้คำตอบนี้ดีขึ้นมาก มิฉะนั้นนี่คือการอ้างสิทธิ์ด้วยตนเอง ตัวอย่างเช่น อาจกล่าวได้ว่าไม่มีอัลกอริทึมที่แข็งแกร่ง (ความหมายของความแข็งแกร่งคืออะไร) จากนั้นจะใช้อัลกอริทึมเริ่มต้น java.util.Random จำเป็นต้องมีการอ้างอิงและในกรณี Java แม้แต่เวอร์ชัน..
in flag
ขอบคุณสำหรับความคิดเห็นของคุณ kelalaka ฉันได้เพิ่มคำอธิบายอีกเล็กน้อยตามที่คุณแนะนำ
kelalaka avatar
in flag
มีรายการอัลกอริทึมที่แข็งแกร่งหรือไม่?
Paul Uszak avatar
cn flag
@kelalaka 'Strong' เป็นคำทั่วไปที่ใช้โดยนักเข้ารหัส หน่วยงาน และรัฐบาลเผด็จการ เพื่อระบุว่าการเข้ารหัสไม่สามารถเอาชนะได้แบบเรียลไทม์ มีรายการ[ที่นี่](https://crypto.stackexchange.com/a/62515/23115) ฉันไม่รู้ว่าควรเพิ่ม AES หรือไม่เนื่องจากไม่มีหลักฐานทางคณิตศาสตร์ว่ายังคงปลอดภัย
kelalaka avatar
in flag
@PaulUszak ฉันกำลังพูดถึงในบริบทของ Java Security และโดยเฉพาะเกี่ยวกับตัวสร้างตัวเลขสุ่ม

โพสต์คำตอบ

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