Lava lamp की निरर्थकता: randomness का वास्तव में क्या मतलब है

 (loup-vaillant.fr)
1 पॉइंट द्वारा GN⁺ 3 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Cloudflare का lava lamp-आधारित random number प्रचार इंटरनेट encryption में किसी बड़े व्यावहारिक योगदान से ज़्यादा marketing और security theater के करीब है
  • encryption में महत्वपूर्ण बात मानों की अंतर्निहित randomness नहीं, बल्कि यह है कि attacker उन मानों के बारे में कितना जानता है; सुरक्षा इसी knowledge gap पर निर्भर करती है
  • One-time pad पर्याप्त random key को केवल एक बार इस्तेमाल करने पर plaintext की जानकारी छिपाता है, लेकिन वही key दोबारा इस्तेमाल करने पर देखी गई जानकारी के साथ मिलकर टूट जाता है
  • आधुनिक सिस्टम one-time pad की जगह CSPRNG और stream cipher का उपयोग करते हैं, और ChaCha20 या AES-256-CTR 256-bit key के साथ व्यावहारिक सुरक्षा देते हैं
  • physical true RNG में bias हटाना कठिन होता है और सुरक्षा में बढ़त भी कम मिलती है, इसलिए server द्वारा सीधे seed बनाना और fast key erasure का उपयोग करना ज़्यादा सुरक्षित और सरल design है

randomness वस्तु पर नहीं, पर्यवेक्षक की जानकारी पर निर्भर करती है

  • Cloudflare यह प्रचार करता है कि lava lamp इंटरनेट encryption में मदद करती हैं, लेकिन यह तरीका सुरक्षा में बड़े योगदान से ज़्यादा marketing और security theater के करीब है
  • Cloudflare lava lamp के अलावा double pendulums, wave motion, mobiles जैसे physical unpredictability devices भी इस्तेमाल करता है
  • केवल return 4 करने वाला XKCD-style function हमेशा 4 लौटाता है, इसलिए वस्तु के रूप में वह random नहीं है; लेकिन अगर caller केवल इतना जानता हो कि यह “एक निष्पक्ष पासे से चुना गया constant” है और उसने इसे एक बार call किया हो, तो पर्यवेक्षक के probability distribution में इसे random माना जा सकता है
  • encryption में असली सवाल यह नहीं है कि result स्वभावतः random है या नहीं, बल्कि यह है कि attacker उस result के बारे में कितना जानता है
  • एक ही मान की randomness का अर्थ इस पर बदल जाता है कि किसके पास कौन-सी जानकारी है, और cryptographic system में यही knowledge gap सुरक्षा तय करता है

One-time pad कैसे काम करता है और कैसे टूटता है

  • Russian roulette की उपमा में एक साथी को गोली की स्थिति पता है, और वह खिलाड़ी के साथ पहले से साझा किए गए पासे के मान को गोली की स्थिति में जोड़कर केवल उसका परिणाम बाहर बोलता है
  • खिलाड़ी पुकारे गए मान से पासे का मान घटाकर गोली की स्थिति पुनः प्राप्त कर सकता है, लेकिन विरोधी पासे का मान नहीं जानता, इसलिए केवल पुकारे गए मान से गोली की स्थिति नहीं जान सकता
  • अगर पासा निष्पक्ष हो, तो विरोधी की prior probability P(Ci) और किसी खास संख्या S3 सुनने के बाद की posterior probability P(Ci|S3) समान रहती है
  • Bayes formula के अनुसार P(Ci|S3) = P(Ci) × 1/6 ÷ 1/6 = P(Ci) होता है, इसलिए विरोधी पुकारा गया मान सुनकर भी कुछ नहीं सीखता
  • यही संरचना One-time pad का मूल है; पर्याप्त random key को message के साथ केवल एक बार मिलाने पर ciphertext plaintext की जानकारी प्रकट नहीं करता
  • अगर वही key दूसरे खेल में फिर इस्तेमाल हो, तो पहले खेल से सामने आई जानकारी के कारण विरोधी पासे के मान की संभावित सीमा घटा सकता है
  • अगर पहले खेल में बंदूक के आगे के चार chamber खाली होने की पुष्टि हो जाए, तो विरोधी जान सकता है कि पासा केवल 3 या 4 रहा होगा; और अगर दूसरे खेल में साथी “Four” पुकारे, तो उसे यह जानकारी भी मिल जाती है कि गोली या तो पहले chamber में है या आख़िरी में
  • One-time pad नाम के अनुसार केवल एक बार ही सुरक्षित है; वही key दोबारा इस्तेमाल करने पर देखे गए ciphertext और पुरानी जानकारी मिलकर सुरक्षा तोड़ देते हैं

