समरूपी रूप से एन्क्रिप्टेड CRDTs

 (jakelazaroff.com)
15 पॉइंट द्वारा GN⁺ 2025-06-20 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • local-first software में सहयोगी दस्तावेज़ों की सुरक्षा बनाए रखने के लिए homomorphic encryption और CRDTs को जोड़ा जाता है
  • केवल end-to-end encryption से सर्वर डेटा को merge नहीं कर सकता, जिससे sync और update efficiency पर सीमाएँ आती हैं
  • homomorphic encryption ऐसी तकनीक है जो सर्वर को सामग्री जाने बिना CRDT updates को merge करने के लिए program execution संभव बनाती है
  • लेकिन homomorphic encryption की बुनियादी सीमाओं (performance गिरावट, space और computation में वृद्धि, code को worst-case behavior के अनुसार चलाने की आवश्यकता) के कारण वास्तविक उपयोग में गंभीर कठिनाइयाँ मौजूद हैं
  • CRDTs और secure computation के सह-अस्तित्व के लिए कई approaches पर शोध चल रहा है, और अभी पूर्ण समाधान की तलाश जारी है

local-first और सुरक्षित collaboration की चुनौतियाँ

  • remote collaboration में दस्तावेज़ को local-first तरीके से CRDT में store करके, sync के माध्यम से collaborative editing experience दिया जाता है
  • अगर ऐसी security requirement हो कि दस्तावेज़ की सामग्री app developer जैसे third party के सामने भी कभी उजागर न हो, तो end-to-end encryption आम तौर पर इस्तेमाल की जाने वाली विधि है
  • end-to-end encryption का संचालन सरल है, लेकिन sync server डेटा को merge नहीं कर पाता, इसलिए लंबे समय तक asynchronous तरीके से काम करने पर अक्षम डेटा संचार होता है

homomorphic encryption क्या है?

  • homomorphic encryption एक विशेष encryption विधि है जो encrypted data पर सीधे algorithm execution संभव बनाती है
  • इसका उपयोग करने पर sync server डेटा की सामग्री जाने बिना CRDT update merge कर सकता है
  • homomorphic encryption में समर्थित operations के प्रकार के अनुसार इसे partial homomorphic (केवल addition या multiplication में से एक), somewhat/leveled homomorphic (दोनों लेकिन सीमित बार), और fully homomorphic (कोई सीमा नहीं) में बाँटा जाता है
  • operations बढ़ने पर ciphertext में noise जमा होता जाता है और decryption कठिन हो जाती है, इसलिए bootstrapping जैसी advanced techniques की आवश्यकता पड़ती है
  • encrypted bits (0/1) स्तर पर XOR, AND जैसे basic operation gates के संयोजन से सामान्य boolean circuits लागू किए जा सकते हैं

homomorphic encryption CRDT के वास्तविक implementation उदाहरण

  • Rust आधारित library TFHE-rs से Last Write Wins Register नामक एक प्रमुख CRDT को homomorphic encryption के साथ implement किया गया
  • plaintext struct और encrypted struct के fields और methods (encryption/decryption) लगभग समान हैं, लेकिन वास्तविक merge logic में महत्वपूर्ण अंतर आता है
  • क्योंकि if/else, match जैसे execution path branching से ciphertext decryption के बारे में संकेत मिल सकते हैं, encrypted environment में सभी branches और loops को तुरंत evaluate करने का तरीका अनिवार्य है
  • मुख्य condition comparison और merge operations सभी bit-level FheBool operators और select method आदि से किए जाते हैं, ताकि किस condition में value बदली, यह बाहर से पता न चल सके

homomorphic encryption की बुनियादी सीमाएँ

  • encryption key और data size का असंतुलन: उदाहरण में 32 bytes डेटा के लिए 123MB server key चाहिए (compression के बाद भी 27MB), इसलिए space inefficiency गंभीर है
  • performance गिरावट: homomorphically encrypted CRDT merge, unencrypted की तुलना में लगभग 2 अरब गुना धीमा था और लगभग 1 second स्तर पर मापा गया
  • अगर loops और branches input value के अनुसार बदलें तो information leakage हो सकती है, इसलिए हमेशा worst-case के आधार पर operations और memory खर्च करनी पड़ती है
  • उदाहरण के लिए, last-write-wins map जैसे sparse key-value मामलों में भी, merge करते समय सभी keys को fixed size में पूरी तरह भरकर संभालना पड़ता है, जिससे वास्तविक scalability घटती है
  • सिस्टम को ऐसा design करना पड़ता है कि ciphertext structure या change history देखकर बाहरी पर्यवेक्षक यह अनुमान न लगा सके कि value बदली या कौन सा हिस्सा update हुआ

