/ Dev / random से पढ़ने से कोई डेटा उत्पन्न नहीं होता है

Question

मैं अक्सर कमांड का उपयोग करता हूं

cat /dev/urandom | strings --bytes 1 | tr -d '\n\t ' | head --bytes 32

छद्म यादृच्छिक पासवर्ड उत्पन्न करने के लिए। यह साथ काम नहीं करता है /dev/random।

विशेष रूप से

• cat /dev/urandom | strings --bytes 1 | tr -d '\n\t ' उत्पादन करता है
• cat /dev/random | strings --bytes 1 उत्पादन करता है
• cat /dev/random | strings --bytes 1 | tr -d '\n\t ' उत्पादन नहीं करता है

NB: जब /dev/randomआप का उपयोग कर अपने माउस या प्रेस कुंजी (जैसे ctrl, शिफ्ट, आदि) एंट्रॉपी उत्पन्न करने के लिए हो सकता है।

अंतिम उदाहरण काम क्यों नहीं करता है? क्या trकिसी प्रकार के बड़े आंतरिक बफर हैं जो /dev/urandomजल्दी से भरते हैं लेकिन /dev/randomनहीं करते हैं?

PS मैं सेंटोस 6.5 का उपयोग कर रहा हूं

cat /proc/version
Linux version 2.6.32-431.3.1.el6.x86_64 ([e-mail]) (gcc version 4.4.7 20120313 (Red Hat 4.4.7-4) (GCC) ) #1 SMP Fri Jan 3 21:39:27 UTC 2014

Comments

आपका वितरण, आपका कर्नेल संस्करण क्या है? Cygwin पर दोनों मान लौटाते हैं।

— कीवी

@ कीवी देखें संपादित करें।

— आरोन जे लैंग

तुम्हें पता है pwgen, विशेष रूप से pwgen -s?

— एमवीजी

-sस्विच उन्हें, कम यादगार अधिक सही मायने में यादृच्छिक बनाता है। @ बोयड: डेबियन- डिस्ट्रोस से परे व्यापक रूप से उपलब्ध है? जिस तरह से मैं इसे देखता हूं, pwgen CentOS के लिए उपलब्ध है जबकि मेकपासवार्ड नहीं है ।

— एमवीजी

@BoydStephenSmithJr। मैं makepasswdअपने मंच पर उपलब्ध नहीं है @ MvG के साथ , वैसे भी धन्यवाद

— हारून जे लैंग

Answer 1

यह अंततः होगा।

में:

cat /dev/random | strings --bytes 1 | tr -d '\n\t '

cat कभी भी बफर नहीं करेगा, लेकिन यह वैसे भी बहुत बढ़िया है क्योंकि यहां कुछ भी नहीं है।

< /dev/random strings --bytes 1 | tr -d '\n\t '

stringsहालाँकि, इसका आउटपुट अधिक लंबा नहीं होता, क्योंकि टर्मिनल टर्मिनल पर जाने पर लाइनों के विपरीत, ब्लॉक (4 या 8kB जैसी किसी चीज़) से इसका आउटपुट बफ़र करेगा ।

इसलिए यह केवल स्टडआउट के लिए लिखना शुरू कर देगा जब उसने 4kB मूल्य के वर्णों को आउटपुट के लिए जमा कर लिया है, जो /dev/randomकि कुछ समय लेने वाला है।

trआउटपुट एक टर्मिनल पर जाता है (यदि आप एक शेल प्रॉम्प्ट में एक टर्मिनल पर चल रहे हैं), तो यह अपने आउटपुट लाइन-वार को बफर करेगा। क्योंकि आप इसे हटा रहे हैं \n, इसलिए इसमें लिखने के लिए पूरी लाइन नहीं होगी, इसलिए इसके बजाय, यह तब ही लिखेगा जब एक पूर्ण ब्लॉक जमा हो गया हो (जैसे कि आउटपुट टर्मिनल पर नहीं जाता है)।

इसलिए, trजब तक stringsकि /dev/random8kB (2 ब्लॉक संभवतः बहुत अधिक) लिखने के लिए पर्याप्त रूप से पढ़ा गया है, तब तक कुछ भी नहीं लिखने की संभावना है (क्योंकि पहले ब्लॉक में शायद कुछ नई पंक्ति या टैब या अंतरिक्ष वर्ण होंगे)।