key length और आधुनिक encryption की व्यावहारिक सुरक्षा

  • इंटरनेट पर गोली की स्थिति के बजाय bit और byte भेजे जाते हैं, और एक bit का “yes/no” message एक coin toss से छिपाया जा सकता है
  • heads आने पर message को वैसा ही रहने देना और tails आने पर “yes” और “no” को उलट देना, coin result न जानने वाले पर्यवेक्षक से plaintext छिपाता है
  • लेकिन अगर उसी coin result से दो bit encrypt किए जाएँ, तो ciphertext चार संभावित plaintext को घटाकर दो तक सीमित कर देता है
    • “Yes yes” का मतलब है कि plaintext “yes yes” या “no no” था
    • “No no” का मतलब है कि plaintext “no no” या “yes yes” था
    • “Yes no” का मतलब है कि plaintext “yes no” या “no yes” था
    • “No yes” का मतलब है कि plaintext “no yes” या “yes no” था
  • सामान्य रूप से, जब n bit को एक ही coin toss से encrypt किया जाता है, तो संभावित plaintext space 2^n से घटकर 2 रह जाता है
  • शुद्ध information-theoretic अर्थ में n bit को सही तरह encrypt करने के लिए n-bit key चाहिए; इससे लंबा message हो तो उसका कुछ हिस्सा decrypt हो सकता है, और अगर पर्यवेक्षक पहले से n bit या उससे अधिक जानकारी जानता हो, तो आम तौर पर पूरा message decrypt किया जा सकता है
  • Cloudflare के पूरे traffic पर one-time pad लागू करने के लिए खगोलीय मात्रा में random number चाहिए होंगे, लेकिन आधुनिक सिस्टम one-time pad का उपयोग नहीं करते
  • authenticated encryption और stream cipher का सही उपयोग करने पर 256-bit key से बहुत सारा data व्यावहारिक रूप से सुरक्षित encrypt किया जा सकता है
  • ChaCha20 या AES-256-CTR जैसे उपयुक्त stream cipher का उपयोग करने पर कोई passive observer plaintext पाने के लिए लगभग 2^255 संयोजन आज़माने को मजबूर होगा
  • key जानने वाले के लिए stream पूरी तरह predictable होती है, लेकिन key न जानने वाले पृथ्वी-स्तरीय सभ्यता के पर्यवेक्षक के लिए यह पूरी तरह unpredictable “entropy” की तरह व्यवहार करती है
  • इस तरीके का औपचारिक नाम Cryptographically Secure Pseudo-Random Number Generator, संक्षेप में CSPRNG है

वास्तविक random number generation और fast key erasure

  • एक 256-bit master key से ज़रूरी random number निकालने के लिए master server या hardware security module में master key रखी जा सकती है, local key stream बनाई जा सकती है, और उसे पूरी कंपनी में सुरक्षित रूप से वितरित किया जा सकता है
  • हर server या CPU core 256-bit local key और counter से जितने चाहें उतने random byte बना सकता है
  • मुख्य समस्या यह है कि secure distribution बहुत कठिन है
  • अगर local key लीक हो जाए, तो उस machine द्वारा अतीत में encrypt किए गए और भविष्य में encrypt किए जाने वाले सभी message जोखिम में पड़ जाते हैं; master key लीक होने पर नुकसान बहुत बड़ा हो जाता है
  • fast key erasure key leakage की संभावना और leakage होने पर नुकसान कम करने की प्रक्रिया है
    • 512-byte buffer की शुरुआत में 32-byte random seed रखा जाता है
    • उसी seed से 512 byte generate करके buffer को overwrite किया जाता है
    • पहले 32 byte छोड़कर बाकी हिस्से को request के अनुसार output किया जाता है और फिर मिटा दिया जाता है
    • buffer पूरा इस्तेमाल होने पर फिर से generation चरण पर लौटा जाता है
  • “erasure” नाम इसलिए है क्योंकि generation चरण पुरानी key को मिटा देता है
  • अगर buffer लीक हो जाए, तो future message जोखिम में आ सकते हैं, लेकिन जो पुराने मान पहले ही output होकर मिटाए जा चुके हैं वे सुरक्षित रहते हैं
  • इससे भी अधिक महत्वपूर्ण सावधानी buffer की copy न बनाना है
    • उसी seed से दो stream नहीं बननी चाहिए
    • process fork करते समय stream को ठीक से दो भागों में बाँटना चाहिए
  • अगर एक ही stream की एक से अधिक copy बन जाए, तो वही random byte दोहर सकते हैं और यह घातक हो सकता है
  • इसी कारण user-space RNG की सिफारिश नहीं की जाती; kernel RNG आसान नहीं है, लेकिन audit करने के लिए घटकों की संख्या कम होती है

