Ipfs: अनुमतियां

आगे की जांच पर, मुझे लगता है कि केवल एक चीज जो गायब है वह है बूँद का स्वामित्व (संभवतः कोई नहीं) और मालिक द्वारा नियंत्रित सूची (या कई) के आधार पर अनुमतियाँ पढ़ें (यदि कोई नहीं)। इसे अंतर्निहित fs को संशोधित किए बिना IPFS के शीर्ष पर बनाया जा सकता है।

बेहतर होगा कि आप इसके बजाय क्षमताओं का उपयोग करें। अनुभवहीन उदाहरण: फ़ाइल को कुछ गुप्त के साथ एन्क्रिप्ट करें, और उन लोगों के साथ रहस्य साझा करें जिनके पास "पढ़ने की अनुमति" है।

बिल्कुल। टोपियां। ई-अधिकार और ताहो-एलएएफएस देखें

-
मेलबॉक्स से भेजा गया

शुक्र, 4 सितंबर 2015 को शाम 4:46 बजे, मौराद डी क्लर्क नोटिफिकेशन @github.com
लिखा था:

बेहतर होगा कि आप इसके बजाय क्षमताओं का उपयोग करें। अनुभवहीन उदाहरण: फ़ाइल को कुछ गुप्त के साथ एन्क्रिप्ट करें, और उन लोगों के साथ रहस्य साझा करें जिनके पास "पढ़ने की अनुमति" है।

इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें:
https://github.com/ipfs/ipfs/issues/86#issuecomment -137755902

अनुमति को प्रबंधित करने के लिए एन्क्रिप्शन एक बहुत बुरा विचार है। यह आशावादी परिदृश्यों में अच्छा काम करता है लेकिन वास्तविकता में खुद को बहुत अच्छी तरह से पकड़ नहीं पाता है।

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

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

अंत में, जब सुरक्षा और गोपनीयता की बात आती है तो फ़ाइल को नेटवर्क छोड़ने से रोकने से बेहतर कुछ नहीं है।

फ़ाइल अनुमतियों के बजाय, मुझे लगता है कि इसे नोड स्तर पर करना अधिक सार्थक होगा। मूल रूप से, एक नोड श्वेतसूची/ब्लैकलिस्ट प्रतिमान के आधार पर अन्य नोड्स से कनेक्शन को अस्वीकार करने में सक्षम होना चाहिए। यह लोगों को एक निजी आईपीएफएस नेटवर्क बनाने देगा, जो कि निजी बिट टोरेंट ट्रैकर्स की तरह है, संवेदनशील डेटा साझा करने के लिए दुर्भावनापूर्ण नोड में लीक होने से बचने के लिए।

हो सकता है कि हम ज्ञात दुर्भावनापूर्ण नोड्स को स्वचालित रूप से अवरुद्ध करने के लिए आईपीएफएस पर संग्रहीत नोड्स की विश्व स्तर पर वितरित ब्लैकलिस्ट पर भी विचार कर सकें। हालांकि, मुझे नहीं पता कि यह कितना उपयोगी होगा क्योंकि एक नोड पहचान को एक नई कुंजी जोड़ी के माध्यम से फिर से उत्पन्न किया जा सकता है।

मैं यह भी मानता हूं कि एन्क्रिप्शन ऐसा करने का सबसे सीधा तरीका है।
एन्क्रिप्शन योजनाओं को हैक किया जा सकता है, लेकिन नोड्स को भी। उपयोगकर्ताओं को बस जरूरत है
अभिगम नियंत्रण प्रदान करने का प्रयास करते समय इन संभावनाओं से अवगत होना
बूँद करने के लिए।
9 सितंबर 2015 को शाम 6:48 बजे, "एटिने महू" नोटिफिकेशन @github.com ने लिखा:

अनुमति को प्रबंधित करने के लिए एन्क्रिप्शन एक बहुत बुरा विचार है। यह अच्छी तरह से काम करता है
आशावादी परिदृश्य लेकिन वास्तविकता में खुद को बहुत अच्छी तरह से पकड़ नहीं पाते हैं।

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

