Java.security.egd विकल्प क्या है?

Question

मैं जिस प्रोजेक्ट पर काम कर रहा हूं, उसी के समान कमांड का उपयोग करके एप्लिकेशन लॉन्च किया गया है:

java -Djava.security.egd=file:/dev/urandom -jar app.jar

मैंने पहले कभी java.security.egdविकल्प नहीं देखा । थोड़ा खोज करने पर, यह जावा अनुप्रयोग में यादृच्छिक संख्या पीढ़ी को कॉन्फ़िगर करने के लिए उपयोग किया जाता है।

क्या यह सही है? कब लागू किया जाना है?

Answer 1

जावा एप्लिकेशन क्रिप्टोग्राफिक रूप से मजबूत छद्म यादृच्छिक संख्या जनरेटर ( CSPRNG ) का उपयोग करके क्रिप्टोग्राफिक रूप से मजबूत यादृच्छिक मूल्यों का उत्पादन करने के लिए java.security.SecureRandom वर्ग का उपयोग कर सकते हैं और करना चाहिए । Java.util.Random क्लास के मानक JDK कार्यान्वयन को क्रिप्टोग्राफिक रूप से मजबूत नहीं माना जाता है।

यूनिक्स की तरह के ऑपरेटिंग सिस्टम में /dev/randomएक विशेष फाइल होती है जो डिवाइस ड्राइवर्स और अन्य स्रोतों से एकत्र किए गए पर्यावरणीय शोर तक पहुँचने वाले छद्म यादृच्छिक संख्याओं को परोसती है। हालाँकि, यह ब्लॉक करता है यदि अनुरोध की तुलना में कम एन्ट्रॉपी उपलब्ध है ; /dev/urandomआमतौर पर कभी ब्लॉक नहीं होता है, भले ही छद्म आयामी जनरेटर जनरेटर बीज बूट के बाद एन्ट्रापी के साथ पूरी तरह से प्रारंभिक नहीं था। अभी भी एक 3 विशेष फ़ाइल है, /dev/arandomजो बूट के बाद ब्लॉक करता है जब तक कि बीज को पर्याप्त एन्ट्रॉपी के साथ सुरक्षित रूप से आरंभीकृत नहीं किया गया है, और फिर कभी भी ब्लॉक नहीं करता है।

डिफ़ॉल्ट रूप से, JVM सिक्योर रैंडम क्लास का उपयोग करके बीज देता है /dev/random, इसलिए आपका जावा कोड अप्रत्याशित रूप से ब्लॉक हो सकता है । -Djava.security.egd=file:/dev/./urandomजावा प्रक्रिया शुरू करने के लिए उपयोग की जाने वाली कमांड लाइन इनवोकेशन का विकल्प जेवीएम को /dev/urandomइसके बजाय उपयोग करने के लिए कहता है ।

अतिरिक्त SHA1PRNG एल्गोरिथ्म/./ का उपयोग करने के लिए JVM बनाने के लिए लगता है जो PRAG (छद्म रैंडम नंबर जेनरेटर) की नींव के रूप में SHA-1 का उपयोग करता है। यह /dev/urandomनिर्दिष्ट किए जाने पर उपयोग किए गए NativePRNG एल्गोरिथम से अधिक मजबूत है ।

अंत में, एक मिथक है /dev/urandomजो एक छद्म यादृच्छिक संख्या जनरेटर है, एक PRNG है, जबकि /dev/randomएक "सच" यादृच्छिक संख्या जनरेटर है । यह केवल सच नहीं है, दोनों /dev/randomऔर /dev/urandomएक ही CSPRNG (क्रिप्टोग्राफी द्वारा सुरक्षित कूट-यादृच्छिक संख्या जनरेटर) द्वारा खिलाया जाता है। केवल व्यवहार जब उनके संबंधित पूल एंट्रोपी से बाहर निकलते हैं, तो कुछ अनुमान के अनुसार, भिन्न होता है: /dev/randomब्लॉक, जबकि /dev/urandomनहीं।

