शून्य-ज्ञान कोड होस्टिंग? [बन्द है]


28

ऑनलाइन सेवा प्रदाताओं द्वारा संग्रहीत डेटा की व्यापक सरकारी निगरानी के बारे में हाल के खुलासे के प्रकाश में, शून्य-ज्ञान सेवाएं अब सभी क्रोध हैं।

एक शून्य-ज्ञान सेवा वह है जहां सभी डेटा को एक कुंजी के साथ एन्क्रिप्ट किया जाता है जो सर्वर पर संग्रहीत नहीं होता है। एन्क्रिप्शन और डिक्रिप्शन पूरी तरह से क्लाइंट साइड पर होता है, और सर्वर कभी भी सादे डेटा या कुंजी को नहीं देखता है। नतीजतन, सेवा प्रदाता किसी तीसरे पक्ष को डेटा को डिक्रिप्ट और प्रदान करने में असमर्थ है, भले ही वह चाहे।

एक उदाहरण देने के लिए: स्पाइडरऑक को ड्रॉपबॉक्स के शून्य-ज्ञान संस्करण के रूप में देखा जा सकता है।

प्रोग्रामर के रूप में, हम बहुत अधिक भरोसा करते हैं, और हमारे कुछ संवेदनशील डेटा - हमारे कोड - ऑनलाइन सेवा प्रदाताओं के एक विशेष वर्ग पर भरोसा करते हैं: कोड होस्टिंग प्रदाता (जैसे बिटबकेट, असेंबला, और इसी तरह)। मैं निश्चित रूप से यहां निजी रिपोजिटरी के बारे में बात कर रहा हूं - शून्य-ज्ञान की अवधारणा सार्वजनिक रिपॉजिटरी के लिए कोई मतलब नहीं है।

मेरे प्रश्न हैं:

  1. क्या शून्य-ज्ञान कोड होस्टिंग सेवा बनाने के लिए कोई तकनीकी बाधाएं हैं? उदाहरण के लिए, क्या SVN, Mercurial, या Git जैसे लोकप्रिय संस्करण नियंत्रण प्रणालियों द्वारा उपयोग किए जाने वाले नेटवर्क प्रोटोकॉल के बारे में कुछ ऐसा है जो एक ऐसी योजना को लागू करने में मुश्किल (या असंभव) होगा जहां क्लाइंट और सर्वर के बीच संचार किया जा रहा डेटा के साथ एन्क्रिप्ट किया गया है एक सर्वर को पता नहीं है?

  2. क्या आज कोई शून्य-ज्ञान कोड होस्टिंग सेवाएँ मौजूद हैं?


1
होमोमोर्फिक एन्क्रिप्शन के बिना , मैं यह नहीं देखता कि शून्य-ज्ञान कोड होस्टिंग साइट ड्रॉप-बॉक्स के शून्य-ज्ञान संस्करण पर किसी भी प्रकार का लाभ कैसे प्रदान कर सकती है। मुझे विश्वास नहीं है कि कोई भी अभी तक इस तरह की योजना के साथ आया है जो दोनों सुरक्षित है (यानी, पर्याप्त सुरक्षित है कि विशेषज्ञ इस पर भरोसा करते हैं) और तेजी से उपयोग करने योग्य हो।
ब्रायन

2
@AndresF। मैं केवल स्पाइडरओक मान सकता हूं कि क्लाइंट पर डिफरेंशियल-डिफरेंस जेनरेट होता है, सर्वर स्टोर एन्क्रिप्टेड डिफरेंशियल होता है, और फिर डिफरेंट-बेस एप्लिकेशन क्लाइंट पर तब होता है जब डिफरेंट और बेस एनक्रिप्टेड होता है। मैं सहमत हूं कि उनकी भाषा बहुत अस्पष्ट है।
अप्सिलर्स

2
@apsillers: या आप जानबूझकर ऐसी सामग्री को किसी फ़ाइल में भर सकते हैं और इसका उपयोग फ़ाइल की पहचान करने के लिए कर सकते हैं (उदाहरण के लिए, यदि कोई चोरी को छिपाने के लिए एन्क्रिप्शन का उपयोग करने की कोशिश कर रहा है)।
22