stream cipher का चयन और security margin

  • आधारभूत stream cipher का internal block size भी महत्वपूर्ण है
  • ChaCha20 का 512-bit block इतना बड़ा है कि चिंता की ज़रूरत नहीं, और AES का 128-bit block भी पर्याप्त बड़ा है
  • AES पर simple brute force से कहीं बेहतर सफलता संभावना वाले व्यावहारिक attack मौजूद हैं; AES-128 टूट सकता है, लेकिन AES-256 को सुरक्षित माना जाता है
  • इससे छोटे block size को इस उपयोग में टूटा हुआ मानना चाहिए
  • अनुशंसित विकल्प ChaCha20 या AES-256 हैं, और प्राथमिकता ChaCha20 को दी जाती है
  • आधुनिक stream cipher बहुत सुरक्षित हैं, और academic literature तथा कई सरकारों, खासकर अमेरिका, के उपयोग मामलों को देखें तो निकट भविष्य में इनके टूटने की संभावना बहुत कम है
  • चूँकि CSPRNG और encryption दोनों cryptography पर निर्भर हैं, इनमें से एक भी टूटे तो पूरा system टूट जाता है
  • अगर यह मानें कि AES-256 या ChaCha20 के निकट भविष्य में टूटने की सार्थक संभावना है, तो security margin बढ़ाने के विकल्प मौजूद हैं
    • अगर CSPRNG और encryption में एक ही cipher इस्तेमाल किया जाए, तो attacker के पास AES या ChaCha में से किसी एक को तोड़ लेने का विकल्प नहीं रहेगा; उसे एक खास cipher ही तोड़ना होगा
    • rounds बढ़ाने से केवल brute-force लागत ही नहीं बढ़ती, बल्कि brute force से बेहतर attack को रोकने में भी मदद मिलती है
    • AES-256 में 14 rounds और ChaCha20 में 20 rounds होते हैं
    • ChaCha7 पर exhaustive search से बेहतर attack हैं, लेकिन ChaCha8 पर अभी ऐसे attack नहीं हैं
    • ChaCha20 के 20 rounds इसलिए हैं कि अगर अचानक 12-round attack मिल जाए तो भी पर्याप्त margin बना रहे
  • कई system को parallel में चलाने वाली approach कुल complexity बहुत बढ़ा देती है, और यह complexity किसी एक component पर mathematical attack से भी अधिक घातक vulnerability पैदा कर सकती है

physical true RNG और initial seed

  • यह मानने में सावधानी चाहिए कि physical true RNG सैद्धांतिक रूप से टूट सकने वाले CSPRNG से ज़्यादा सुरक्षित होता है
  • security के लिए random output में अक्सर ऐसा कोई detectable bias नहीं होना चाहिए जिसे 2^64 sample का विश्लेषण करने पर भी पकड़ा जा सके; इसका मतलब अत्यंत uniform distribution है
  • physical process को उस स्तर तक tune करना कठिन है, इसलिए व्यवहार में noise source output को cryptographic hash से गुज़ारना पड़ता है
  • fast key erasure वाले stream cipher की तुलना में security gain छोटा होता है, जबकि ज़रूरत के अनुसार performance cost बड़ी हो सकती है
  • किसी भी मात्रा में random number बनाने के लिए शुरुआती कुछ byte का seed चाहिए ही होता है
  • किसी unpredictable source को पर्याप्त समय तक digitally record करके 256 bit से अधिक entropy प्राप्त की जाए, और उस record को SHA-256 या BLAKE2s जैसे 256-bit hash से hash किया जाए, तो master seed बनाया जा सकता है
  • संभावित random source में hardware random number generator, CPU jitter, किसी पेड़ की random photo, beam splitter, key press या mouse event, पासा आदि शामिल हैं
  • अलग-अलग साइटों के बीच random number distribution व्यावहारिक नहीं है; यह केवल जटिल ही नहीं, बल्कि compromise का कारण भी बन सकता है
  • random number केवल एक बार नहीं चाहिए होते; compromise का संदेह होने पर या महत्वपूर्ण security update के समय भी उनकी ज़रूरत पड़ती है
  • झंझट और जोखिम घटाने के लिए बाहर से लाने की बजाय आम तौर पर बेहतर है कि वही computer अपने उपयोग के लिए random seed खुद बनाए
  • सामान्य server में CPU jitter, peripheral interaction, और network event होते हैं, जो सामान्य उपयोग के लिए पर्याप्त हैं
  • अतिरिक्त सुरक्षा चाहिए तो हर server rack में कुछ hardware RNG dongle जोड़े जा सकते हैं, लेकिन इससे अधिक जटिल तरीका अनावश्यक complexity है