इस प्रणाली पर मैं यह कोशिश कर रहा हूं, मैं प्रति सेकंड 3 बाइट का औसत प्राप्त कर सकता हूं /dev/random(जैसा कि 12MiB पर विरोध किया गया है /dev/urandom), इसलिए सबसे अच्छी स्थिति में (पहले 4096 बाइट्स /dev/randomसभी प्रिंट करने योग्य हैं), हम कर रहे हैं trकुछ भी आउटपुट करने के लिए 22 मिनट पहले बात करना। लेकिन यह अधिक होने की संभावना है घंटे (एक त्वरित परीक्षण में, मैं stringsहर 1 से 2 ब्लॉक को पढ़ते हुए एक ब्लॉक लिखता देख सकता हूं , और आउटपुट ब्लॉक में लगभग 30% नईलाइन वर्ण हैं, इसलिए मुझे उम्मीद है कि इसे पढ़ने की आवश्यकता होगी पहले कम से कम 3 ब्लॉक में trआउटपुट के लिए 4096 अक्षर हैं)।

इससे बचने के लिए, आप कर सकते हैं:

< /dev/random stdbuf -o0 strings --bytes 1 | stdbuf -o0 tr -d '\n\t '

stdbuf एक GNU कमांड (कुछ BSD पर भी पाया जाता है) जो LD_PRELOAD ट्रिक के माध्यम से कमांड के stdio बफरिंग को बदल देता है।

ध्यान दें कि इसके बजाय strings, आप उपयोग कर सकते हैं tr -cd '[:graph:]'जो टैब, न्यूलाइन और स्पेस को भी बाहर करेगा।

आप CUTF-8 वर्णों के साथ संभावित भविष्य के आश्चर्य से बचने के लिए स्थान को ठीक करना चाहते हैं ।

Comments

वाह प्रभावशाली व्याख्या।

— कीवी

गजब का! महान व्याख्या और समाधान। मैंने हमेशा cat'बेकार' का उपयोग किया है क्योंकि मुझे पाइपलाइन के अंत में पुनर्निर्देशन को कभी पसंद नहीं किया गया था, अब मैं 'एक प्रक्रिया को बचा सकता हूं' और अभी भी पठनीय कमांड हैं। मेरा अंतिम समाधान था< /dev/random stdbuf -o0 tr -Cd '[:graph:]' | stdbuf -o0 head --bytes 32

— हारून जे लैंग

@AaronJLang, के बारे में अच्छी बात [:graph:]। मैं उस एक के बारे में भूल गया था।

— स्टीफन चेज़लस

@AaronJLang, आप की जरूरत नहीं है stdbufके लिए head -c32जब तक आप इसे ही डेटा लिखने के लिए अनुमति देना चाहते हैं के रूप में यह समझ में आ गया है (जैसे जल्द ही यह के रूप में के रूप में एक 32byte हिस्सा के बजाय कई मात्रा में उन्हें मिल गया)

— स्टीफन Chazelas

मेरी राय में, लेखक के उपयोग के लिए / dev / urandom पर्याप्त है। अगर किसी को यह जानने की उत्सुकता होती है कि कैसे, विशेष रूप से, यादृच्छिक की तुलना में यूरेनियम काम करता है, तो मैं सुझाव देता हूं कि ड्राइवर के शीर्ष पर टिप्पणियों को पढ़ें / कर्नेल स्रोत पेड़ के char / random.c में। टिप्पणियों में PRNG के विश्लेषण का उल्लेख है और यह कार्यान्वयन है। उम्मीद है, यह पेपर इस सवाल का जवाब देगा कि "बस यादृच्छिक की तुलना में कम या ज्यादा यादृच्छिक है?" यहाँ उपलब्ध है: eprint.iacr.org/2012/251.pdf

— ईथर फ़िज़ा

Answer 2

कई सुरक्षा अनुप्रयोगों के लिए यादृच्छिक संख्याओं को उत्पन्न करने के लिए पर्याप्त एन्ट्रापी - एन्ट्रापी उपायों की आवश्यकता होती है कि यादृच्छिकता कितनी अप्रत्याशित है। एक नियतात्मक प्रोसेसर एन्ट्रापी उत्पन्न नहीं कर सकता है, इसलिए एन्ट्रापी बाहर से आना चाहिए - या तो गैर-नियतात्मक व्यवहार के साथ एक हार्डवेयर घटक से, या अन्य कारकों से जो पुन: पेश करने के लिए पर्याप्त रूप से कठिन हैं, जैसे कि उपयोगकर्ता क्रियाओं का समय (जो माउस को आकर्षक बना रहा है) आते हैं)। पर्याप्त एन्ट्रापी उपलब्ध होने के बाद, क्रिप्टोग्राफी का उपयोग यादृच्छिक संख्याओं की व्यावहारिक रूप से असीमित धारा उत्पन्न करने के लिए किया जा सकता है।