एन्ट्रापी कम चलने के बारे में क्या? इससे कोई फर्क नहीं पड़ता।

यह पता चला है कि "बेतरतीब दिखना" हमारे क्रिप्टोग्राफिक बिल्डिंग ब्लॉकों के बहुत सारे के लिए बुनियादी आवश्यकता है। और यदि आप एक क्रिप्टोग्राफिक हैश का उत्पादन लेते हैं, तो इसे यादृच्छिक स्ट्रिंग से अप्रभेद्य होना चाहिए ताकि सिफर इसे स्वीकार करेंगे। यह SHA1PRNG एल्गोरिथ्म का उपयोग करने का कारण है, क्योंकि यह एक बीज के साथ हैश फ़ंक्शन और एक काउंटर का उपयोग करता है।

कब लागू किया जाना है?

हमेशा, मैं कहूंगा।

स्रोत:
https://gist.github.com/svrc/5a8accc57219b9548fe1
https://www.2uo.de/myths-about-urandom

---

EDIT 04/2020:

एक टिप्पणी में जावा 8 में सिक्योर रैंडम क्लास के व्यवहार पर बदलाव का उल्लेख किया गया है ।

SHA1PRNG और NativePRNG को java.srurity फ़ाइल में SecureRandom बीज स्रोत गुणों का ठीक से सम्मान करने के लिए निर्धारित किया गया था। (फ़ाइल का उपयोग करते हुए अस्पष्ट वर्कअराउंड: /// dev / urandom और फ़ाइल: / dev /./ यूरेनियम की अब आवश्यकता नहीं है।)

यह पहले से ही ऊपर दिए गए स्रोत अनुभाग में संदर्भित परीक्षणों द्वारा इंगित किया गया था। अतिरिक्त 8 में SecureRanom/./ द्वारा उपयोग किए गए एल्गोरिदम को NativePRNG से SHA1PRNG में बदलने की आवश्यकता है ।

हालाँकि, मेरे पास कुछ ऐसी खबरें हैं जिन्हें मैं साझा करना चाहता हूं। के रूप में प्रति JEP-273 , जावा 9 के बाद से SecureRandom वर्ग औजार तीन नियतात्मक यादृच्छिक बिट जनरेटर (DRBG) तंत्र में वर्णित NIST 800-90Ar1 । ये मैकेनिज्म आधुनिक एल्गोरिदम को SHA-512 और AES-256 जितना मजबूत बनाता है।

JDK में दो प्रकार के सिक्योर रैंडम कार्यान्वयन थे:

• एक प्लेटफ़ॉर्म-निर्भर है और देशी कॉल या ओएस उपकरणों पर आधारित है जैसे कि /dev/{u}randomयूनिक्स पर पढ़ना या विंडोज पर क्रिप्टोकरेंसी का उपयोग करना। लिनक्स और विंडोज के नवीनतम रिलीज पहले से ही डीआरबीजी का समर्थन करते हैं, लेकिन पुराने रिलीज और एम्बेडेड सिस्टम नहीं हो सकते हैं ।
• दूसरी तरह का शुद्ध जावा कार्यान्वयन है जो पुराने SHA1- आधारित RNG कार्यान्वयन का उपयोग करता है, जो कि स्वीकृत DRBG तंत्र द्वारा उपयोग किए गए एल्गोरिदम जितना मजबूत नहीं है।

इस बीच जावा 13 सुरक्षा डेवलपर की गाइड अभी भी पढ़ती है

Linux और macOS पर, यदि java.security में एन्ट्रापी सभा उपकरण file:/dev/urandomया पर सेट है file:/dev/random, तो NativePRNG SHA1PRNG को पसंद किया जाता है। अन्यथा, SHA1PRNG को प्राथमिकता दी जाती है।

यह स्पष्ट करने के लिए कि नए DRBG तंत्र पिछले PRNGs के साथ कैसे खेलते हैं, मैं AdoptOpenJDK (13.0.2 + 8 का निर्माण) के साथ macOS (डार्विन) पर कुछ परीक्षण चलाता हूं। यहाँ परिणाम हैं:

फ़ाइल: / dev / यादृच्छिक
प्रदाताओं के लिए वरीयता क्रम:

SecureRandom.NativePRNG
SecureRandom.DRBG
SecureRandom.SHA1PRNG

फ़ाइल: / dev / urandom
प्रदाताओं के लिए वरीयता का क्रम:

SecureRandom.NativePRNG
SecureRandom.DRBG
SecureRandom.SHA1PRNG

फ़ाइल: / dev /./ यूरेनियम का
प्रदाताओं के लिए वरीयता क्रम:

SecureRandom.DRBG
SecureRandom.SHA1PRNG
SecureRandom.NativePRNG

निष्कर्ष:

मैं -Djava.security.egd=file:/dev/./urandomयह सुनिश्चित करने के लिए उपयोग करूंगा कि प्लेटफ़ॉर्म का अप्रत्याशित रूप से अवरुद्ध होने से बचने के लिए उपयोग किए गए प्लेटफ़ॉर्म का उपयोग किए बिना सबसे सुरक्षित सिक्योर रैंडम कार्यान्वयन का लाभ उठाएं ।

Comments

जावा 8 के रूप में, फ़ाइल के नाम में "/ अस्पष्ट वर्कअराउंड" की आवश्यकता नहीं है, इसलिए आप बस "/ dev / urandom" का उपयोग कर सकते हैं, देखें: docs.oracle.com/javase/8/docs / तकनीकी / गाइड / सुरक्षा /…

— कमल

उत्तर को अपडेट करने के लिए धन्यवाद (विशेष रूप से जावा 9 और 13 में परिवर्तन के बारे में)। मेरी समझ के अनुसार, हालांकि, Java 8 में "एंट्रॉपी गैम्बलिंग डिवाइस" को / dev / urandom या /dev/./ आयामी को सेट करने पर ठीक उसी परिणाम प्राप्त होने चाहिए, अन्यथा फिक्स का कोई मतलब नहीं होगा। एक ओएस के नजरिए से, वे एक ही समान फ़ाइल की ओर इशारा करते हैं, ताकि जावा को प्रभावित न करें (यह फिक्स से पहले किया था, लेकिन यह एक बग था, एक इच्छित विशेषता नहीं)। इसलिए आपका कथन "PRNG चयन को प्रभावित करने के लिए अतिरिक्त / / की आवश्यकता है।" जावा 8. के ​​रूप में अब सच नहीं होना चाहिए

— कमल

धन्यवाद @Kalal आपकी टिप्पणियों के लिए। मेरा पिछला वाक्यांश "PRNG चयन" पर्याप्त स्पष्ट नहीं था। मैंने यह स्पष्ट करने के लिए इसे दोहराया है कि मैं उपयोग किए गए एल्गोरिथ्म के बारे में बात कर रहा हूं: NativePRNG या SHA1PRNG। के उपयोग के /dev/urandomचयन NativePRNG से तंग आ गया /dev/urandom, जबकि /dev/./urandomऊपर SHA1PRNG की पसंद (भी द्वारा खिलाया /dev/urandom) जब जब जावा 8 का उपयोग कर जावा 9 के बाद से, DRBG पूर्वता लेता है /dev/./urandomस्रोत निर्दिष्ट किया जाता है।

— प्रातः

Answer 2

यदि आप JDK 8 या उच्चतर का उपयोग कर रहे हैं तो इसकी आवश्यकता नहीं है

मुद्दा जावा द्वारा तय किया गया है और यहां कुछ लिंक दिए गए हैं

रेखांकित करें

SHA1PRNG और NativePRNG को java.srurity फ़ाइल में SecureRandom बीज स्रोत गुणों का ठीक से सम्मान करने के लिए निर्धारित किया गया था। (फ़ाइल का उपयोग करते हुए अस्पष्ट वर्कअराउंड: /// dev / urandom और फ़ाइल: / dev /./ यूरेनियम की अब आवश्यकता नहीं है।)

अधिक जानकारी के लिए (पृष्ठ में यादृच्छिक के लिए खोज):

https://docs.oracle.com/javase/8/docs/technotes/guides/security/enhancements-8.html

https://www.oracle.com/technetwork/java/javase/8-whats-new-2157071.html

Comments

मैं नहीं मानता कि यह सही है। पृष्ठभूमि के लिए: tersesystems.com/blog/2015/12/17/… जावा 8 में सुधार केवल यह कहता है कि वे अब java.security फ़ाइल में SecureRandom बीज स्रोत गुणों का सम्मान करते हैं। लेकिन डिफ़ॉल्ट रूप से इसमें अभी भी शामिल है: securerandom.source = फ़ाइल: / dev / random "अस्पष्ट वर्कअराउंड" अतिरिक्त के लिए संदर्भित करता है। / फ़ाइल नाम में भी स्वीकार किए जाते हैं (और सबसे अधिक मतदान) उत्तर द्वारा उल्लेख किया गया है।

— कमल

"अस्पष्ट वर्कअराउंड" केवल विशिष्ट परिस्थितियों में आवश्यक था , देखें: Bugs.java.com/bugdatabase/view_bug.do?bug_id=6202721

— कमल

@ कामल आपके द्वारा पोस्ट किए गए लिंक जावा 6 और उससे पहले का है,

— वेणु माधव

ठीक यही बिंदु, यह जावा 8 में तय किया गया था। बग रिपोर्ट के अनुसार, जावा 1.4.2 के बाद "अस्पष्ट वर्कअराउंड" (फ़ाइल नाम में अतिरिक्त ./ जोड़ने) की आवश्यकता थी और 6. मैं मान रहा हूं। जावा 7 में भी, अन्यथा इसे जावा 8 में तय नहीं किया गया है। यदि आप एक गैर-अवरोधक डिवाइस का उपयोग करना चाहते हैं, तो सेटिंग / देव / रैंडम के बजाय सेटिंग / देव / रैंडम की अभी भी आवश्यकता है।

— कमल

Answer 3

यह लिनक्स /dev/randomऔर /dev/urandomयादृच्छिक संख्या जनरेटर के अंतर से संबंधित है ।

इस लिंक से लिया गया

जावा बग 6202721 बताता है कि java.security.SecureRandom / dev / random के बजाय / dev / random का उपयोग करता है भले ही / dev / urandom निर्दिष्ट हो क्योंकि उस समय (लगभग 2004) / dev / urandom ठीक से काम नहीं कर रहा था। बग को अब कभी भी उलट नहीं किया गया है कि / dev / urandom काफी अच्छी तरह से काम करता है। इसलिए, आपको / देव / यादृच्छिक के बजाय SHA1PRNG के उपयोग को मजबूर करने के लिए /dev/./urandom का उपयोग करके सेटिंग को अस्पष्ट करके इसे नकली करना होगा।

तुम्हारे प्रश्न का उत्तर देने के लिए

कब लागू किया जाना है?

उपरोक्त लिंक के आधार पर, यह जावा संस्करण 5 के लिए कुछ अद्वितीय है और इसके बाद 2004 में लिनक्स सिस्टम पर / dev / urandom के साथ समस्याओं का परिणाम है।

Comments

उस लेख में शायद एक टाइपो है, जैसा कि जावा बग 6202721 बताता है कि "यह एक समस्या है अगर / dev / urandom को चुना गया क्योंकि / dev / random ठीक से काम नहीं कर रहा है।" इसलिए आपका निष्कर्ष "/ dev / urandom के साथ समस्याओं के परिणामस्वरूप" गलत है। डिफॉल्ट (/ देव / रैंडम) के बजाय चुनने पर / dev / urandom पर स्पष्टीकरण के लिए स्वीकृत उत्तर देखें। यह ज्यादातर मामलों में एक अच्छा विचार है।

— कमल