निष्कर्ष और आगे की दिशा

  • CRDTs और homomorphic encryption सिद्धांत रूप में स्वाभाविक रूप से जोड़े जा सकते हैं, लेकिन व्यवहार में space/time efficiency और program structure के कारण घातक सीमाएँ बहुत बड़ी हैं
  • इस समय तक पूरी तरह practical solution नहीं आया है, लेकिन CRDTs स्वयं भी अपेक्षाकृत नई technology है और इस पर लगातार शोध जारी है
  • local-first collaboration apps में security और usability के संतुलन के लिए innovative solutions की संभावना अब भी बनी हुई है

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

1 टिप्पणियां

 
GN⁺ 2025-06-20
Hacker News राय

  • यह सच है कि fully homomorphic encryption का क्षेत्र वास्तव में बहुत धीमा और अल्प-कार्यक्षम है, लेकिन यह भी उल्लेख करना चाहिए कि यह क्षेत्र खुद 2009 में सामने आया एक अपेक्षाकृत नया क्षेत्र है; पिछले 15 वर्षों में इस क्षेत्र की प्रगति वास्तव में अद्भुत रही है। शुरुआती homomorphic encryption schemes में TB/PB स्तर की keys चाहिए थीं, और bootstrapping (homomorphic encryption में जब multiplication operations बहुत बढ़ जाते हैं तब आवश्यक operation) में हजारों घंटे लगते थे। अब keys लगभग 30MB स्तर की हैं, और bootstrapping 0.1 सेकंड के भीतर संभव हो गया है। उम्मीद है कि यह आगे भी विकसित होता रहेगा और एक दिन व्यावहारिक रूप से उपयोगी बनेगा

    • शुरुआती CRDTs भी WOOT की तरह बहुत अव्यावहारिक थे, लेकिन आज के आधुनिक CRDT databases का performance सामान्य LSM की तुलना में बहुत पीछे नहीं है। उदाहरण के लिए, RDX CRDTs merge sort जैसे algorithm पर काम करते हैं, इसलिए सब कुछ O(N) है। अधिकांश implementations में metadata overhead भी अच्छी तरह नियंत्रित किया जाता है। WOOT, librdx, go-rdx देखें

    • CRDT की architecture विशेषताओं के कारण यह धीमा होना लगभग तय है, और सबसे अच्छे algorithms में भी संरचनात्मक लागत अधिक है। उस पर homomorphic encryption जोड़ देने से चुनौती का स्तर बहुत बढ़ जाता है। यह वास्तव में प्रभावशाली है, लेकिन यह व्यवहार में उपयोगी है या नहीं, इस पर संदेह है। दावे के आधार के रूप में यह विवरण उद्धृत किया गया: "सर्वर को नया map गणना करने के लिए सभी keys को एक-एक करके merge करना होता है, और उसके बाद पूरे map को हर peer को भेजना होता है—क्योंकि सर्वर के दृष्टिकोण से पूरा map हर बार अलग होता है"

  • CRDT का अर्थ Conflict-free Replicated Data Type है, यानी एक विशेष data type जो बिना टकराव के distributed synchronization संभव बनाता है। CRDT Wikipedia लिंक देखें

    • उदाहरण के लिए, वे apps जिनमें कई लोगों को एक ही document को एक साथ संपादित करना होता है, अक्सर CRDT का उपयोग करते हैं

  • लेख में performance की कमी का उल्लेख है, और वास्तव में M4 MacBook Pro पर last write wins register को सामान्य रूप से चलाने पर merge में 0.52 nanosecond लगते हैं, जबकि homomorphic encryption वाले version में 1.06 सेकंड लगते हैं। यानी operation speed में 2 अरब गुना का अंतर है। यह सचमुच चौंकाने वाला आंकड़ा है

  • FHE(Full Homomorphic Encryption) वास्तव में बहुत धीमा है, लेकिन 2009 के बाद इसमें आश्चर्यजनक प्रगति हुई है। केवल bootstrapping speed ही करोड़ों गुना तेज हो चुकी है। tfhe-rs का उपयोग करके homomorphic encryption आधारित AES-128 का प्रदर्शन भी पहले ही किया जा चुका है। ऐसा लगता है कि AI inference/training के लिए real-time FHE अपनाने की संभावना लगातार बढ़ रही है। tfhe-aes-128 GitHub लिंक देखें

  • मैं इस बात से सहमत नहीं हूँ कि सर्वर अब क्लाइंट के बदलावों को समझ नहीं सकता। सर्वर केवल वे बदलाव भेज सकता है जो उपयोगकर्ता ने अभी तक नहीं देखे हैं, और उपयोगकर्ता उन्हें decrypt और merge करके document का नवीनतम version बना सकता है। Homomorphic encryption दिलचस्प है, लेकिन जहाँ उचित performance या bandwidth चाहिए, वहाँ यह लगभग कभी उपयुक्त नहीं है। मैंने पहले एक शोध-पत्र में homomorphic encryption आधारित पूर्ण गोपनीय computing देखी थी, जिसमें custom CPU+RAM को cipher में encode करके हर clock signal पर एक instruction प्रोसेस किया जाता था। यह वास्तव में काम करती है, लेकिन गति लगभग 1 virtual CPU instruction प्रति सेकंड के स्तर की होती है। अगर ऐसी speed और cost स्वीकार्य है, तो बेहतर है उसे local पर चलाया जाए, या अगर बहुत पैसे हों तो खुद hardware खरीदकर local पर प्रोसेस किया जाए

    • Computer science और cryptography के papers में अक्सर ऐसे शोध होते हैं जो व्यावहारिकता से काफी दूर होते हैं, जैसे attack complexity को 2^250 से 2^230 तक घटाना जैसी अत्यंत अवास्तविक बातें। फिर भी ऐसे शोध वास्तविक R&D और what’s possible की सीमा बढ़ाने में अर्थपूर्ण होते हैं

    • अगर सर्वर सामग्री को सीधे संभाल नहीं सकता, तो वह CRDT document को merge नहीं कर सकता और हर बार CRDT की पूरी state को लेकर फिर भेजना पड़ता है। अगर आपका मित्र उसी समय online है, तो operations भेजकर real-time merge किया जा सकता है, लेकिन अन्यथा यह बहुत अल्प-कार्यक्षम है

  • यह संदेह है कि क्या छात्र FHE से encrypted WASM या JS grading code को JupyterLite और ottergrader के संयोजन के साथ अपने Chromebook पर सीधे चलाएँ तब भी उस पर भरोसा किया जा सकता है। code signing और SETI@home screensaver के संबंध को लेकर भी जिज्ञासा है

  • THFE-rs का उपयोग न करना ही बेहतर होगा, क्योंकि Zama prototype उपयोग के अलावा commercial license की मांग करता है। इसकी licensing terms असुविधाजनक हैं। इसके बजाय openFHE(C++), lattigo(golang) libraries की सिफारिश की जाती है, और दोनों का commercial उपयोग स्वतंत्र रूप से किया जा सकता है

  • मुझे लगता है कि FHE यहाँ उपयोग के लिए मूल रूप से अनुपयुक्त tool है। FHE उन स्थितियों के लिए उपयुक्त है जहाँ central server ऐसे data को संभालता है जिसका मालिक वही हो या जिसे वही जानता हो। यहाँ कई उपयोगकर्ताओं को distributed data पर साथ काम करना है, इसलिए MPC(मल्टीपार्टी computation: कई प्रतिभागियों द्वारा अपने-अपने secret data पर मिलकर computation करना, जैसे योग निकालना) कहीं अधिक दक्ष होगा

    • मैं भी अक्सर FHE का उपयोग करना चाहता हूँ, लेकिन अंत में समझ आता है कि इससे बेहतर tool या अधिक उपयुक्त तरीका मौजूद है। FHE लागू हो सकने वाली स्थितियाँ खुद काफी सीमित हैं

  • लेख में रखी गई assumptions ठीक से समझ नहीं आतीं। मैं CRDT और homomorphic encryption दोनों की अवधारणाएँ समझता हूँ, लेकिन यह स्पष्ट नहीं है कि synchronization के लिए दोनों पक्षों का एक साथ online होना क्यों आवश्यक है। अगर asynchronous ‘store-and-forward’ तरीके से updates का आदान-प्रदान किया जाए, तो in-flight data भी encrypted रूप में भेजा जा सकता है; फिर सर्वर को state क्यों बनाए रखनी चाहिए (वह भी encrypted state में), और प्रस्तावित तरीके से बदलाव क्यों करने चाहिए, यह समझ नहीं आता

    • मेरा मानना है कि समस्या यह है कि सर्वर को हर peer के लिए register की अलग प्रति संग्रहीत करनी पड़ती है। सर्वर यह निर्धारित नहीं कर सकता कि सबसे नई state कौन-सी है। FHE का उपयोग करने पर सर्वर केवल एक प्रति बनाए रख सकता है। यानी अगर सभी peers हमेशा online हों (एक ही समय पर जुड़े हों), तो सर्वर केवल relay कर सकता है और अलग से कुछ संग्रहीत करने की आवश्यकता नहीं होती

  • FHE की धीमी और अल्प-कार्यक्षम प्रकृति के साथ CRDT की storage overhead का मिलना काफ़ी दिलचस्प लगता है