4
यह ऐसा कुछ नहीं है जिसका मुझे कोई अनुभव है, लेकिन मैं एक संभव तकनीकी अवरोध की कल्पना कर सकता हूं जिसमें एक शून्य-ज्ञान कोड होस्टिंग सेवा है: क्या सभी उपयोगकर्ताओं को ठीक उसी कुंजी को जानने / उपयोग करने की आवश्यकता नहीं होगी? और अगर ऐसा है, तो प्रमाणीकरण तंत्र क्या होगा जो उपयोगकर्ता के विभिन्न स्तरों को सुनिश्चित करता है?
सीबी

2
@gnat: मैं एक सिफारिश के लिए नहीं कह रहा हूँ। मैं केवल यह पूछ रहा हूं कि मेरे द्वारा बताए गए सॉर्ट की कोई सेवा मौजूद है या नहीं। इस तरह की सेवा के अस्तित्व से इस बात के प्रमाण मिलेंगे कि तकनीकी अवरोध जो मैं इस बारे में पहले पूछ रहा था, वे अति-योग्य हैं।
HC4 -

जवाबों:


3

आप प्रत्येक पंक्ति को अलग से एन्क्रिप्ट कर सकते हैं। यदि आप अपनी फ़ाइल के नाम और अनुमानित रेखा की लंबाई और रेखाओं की संख्या को बदलना चाहते हैं, जिस पर रेखाएँ बदलती हैं, तो आप इस तरह का उपयोग कर सकते हैं:

https://github.com/ysangkok/line-encryptor

जैसा कि प्रत्येक पंक्ति को अलग से (लेकिन उसी कुंजी के साथ) एन्क्रिप्ट किया गया है, अपलोड किए गए परिवर्तन (जैसे आमतौर पर) केवल प्रासंगिक लाइनों को शामिल करेंगे।

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

ऊपर एन्क्रिप्टेड लाइन एससीएम अज्ञेयवादी है, लेकिन यूनिफ़ाइड फ़र्क फ़ाइलों (प्लेनटेक्स्ट) को पढ़ सकती है और परिवर्तनों को एन्क्रिप्ट करके उन्हें सिफरटेक्स्ट में लागू कर सकती है। यह किसी भी SCM पर प्रयोग करने योग्य बनाता है जो आपको एक एकीकृत अंतर (जैसे गिट) उत्पन्न करेगा।


क्या आप इसके लिए git की स्मज-क्लीन का उपयोग नहीं कर सकते हैं ?
19

@ शविक: आप कर सकते हैं, लेकिन इस तरह, मैं यह नहीं देखता कि आप पूरी फाइल को फिर से एन्क्रिप्ट करने से कैसे बचेंगे। लेकिन निश्चित रूप से, यह कोड के लिए ज्यादा मायने नहीं रखेगा क्योंकि फ़ाइल का आकार छोटा है। लेकिन फिर "लाइन एनक्रिप्ट" की कोई आवश्यकता नहीं है, आप बस किसी भी एन्क्रिप्शन टूल का उपयोग कर सकते हैं।
Janus Troelsen

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

@ मिचेल्ट: नहीं, IV के कारण। इसे स्वयं आज़माएं :) लिंक किए गए कार्यान्वयन का उपयोग करके, लाइनों को एन्क्रिप्ट करने के लिए <IV>,<ciphertext>
Janus Troelsen

1
@ शविक: लाइनें व्यक्तिगत रूप से एन्क्रिप्ट की जाती हैं। यदि आप एक लाइन बदलते हैं, तो पूरी लाइन फिर से एन्क्रिप्ट हो जाएगी, लेकिन एक नए IV (हमेशा की तरह) के साथ। लेकिन बाकी फाइल को छुआ नहीं जाएगा! एन्क्रिप्शन नियतात्मक है, लेकिन IV के इनपुट भी हैं, और वे छद्म यादृच्छिक रूप से चुने गए हैं।
Janus Troelsen

1

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

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

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

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


पुन: "इसका मतलब होगा कि आपके पास विभिन्न कोड दृश्य सुविधाओं, कोई सर्वर-साइड रिपॉजिटरी ब्राउज़र या लॉग व्यूअर के साथ एक वेब साइट नहीं हो सकती है। कोई भी कोड अलग नहीं है, कोई ऑनलाइन कोड समीक्षा उपकरण नहीं है।" - आपके पास अभी भी ये हो सकता है यदि एप्लिकेशन लॉजिक क्लाइंट-साइड जेएस में था और इसने आपको अपना पासवर्ड / कुंजी दर्ज किया (लेकिन इसे सर्वर पर नहीं भेजा गया), सही?
HC4 - मोनिका