lava lamp wall क्यों अनावश्यक है

  • Cloudflare की lava lamp wall की ज़रूरत नहीं है, और अगर उसे local network के ज़रिए server से जोड़ा जाए तो केवल अतिरिक्त complexity और attack surface बढ़ता है
  • सही implementation होने पर जोखिम बहुत कम हो सकता है, फिर भी मिलने वाले लाभ की तुलना में जोखिम अधिक है
  • अगर Cloudflare सुरक्षा को गंभीरता से लेता है, तो उसे lava lamp का उपयोग बंद कर देना चाहिए और उन्हें केवल सजावट और marketing के लिए छोड़ देना चाहिए
  • server का खुद random number generate करना अधिक सरल और अधिक सुरक्षित है
  • यह भी संभव है कि Cloudflare पहले से ऐसा ही कर रहा हो

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 3 시간 전
Lobste.rs की राय

  • यह लेख गलतफ़हमी के साथ लिखा गया लगता है, और थोड़ा मज़ा किरकिरा करने वाला भी। आधुनिक random number generation कई स्वतंत्र entropy sources का उपयोग करती है, और कंप्यूटर के चलते रहने के दौरान इन्हें लगातार entropy pool में hash करके मिलाती रहती है
    ऐसा नहीं है कि कंप्यूटर के पास सिर्फ एक “random seed” होता है; रनटाइम के दौरान seed = hash(seed, new_data) जैसे तरीके से कई स्रोतों की entropy का उपयोग कर उसे लगातार फिर से seed किया जाता है। Lava lamp को फ़िल्म करने वाले कैमरा डेटा को जोड़ देने से सिस्टम की security कभी कम नहीं होती। Entropy pool में आने वाला डेटा पहले से मौजूद दूसरे डेटा के साथ hash हो जाता है। इसे इस तरह डिज़ाइन किया गया है कि अगर हमलावर को न पता हो ऐसी थोड़ी-सी जानकारी भी मौजूद हो तो यह सुरक्षित रहे, इसलिए अलग-अलग गुणवत्ता की randomness वाले बहुत-से डेटा को मिलाने पर भी security खराब नहीं होती
    Lava lamp सिस्टम की security को नुकसान नहीं पहुँचाते, और मेरी नज़र में यह सिस्टम का हिस्सा बनने वाली एक आनंददायक और कार्यात्मक कला-कृति है। यह random number की गुणवत्ता को भी बेहद मामूली स्तर पर बढ़ाता है, और randomness तथा entropy की अवधारणाओं को दृश्य रूप में दिखाता है

    • सही है, लेकिन kernel random number generators पहले से ही 30 साल से अधिक समय से तरह-तरह की hardware randomness का उपयोग करते आए हैं, और इन्हें कितना “लगातार” या “निरंतर” re-seed किया जाता है, इसे बढ़ा-चढ़ाकर नहीं कहना चाहिए
      Hardware से randomness लगातार इकट्ठी होती रहती है, लेकिन Linux random number generator को समय-समय पर ही re-seed किया जाता है। Boot के बाद पहले 1 मिनट तक हर कुछ सेकंड में, और उसके बाद यह लगभग प्रति मिनट एक बार तक धीमा हो जाता है

      https://zx2c4.com/projects/linux-rng-5.17-5.18/…

    • मुझे नहीं पता कि मैंने कहाँ यह आभास दिया कि मौजूदा सिस्टम ऐसे नहीं हैं, या ऐसा संकेत दिया। यहाँ, lava lamp वाले हिस्से को छोड़कर, मेरा उद्देश्य मौजूदा सिस्टम समझाना नहीं था, बल्कि यह रेखांकित करना था कि हमें वास्तव में कितनी कम चीज़ चाहिए — यानी 256 बिट काफ़ी हैं
      यह बात कि lava lamp को फ़िल्म करने वाले कैमरा डेटा को जोड़ने से security कम नहीं होती, मुझे attack surface की याद दिलाती है। इसका मतलब है एक embedded computer और उस computer तथा server के बीच network communication जोड़ना। मेरे लिए इस तरह जुड़ने वाला छोटा-सा जोखिम उस बेहूदा रूप से छोटे जोखिम से कहीं बड़ा लगता है, जहाँ सच में lava lamp की ज़रूरत पड़ जाए

  • अगर दार्शनिक भेद को अलग तरह से कहें, तो बात यह है: कितने संभावित परिणाम हैं, और परिणाम कितने अनुमानित हैं
    Cryptographic उद्देश्यों के लिए अनुमानित होने की सीमा को 2^-256 के स्तर पर स्थिर कर दिया गया है, लेकिन दिलचस्प बात यह है कि ऐसे आम processes भी हैं जिनमें संभावित परिणामों की संख्या इससे कहीं ज़्यादा होती है, और कभी-कभी आप चाहते हैं कि चाहे संभावना कितनी भी कम हो, हर संभव परिणाम उत्पन्न किया जा सके। ऐसी स्थिति में cryptographic randomness अपर्याप्त हो सकती है
    एक standard card deck में 52! तरह की shuffles होती हैं, जो लगभग 2^226 है, इसलिए cryptographically random seed से सभी shuffles बनाई जा सकती हैं। लेकिन अगर आप Uno खेल रहे हों या कई decks को साथ में shuffle कर रहे हों, तो 256-bit random number generator के पास सभी shuffles बनाने लायक state नहीं होती। अगर सिस्टम की सारी user-space randomness kernel से आती हो, और kernel सारी hardware randomness को 256-bit CSPRNG में डाल देता हो, तो Las Vegas में cards shuffle करने के लिए यह काफ़ी न हो :-)
    लेख में जो छूटा है वह re-seeding है, जो इसलिए रोचक विषय है क्योंकि यह fast key erasure के साथ कैसे interact करता है, और शुरुआती seed हासिल करना कितना कठिन हो सकता है, यह दिखाता है। लेख यह संकेत देता है मानो Linux सिर्फ CPU jitter का उपयोग करता है, लेकिन यह बहुत अधिक सरलीकरण है। Linux कई randomness sources का उपयोग करता है, और jitter dance सिर्फ अंतिम उपाय के रूप में इस्तेमाल होता है

    • ऐसा नहीं है। वास्तविक दुनिया में कोई भी कभी भी ऐसा नहीं करेगा
      वास्तविक दुनिया में 2^128 samples तक भी पहुँचना असंभव है। सच कहें तो उससे बहुत कम, और इसी वजह से AES-128 भी आज कई उपयोगों के लिए पर्याप्त सुरक्षित है। जब संभावित परिणामों की संख्या 2^256 से बड़ी हो, तो “सभी संभावित परिणामों को चलाना” पूरी तरह असंभव है। इसे भूल जाना बेहतर है। ऐसी कोई चीज़ व्यवहार में होती ही नहीं
      Blackjack में, जब आप एक deck नहीं बल्कि 6 decks का उपयोग करते हैं, तब भी आप वास्तव में ऐसा shuffling process नहीं चाहते जो हर संभव shuffle पर probability को बिल्कुल समान रूप से बाँट दे। आपको बस ऐसा distribution चाहिए जो इतना अच्छा हो कि जितना भी अधिक sampling कर लें, अंतर पहचान में न आए। भले ही shuffles की संख्या 2^256, या यहाँ तक कि 2^128 तक सीमित हो, आपको फ़र्क महसूस नहीं होगा
      लेख में re-seeding को छोड़ना जानबूझकर किया गया था। इसकी ज़रूरत सिर्फ कुछ खास मौकों पर होती है, जैसे suspected compromise और कुछ security updates। Reboot के समय भी, अगर यह random number generator की state को non-volatile memory में बनाए रखने से अधिक सरल या सुरक्षित हो। इसलिए “re-seed” कहने की बजाय मैं इसे एक नई initial seed के साथ फिर से शुरू करना कहना पसंद करूँगा
      सामान्य संचालन के दौरान re-seeding की बिल्कुल ज़रूरत नहीं होती। इसे लागू करने से सिर्फ complexity बढ़ेगी
      Linux सिर्फ CPU jitter का उपयोग करता है, यह संकेत मुझे जाँचना चाहिए था। मेरी समझ के अनुसार boot के समय वही एकमात्र चीज़ थी। खासकर user input और network input आने से पहले। क्या आपको कोई और source पता है? Hardware random number generator support तो शायद पहले से होगा
    • संभावना और अनुमानित होने के भेद को देखकर मुझे Shamir, Rivest, Adleman का paper याद आया। इसमें साबित किया गया है कि दो लोगों का फ़ोन पर virtual card deck के ज़रिए सुरक्षित poker खेलना गणितीय रूप से असंभव है
      नहीं किया जा सकता। लेकिन उस बात को एक तरफ़ रखकर, इसे सुरक्षित तरीके से करने का उपाय यह है…
    • दिलचस्प। अगर मुझे सही याद है, तो असली random source को पढ़ना एक blocking operation होता है, इसलिए अगर kernel में पर्याप्त random bytes न हों, तो पर्याप्त randomness पढ़ पाने तक काफ़ी देर लग सकती है
      मेरा अनुमान है कि random number generation hardware cards शायद सिर्फ bit density के लिए नहीं, बल्कि प्रति इकाई समय अधिक bits देने वाले parallel randomness sources पाने के लिए भी मौजूद रहे होंगे

  • अलग-अलग दावों में ऐसा बहुत कम है जिससे मैं ज़ोरदार असहमत हूँ, लेकिन समग्र तर्क मुझे धुंधला लगा। लेख पहले यह स्थापित करता है कि “आधुनिक cryptography को लोगों की सोच से कहीं कम वास्तविक randomness चाहिए”, और फिर निष्कर्ष देता है कि “इसलिए lava lamp attack surface बढ़ाते हैं, तो वे बदतर हैं”
    दोनों दावे सही हो सकते हैं, लेकिन निष्कर्ष तक पहुँचने की कड़ी कुछ खुरदरी लगती है

    • सच कहूँ तो narrative structure बहुत संतोषजनक नहीं है। फिर भी निष्कर्ष का आधा हिस्सा तो मैंने शीर्षक में पहले ही लिख दिया था

  • LavaRand 20 साल से भी पहले यह काम कर रहा था। उस समय यह प्यारा लगता था, लेकिन उस दौर के camera sensors बहुत छोटे थे, और lens वगैरह की पूर्वानुमेय विशेषताओं के कारण वे entropy source के रूप में अच्छे नहीं थे
    मुझे lava lamps पसंद हैं, लेकिन सैकड़ों की दीवार जितनी बिजली खपत करती है, वह एक खिलौना-जैसी व्यवस्था के लिए काफ़ी ज़्यादा है

  • यह self-promotion के काफ़ी करीब है। लगभग कभी links साझा नहीं करता, और जब करता है तो अपने ही links डालता है। हाल की 5 में से 5 posts उसी की सामग्री की ओर इशारा करती हैं

    • यह इस बात पर निर्भर करता है कि “stories and comments” की व्याख्या कैसे की जाए
      “लेखक का community में भाग लेना अच्छा है, लेकिन इसे product announcement या अपने काम की ओर traffic मोड़ने के लिए write-only tool की तरह दुरुपयोग नहीं करना चाहिए। एक सामान्य नियम के तौर पर self-promotion आपकी अपनी stories और comments के एक-चौथाई से कम होना चाहिए।”
      अगर 15 posts पर 1399 comments हैं, तो वह स्पष्ट रूप से community में भाग ले रहा है। बशर्ते वह अपनी हर post पर खुद 90 से ज़्यादा comments न कर रहा हो

  • Cloudflare ने lava lamp से मिली entropy, University of Chile ने भूकंप डेटा, मेरी याद सही हो तो EPFL ने radioactive decay के माप, और कई अन्य प्रतिभागियों ने drand network की शुरुआती key generation ceremony में तरह-तरह का data योगदान दिया
    क्या CSPRNG का उपयोग किया जा सकता था? बिल्कुल। लेकिन फिर मज़ा कहाँ रहता?

    • मज़ा ठीक है। Lava lamps सुंदर हैं, और उनकी wave wall सचमुच बहुत खूबसूरत है। बात तब सीमा पार करती है जब इसे इस तरह पेश किया जाए मानो यह वास्तव में security में मदद कर रही हो