वास्तविक दुनिया में, यदि फ़ाइल कुछ समय पहले बनाई गई है, तो यह है
संभव है कि तब से एन्क्रिप्शन एल्गोरिथम में कोई दोष पाया गया हो।
या, यह संभव है कि नया विशेष डिक्रिप्शन हार्डवेयर व्यापक रूप से बन जाए
उपलब्ध। यह डिक्रिप्शन की जटिलता को काफी कम कर देगा
प्रक्रिया। क्योंकि कोई भी वास्तव में फ़ाइल का स्वामी नहीं है, इसलिए उसे खींचने का कोई तरीका नहीं है
मौजूदा फ़ाइल और इसे एक नए संस्करण के साथ बदलें जो कि एन्क्रिप्टेड है a
नया और सुरक्षित एल्गोरिदम। भले ही आप ऐसा कुछ कर सकें, क्या
आपको बताता है कि दुर्भावनापूर्ण नोड फ़ाइल के पिछले संस्करण को नहीं रखेगा
वैसे भी।

अंत में, फ़ाइल को नेटवर्क छोड़ने से रोकने से बेहतर कुछ नहीं है
जब सुरक्षा और गोपनीयता की बात आती है।

फ़ाइल अनुमतियों के बजाय, मुझे लगता है कि ऐसा करना अधिक सार्थक होगा
एक नोड स्तर पर। मूल रूप से, एक नोड कनेक्शन को अस्वीकार करने में सक्षम होना चाहिए
श्वेतसूची/ब्लैकलिस्ट प्रतिमान के आधार पर अन्य नोड्स से। यह जाने देगा
लोग एक निजी आईपीएफएस नेटवर्क बनाते हैं, थोड़ा सा निजी बिट टोरेंट की तरह
ट्रैकर्स, संवेदनशील डेटा साझा करने के लिए दुर्भावनापूर्ण को लीक होने से बचाते हैं
नोड.

हो सकता है कि हम नोड्स की विश्व स्तर पर वितरित ब्लैकलिस्ट पर भी विचार कर सकें,
ज्ञात दुर्भावनापूर्ण नोड्स को स्वचालित रूप से ब्लॉक करने के लिए, IPFS पर ही संग्रहीत।
हालांकि, मुझे नहीं पता कि नोड पहचान पर विचार करना कितना उपयोगी होगा
बस एक नई कुंजी जोड़ी के माध्यम से पुन: उत्पन्न किया जा सकता है।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/ipfs/ipfs/issues/86#issuecomment -138988589।

@ekg अंतर यह है कि यदि किसी नोड को कैसे सुरक्षित किया जाता है, या स्वयं श्वेतसूची प्रणाली में कोई दोष है, तो इसे अपडेट किया जा सकता है क्योंकि आपके नेटवर्क में सभी प्रभावित नोड्स के "आप नियंत्रण में हैं"। यदि आप किसी नोड पर भरोसा करना चुनते हैं, तो यह सुनिश्चित करना आपके ऊपर है कि यह सुरक्षित है। यदि कोई दोष दिखाई देता है, तो इसका मतलब यह नहीं है कि आपने डेटा लीक कर दिया है, बस आपको इसे जल्द से जल्द ठीक करना चाहिए। जब वितरित फ़ाइल सिस्टम में एन्क्रिप्शन की बात आती है तो आप ऐसा नहीं कर सकते। यदि कोई फ़ाइल टूटी हुई एन्क्रिप्शन का उपयोग करती है, तो आपके पास वह दूसरा मौका नहीं है।

@kawazoe कृपया क्षमता मॉडल में पढ़ें। प्रत्येक अनुमति योजना को एक क्षमता प्रणाली में दर्शाया जा सकता है, इसलिए यह एक _सख्ती से बेहतर_ प्रणाली है। कागजात लाजिमी है।

एक नोड श्वेतसूची/ब्लैकलिस्ट प्रतिमान के आधार पर अन्य नोड्स से कनेक्शन को अस्वीकार करने में सक्षम होना चाहिए। यह लोगों को एक निजी आईपीएफएस नेटवर्क बनाने देगा, जो कि निजी बिट टोरेंट ट्रैकर्स की तरह है, संवेदनशील डेटा साझा करने के लिए दुर्भावनापूर्ण नोड में लीक होने से बचने के लिए।