हाँ, यह .... जब तक यह जानता था कि यह नेटवर्क पर एन्क्रिप्टेड डेटा प्राप्त कर रहा था। यह सर्वर का सिर्फ एक स्पष्ट सीमा है कि यह डेटा को डिक्रिप्ट नहीं कर सकता है।
gbjbaanb

1

मुझे उन लोगों में से एक से नफरत है 'यह आपके सवाल का जवाब देने के लिए काफी नहीं है' लेकिन ..

मैं दो तैयार समाधानों के बारे में सोच सकता हूं, जिन्हें इन चिंताओं का समाधान करना चाहिए।

  1. अपने दम पर एक निजी Git सर्वर को होस्ट करें। फिर उस सर्वर को एक वीपीएन पर रखें, जिस पर आप अपनी टीम के सदस्यों को एक्सेस देते हैं। सर्वर से और इसके लिए सभी संचार एन्क्रिप्ट किए जाएंगे, और आप निश्चित रूप से ओएस-स्तर पर सर्वर को एन्क्रिप्ट कर सकते हैं।

  2. BitSync के रूप में अच्छी तरह से चाल करना चाहिए। सब कुछ एन्क्रिप्ट किया जाएगा, और एक विशाल नेटवर्क में जो कहीं से भी उपलब्ध होगा। वास्तव में यह सब BitCoin / BitMessage / BitSync तकनीक का वास्तव में अच्छा अनुप्रयोग हो सकता है।

अंत में, https://security.stackexchange.com/ पर लोगों को कुछ अधिक जानकारी हो सकती है।


BitSync के बारे में: क्या आप यह सुझाव दे रहे हैं कि इसका उपयोग संस्करण नियंत्रण प्रणाली के प्रतिस्थापन के रूप में किया जाए, या किसी तरह एक संस्करण नियंत्रण प्रणाली के साथ प्रयोग किया जाए? यदि पूर्व, तो निश्चित है, लेकिन यह बहुत दिलचस्प नहीं है। मैं बस स्पाइडरऑक पर फाइलें साझा कर सकता था और इसे केंद्रीकृत किया जाएगा, लेकिन फिर भी शून्य-ज्ञान। अगर बाद वाला, तो कैसे?
HC4 -

1
@ HighCommander4 ने इसे आज़माया नहीं है, लेकिन इसे काम नहीं करने का कोई कारण नहीं होना चाहिए .. क्या आप अपने आरंभिक गिट फ़ोल्डर को साझा करने के लिए सेटअप सिंक नहीं कर सके, तो बस एक सामान्य करें 'git push ./syncedFolderActingAsServer/MyAwesomeProject/src/'? तुम भी git स्तर अनुमतियाँ कर सकता है, आदि .. किसी को यह कोशिश करनी चाहिए!
रबर डक

1

जैसा कि मैंने इसे समझा, git pullकाम करने का तरीका यह है कि सर्वर आपको एक पैक फ़ाइल भेजता है जिसमें वे सभी ऑब्जेक्ट होते हैं जो आप चाहते हैं, लेकिन वर्तमान में नहीं है। और इसके विपरीत git push

मुझे लगता है कि आप इसे इस तरह से सीधे नहीं कर सकते (क्योंकि इसका मतलब है कि सर्वर को वस्तुओं को समझना होगा)। इसके बजाय आप क्या कर सकते हैं सर्वर को एन्क्रिप्टेड पैक फ़ाइलों की एक श्रृंखला के साथ काम करने दें।

ऐसा करने के लिए pull, आप उन सभी पैक फाइलों को डाउनलोड करते हैं जो आपके अंतिम के बाद जोड़े गए थे pull, उन्हें डिक्रिप्ट करके आपके गिट रेपो पर लागू किया गया था। करने के लिए push, आपको पहले करना होगा pull, ताकि आप सर्वर की स्थिति को जान सकें। यदि कोई संघर्ष नहीं है, तो आप अपने परिवर्तनों के साथ एक पैक फ़ाइल बनाएं, इसे एन्क्रिप्ट करें और इसे अपलोड करें।

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.