लिनक्स एक पूल में एन्ट्रापी को जमा करके काम करता है, फिर क्रिप्टोग्राफी का उपयोग करके /dev/randomऔर दोनों के माध्यम से स्वीकार्य यादृच्छिक संख्या का उत्पादन करने के लिए /dev/urandom। अंतर यह है कि /dev/randomएक अत्यंत रूढ़िवादी एन्ट्रापी गणना लागू करता है जो पूल में एंट्रॉपी के अनुमान को कम करता है जो हर बाइट के लिए उत्पन्न करता है, जबकि /dev/urandomपूल में एंट्रोपी की मात्रा के साथ खुद को चिंता नहीं करता है।

यदि पूल में एन्ट्रापी का अनुमान बहुत कम है, /dev/randomतब तक ब्लॉक किया जाता है जब तक कि अधिक एन्ट्रॉपी जमा नहीं की जा सकती। यह गंभीर रूप से उस दर को पंगु बना /dev/randomसकता है जिस पर उत्पादन का उत्पादन किया जा सकता है। यह वही है जो आप यहाँ देख रहे हैं। इससे कुछ लेना-देना नहीं है tr; लेकिन stringsबफरिंग के साथ आउटपुट को पढ़ता है, इसलिए इसे /dev/randomकम से कम एक बाइट इनपुट के उत्पादन के लिए एक पूर्ण बफर (कुछ केबी) को पढ़ना होगा ।

/dev/urandomक्रिप्टोग्राफिक कुंजी उत्पन्न करने के लिए पूरी तरह से स्वीकार्य है , क्योंकि एन्ट्रापी वास्तव में किसी भी बोधगम्य तरीके से कम नहीं होती है। (यदि आप अपनी मशीन को ब्रह्मांड से अधिक समय तक चालू रखते हैं, तो आप इन विचारों की उपेक्षा नहीं कर सकते हैं, लेकिन अन्यथा आप अच्छे हैं।) केवल एक ही मामला है जहां /dev/urandomअच्छा नहीं है, जो कि हौसले से स्थापित प्रणाली पर है 'अभी तक एन्ट्रापी उत्पन्न करने के लिए समय नहीं था, या एक ताज़ा बूट सिस्टम जो केवल पढ़ने के लिए मीडिया से बूट करता है।

stringsअपनी बूट श्रृंखला से दूर होने से संभवतः आपकी प्रक्रिया में तेजी आएगी। नीचे trगैर-मुद्रण वर्णों को फ़िल्टर किया जाएगा:

</dev/random LC_ALL=C tr -dc '!-~'

लेकिन आप /dev/urandomयहां उपयोग कर सकते हैं , जब तक आप ध्यान रखते हैं कि एक सिस्टम पर पासवर्ड उत्पन्न न करें जिसके पास पर्याप्त एन्ट्रॉपी जमा करने का समय नहीं है। आप लिनक्स के एंट्रॉपी पूल के स्तर की जांच कर सकते हैं /proc/sys/kernel/random/entropy_avail(यदि आप उपयोग करते हैं /dev/random, तो इस फ़ाइल में आकृति रूढ़िवादी होगी, संभवतः बहुत अधिक)।

Answer 3

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

आप random.org या इसके पासवर्ड जनरेटर या कई में से एक का उपयोग करने पर विचार कर सकते हैं, कई यादृच्छिक पासवर्ड जनरेटर जो चारों ओर तैर रहे हैं, उदाहरण के लिए कुछ कमांड लाइन युक्तियों के लिए इस पृष्ठ पर एक नज़र डालें (ऐसा नहीं है कि मैं उन सभी की सिफारिश करूंगा , लेकिन उन्हें आपको विचार देना चाहिए), या आप कुछ का उपयोग कर सकते हैं mkpasswd(1)(यहाँ फेडोरा 19 भाग पर expect-5.45-8.fc19.x86_64)।