यह पहले से ही योजनाबद्ध है, लेकिन ऑर्थोगोनल है।

@jbenet मैं यह नहीं कह रहा हूं कि क्षमताएं खराब हैं। यह बहुत अच्छा है कि आप इस मॉडल का उपयोग करने की योजना बना रहे हैं। मैं जो कह रहा हूं वह यह है कि एक एक्सेस क्षमता और एक पढ़ने की क्षमता के बीच एक विशिष्ट अंतर है (इससे कोई फर्क नहीं पड़ता कि यह किस स्तर पर या इसे कैसे कार्यान्वित किया जाता है) और केवल डेटा को एन्क्रिप्ट करना दोनों को अलग करने के लिए पर्याप्त नहीं है।

एक नोड होना जो नियंत्रित करता है कि कौन से नोड्स को एक निश्चित फ़ाइल को पुनर्प्राप्त करने की अनुमति है, एक चीज होनी चाहिए। कुछ परिदृश्यों में फ़ाइलों को एन्क्रिप्ट करना अच्छा नहीं है। कुछ उदाहरण:
कुछ मीडिया सेवा लें, जहां लोगों को सामग्री तक पहुंचने के लिए भुगतान करना पड़े। बैंडविड्थ पर बचत करने के लिए, आईपीएफएस का उपयोग करना समझ में आता है, अगर वे यह सुनिश्चित कर सकते हैं कि केवल भुगतान करने वाले ही फाइलों तक पहुंच सकते हैं, कम से कम अपने नोड्स और ईमानदार उपयोगकर्ताओं के नोड्स के माध्यम से। यदि फ़ाइलें केवल एन्क्रिप्शन द्वारा संरक्षित थीं, तो इसके लिए केवल एक उपयोगकर्ता की आवश्यकता होगी जो प्रति माध्यम कुंजी निकालता है, और समुद्री डाकू आईपीएफएस के माध्यम से सामग्री चुरा सकते हैं। एसिंक्रोनस एन्क्रिप्शन के बिना, आप यह भी नहीं जान सकते थे कि किन उपयोगकर्ताओं ने कुंजी वितरित की है, और एसिंक्रोनस एन्क्रिप्शन के साथ, आपको आईपीएफएस के लाभ नहीं मिलते हैं। कृपया इस पर पुनर्विचार करें।

इसे लागू करने का एक तरीका यह होगा कि फ़ाइल के लिए कहा जाने वाला नोड कुछ प्राधिकरण से पूछेगा कि क्या फ़ाइल तक पहुंचने का प्रयास करने वाले नोड को ऐसा करने की अनुमति दी गई थी, और उसके आधार पर कार्य करें। ऐसा करना बहुत कठिन नहीं होना चाहिए, और निश्चित रूप से उपयोगकर्ता होंगे।

@jcgruenhage आप नेटवर्क के प्रत्येक उपयोगकर्ता को एक ही निजी नेटवर्क पर रख सकते हैं। (निजी नेटवर्क पर अधिक जानकारी के लिए https://github.com/ipfs/go-ipfs/issues/3397#issuecomment-284341649 देखें)

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

निजी नेटवर्क सुविधा दिलचस्प लगती है, लेकिन यह लोगों को इस सामग्री तक पहुँचने के लिए एक पूरी तरह से अलग नोड के लिए मजबूर करेगी, और मुझे संदेह है कि अधिकांश लोग यही चाहते हैं। इसके अलावा, वहां हमारे पास फिर से एक ही कुंजी है जिसे समझौता करने की आवश्यकता होगी, बजाय एक केंद्रीय प्राधिकरण के पास जो इस पर नियंत्रण रखता है कि फाइल कौन प्राप्त करता है।

इस बारे में कि क्या नोड को फ़ाइल साझा करनी चाहिए यदि वे इसे कहीं और से प्राप्त करते हैं, तो उन्हें यह भी कैसे पता होना चाहिए कि फ़ाइल की पहुंच प्रतिबंधित है? मुझे लगता है कि इसे साझा करना ठीक है, क्योंकि जिस चीज को मैं सुनिश्चित करने की कोशिश कर रहा हूं वह केवल यह है कि अगर कोई फ़ाइल को "चोरी" करता है, तो सर्वर नोड्स जिन्होंने फाइलों को पिन किया है, और ईमानदार उपयोगकर्ताओं के नोड्स उनके डाउनलोड नहीं करते हैं सुपर फास्ट, क्योंकि वे इसे उन सभी नोड्स से भी डाउनलोड कर सकते हैं, लेकिन केवल उन लोगों से जो इतने ईमानदार उपयोगकर्ता नहीं हैं।

@jcgruenhage मैं एक निजी नेटवर्क की आवश्यकता की असुविधा के बारे में सहमत हूं।

साथ ही, यह भी स्पष्ट नहीं है कि निजी नेटवर्क कितनी मदद करता है क्योंकि डेटा को डिक्रिप्ट करने पर एक बेईमान उपयोगकर्ता तुरंत इस डेटा को सार्वजनिक नेटवर्क पर अपलोड कर सकता है। अगर कुछ इसे रोकता है तो कृपया मुझे सुधारें।

यदि निजी नेटवर्क में अधिकतम दो नोड होते हैं तो ईमानदार नोड को पता चल जाएगा कि दूसरा नोड बेईमानी से डेटा लीक कर रहा है। निजी नेटवर्क में दो से अधिक नोड्स की अनुमति दें, और रिसाव नियतत्ववाद खो जाता है।

दो नोड निजी नेटवर्क में भी, ईमानदार नोड को तुरंत पता नहीं चलेगा कि डेटा लीक हो रहा है। समय बीत जाएगा, और उस समय तक डेटा आकाशगंगा में आधा हो सकता है।

फ़ाइल डिक्रिप्शन के दौरान एन्क्रिप्टेड नोड आईडी / ट्रेसर आईडी जोड़ने का एक संभावित समाधान है। इस प्रकार प्रत्येक उपयोगकर्ता को उनके लिए अद्वितीय ट्रेसर/नोड आईडी वाली प्रत्येक फ़ाइल की थोड़ी संशोधित प्रति प्राप्त होती है। डिक्रिप्टेड फाइलें हमेशा मूल से अलग होंगी, लेकिन मूल अपरिवर्तनीय और सत्यापन योग्य रहेगी।

निजी नेटवर्क से संबंधित प्रहरी नोड्स इन ट्रेसर मूल्यों के लिए सार्वजनिक नेटवर्क की निगरानी कर सकते हैं। इस तरह, रिसाव की उत्पत्ति का समय पर पता लगाना संभव होगा।

यह एक निजी नेटवर्क पर एक नोड को दूसरे निजी नेटवर्क में डेटा लीक करने से नहीं रोकेगा।

आप उपयोगकर्ताओं को फ़ाइलों को साझा करने से नहीं रोक सकते हैं, लेकिन आपको इसके लिए अपने बुनियादी ढांचे का उपयोग करने से रोकने में सक्षम होना चाहिए, लेकिन वर्तमान में कोई वितरित फ़ाइल वितरण प्रणाली नहीं है जो अभी तक ऐसा करती है।

@jcgruenhage एचआरएम ... यह एक दिलचस्प उपयोगकेस है। क्या प्रत्येक भाग लेंगे
नोड सर्वर से अनुरोध किए जा रहे प्रत्येक ब्लॉक के बारे में पूछता है? या होगा लेखक
सर्वर अनुमत साथियों की एक बड़ी सूची भेजता है और वे कौन सी सामग्री हैं
उपयोग करने की अनुमति है?

शुक्र, 2 जून 2017, 09:19 जनवरी क्रिश्चियन ग्रुन्हेज नोटिफिकेशन @github.com . पर
लिखा था:

आप उपयोगकर्ताओं को फ़ाइलें साझा करने से नहीं रोक सकते, लेकिन आपको सक्षम होना चाहिए
उन्हें इसके लिए अपने बुनियादी ढांचे का उपयोग करने से रोकें, लेकिन वर्तमान में ऐसा नहीं है
वितरित फ़ाइल वितरण प्रणाली जो अभी तक ऐसा करती है।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने टिप्पणी की थी।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/ipfs/ipfs/issues/86#issuecomment-305836646 , या म्यूट करें
सूत्र
https://github.com/notifications/unsubscribe-auth/ABL4HGtd8flt7agdikQeIrSk59vnTZzvks5sADYlgaJpZM4F3vN7
.

निजी नेटवर्क सुविधा आपके पीनेट साथियों के पूर्ण विश्वास की अवधारणा पर बनाई गई थी।

अगला चरण क्षमता प्रणाली हो सकता है जहां आप कुछ नोड्स को कुछ फाइलों तक पहुंच की अनुमति दे सकते हैं। उस स्कीमा में दुर्भावनापूर्ण अभिनेता केवल उसी डेटा को लीक करने में सक्षम होगा, जिसके लिए उसके पास क्षमता है, यह देखते हुए कि दी गई फ़ाइल के लिए क्षमता वाले अन्य नोड्स अच्छी तरह से व्यवहार कर रहे हैं।

@nueverest के रूप में @jcgruenhage ने कहा, एक बार उपयोगकर्ता के पास फ़ाइल तक पहुंच हो जाने के बाद और इसे डिक्रिप्ट कर सकता है तो वह इसे यूएसबी स्टिक पर कॉपी कर सकता है और इसे कहीं और प्रकाशित कर सकता है।

मेरे लिए स्वामित्व अधिक महत्वपूर्ण है --- मैं यह सुनिश्चित करना चाहता हूं कि फ़ाइल किसी ऐसे व्यक्ति द्वारा संशोधित की गई थी जिस पर मुझे भरोसा है। ऐसा करने का एक तरीका फ़ाइल को एन्क्रिप्ट करना है और फ़ाइल नाम के एक भाग के रूप में डिक्रिप्शन कुंजी का उपयोग करना है --- इसलिए एक बार हैश-सम की गणना डिक्रिप्टेड फ़ाइल के लिए की जाती है, मुझे पता चलेगा कि एन्क्रिप्शन कुंजी को जानने वाला केवल वही कर सकता है। .

शायद यह सबसे अच्छा तरीका नहीं है, लेकिन क्या इसे कहीं लागू किया गया है?

/ipfs पथ द्वारा नामित फ़ाइलें (जैसे, /ipfs/QmSVyMxF5W5NFTJxKWhhdVjqnhhFmsqjFgSrbPovp5bzwF) अपरिवर्तनीय हैं इसलिए यह कोई समस्या नहीं होनी चाहिए। /ipns/... पथ द्वारा नामित फ़ाइलें परिवर्तनशील हैं लेकिन लेखक (IPNS नाम के स्वामी) द्वारा हस्ताक्षरित हैं।

हालांकि, यदि आप बैंड से /ipfs/... पथ प्राप्त कर रहे हैं और लेखकत्व निर्धारित करना चाहते हैं, तो आपको संभवतः डेटा पर हस्ताक्षर करने की आवश्यकता होगी (उदाहरण के लिए, gnupg के साथ किया जा सकता है)।

नोट: हम अंततः SUNDR की तरह एक परिवर्तनशील फाइल सिस्टम का निर्माण करेंगे। वह फाइल सिस्टम संभवतः लेखक की जानकारी ले जाएगा। हम संभावित रूप से भविष्य में मनमाने मेटाडेटा की भी अनुमति देंगे (जो सिद्धांत रूप में, लेखक की जानकारी ले जा सकता है)।

@risen @jbenet क्या आप वर्णन कर सकते हैं (या विवरण के लिए लिंक) किसी अधिकृत अनुरोधकर्ता को छोड़कर किसी IPFS नोड पर अनुमति प्राप्त फ़ाइलों को उस नोड को छोड़ने से रोकने के लिए क्षमता मॉडल का उपयोग कैसे किया जा सकता है? क्या IPFS में कोई स्पष्ट क्षमता मॉडल विशेषता है? मैंने इस पर दस्तावेज़ीकरण के लिए चारों ओर खोज की है लेकिन कुछ भी स्पष्ट नहीं मिला है।

हाय @vdods - हम संदर्भ उद्देश्यों के लिए इस रेपो में मुद्दों को खुला छोड़ रहे हैं, लेकिन अनुरोध करते हैं कि फॉलोअप चर्चा https://discuss.ipfs.io/ (जिस पर सक्रिय रूप से निगरानी की जाती है) में हो। कृपया वहां पोस्ट करें - धन्यवाद!