Keyhive - लोकल-फर्स्ट एक्सेस कंट्रोल

 (inkandswitch.com)
3 पॉइंट द्वारा GN⁺ 2025-10-29 | अभी कोई टिप्पणी नहीं है. | WhatsApp पर शेयर करें
  • Keyhive एक रिसर्च प्रोजेक्ट है जिसका उद्देश्य केंद्रीय सर्वर के बिना, ऑफ़लाइन में भी काम करने वाला लोकल-फर्स्ट एक्सेस कंट्रोल सिस्टम बनाना है, और Signal-स्तर की सुरक्षा को दस्तावेज़ सहयोग में लागू करने का प्रयास करना है
  • वितरित वातावरण में भी सिंक्रोनाइज़ किए जा सकने वाले Capability Model और Group Management CRDT, तथा causal relationship-आधारित E2EE(Causal Keys) के माध्यम से सहयोग के दौरान भी सुरक्षित डेटा एक्सेस कंट्रोल संभव होता है
  • मुख्य क्रिप्टोग्राफिक प्रोटोकॉल BeeKEM केंद्रीय सर्वर के बिना भी Forward Secrecy और Post-Compromise Security की गारंटी देता है और हज़ारों सदस्यों वाले समूहों को संभाल सकता है
  • Keyhive की सिंक लेयर Beelay RIBLT-आधारित सेट सिंक्रोनाइज़ेशन और Sedimentree compression method का उपयोग करके बड़े पैमाने के लोकल दस्तावेज़ सिंक्रोनाइज़ेशन की गति को बेहतर बनाती है
  • Ink & Switch इस प्रोजेक्ट के माध्यम से सर्वर-निर्भरता रहित सुरक्षित सहयोग प्लेटफ़ॉर्म की आधारभूत तकनीक प्रस्तुत करता है और ऑफ़लाइन-फर्स्ट सॉफ़्टवेयर इकोसिस्टम के विस्तार का लक्ष्य रखता है

Keyhive का अवलोकन

  • Keyhive क्लाउड सर्वर का उपयोग किए बिना भी सहयोगी डेटा के लिए एक्सेस कंट्रोल को लोकल-फर्स्ट(local-first) वातावरण में लागू करने के लिए किया गया एक शोध है
    • पारंपरिक क्लाउड authentication (जैसे OAuth) केंद्रीय सर्वर के माध्यम से permission verification पर निर्भर करता है, लेकिन लोकल-फर्स्ट मॉडल में डेटा और permissions को साथ में चलना चाहिए
    • इसके लिए Keyhive capability-आधारित डिज़ाइन अपनाता है और वितरित authentication·encryption layer बनाता है
  • लक्ष्य Google Docs और GitHub जैसी user-friendly experience बनाए रखते हुए भी पूर्ण decentralized collaboration security को लागू करना है

डिज़ाइन दर्शन और संरचना

  • Keyhive को इस सिद्धांत पर डिज़ाइन किया गया है कि डेटा लेयर से पहले एक्सेस कंट्रोल लेयर मौजूद होनी चाहिए
    • इसके कारण storage और synchronization structure को भी encryption·permission management तरीके का पालन करना पड़ता है
  • तीन मुख्य घटक:
    1. Convergent Capabilities: CRDT के लिए उपयुक्त एक नया permission model, जिसमें entities के बीच delegation को cryptographically prove किया जा सकता है
    2. Group Management CRDT: केंद्रीय सर्वर के बिना समूह जोड़ना-हटाना और permission revocation करना
    3. E2EE with Causal Keys: दस्तावेज़ की causal structure के अनुसार keys को manage करके efficient encryption लागू करना

Convergent Capabilities

  • यह मॉडल मौजूदा Object-capability और Certificate-capability के फ़ायदों को जोड़ता है
    • इसमें CRDT state शामिल की जाती है ताकि ऑफ़लाइन स्थिति में भी consistency(convergence) बनी रहे
  • public-key-आधारित delegation system के ज़रिए user, group और document को समान entities के रूप में संभाला जा सकता है
    • उदाहरण: user device group बना सकता है, और document team unit बनाकर access permission दे सकता है

BeeKEM: समूह key agreement protocol

  • BeeKEM एक continuous group key agreement(CGKA) प्रोटोकॉल है जो केंद्रीय सर्वर के बिना काम करता है
    • यह TreeKEM की संरचना को आगे बढ़ाते हुए इसे ऐसा बनाता है कि यह केवल causal order के आधार पर काम कर सके
    • इसे केवल Diffie-Hellman key exchange और BLAKE3 hash function का उपयोग करके standard cryptography के आधार पर डिज़ाइन किया गया है
  • मुख्य विशेषताएँ:
    • समूह सदस्य जोड़ना-हटाना, concurrent update conflicts को हल करना, खाली nodes को restore करना—ये सभी काम distributed state में किए जाते हैं
    • concurrency conflict होने पर “Conflict Key” merge algorithm के माध्यम से सुरक्षा बनाए रखी जाती है
    • सामान्य स्थिति में logarithmic समय प्रदर्शन, और worst case में linear प्रदर्शन

Beelay: न्यूनतम-विश्वास synchronization protocol

  • Beelay Keyhive के डेटा और permission information को sync करने वाला एक RPC-आधारित protocol है, जिसमें server केवल encrypted data relay करता है
    • messages को Ed25519 signatures से authenticate किया जाता है, और replay attack तथा person-in-the-middle attack(PITM) से सुरक्षा अंतर्निहित है
  • मुख्य कार्यप्रणाली:
    • RIBLT (Rateless Invertible Bloom Lookup Table) का उपयोग करके set difference की गणना की जाती है, जिससे बड़े डेटा का तेज़ synchronization संभव होता है
    • membership graph (group·document relationship), document collection state, और document body को क्रमवार sync किया जाता है
  • Sedimentree संरचना के माध्यम से Automerge commit graph को compress और merge किया जाता है, जिससे बड़े दस्तावेज़ synchronization में bandwidth की बचत होती है

synchronization flow

  1. membership graph synchronization: समूह और permission संबंधों को sync करना
  2. document collection synchronization: बदले हुए दस्तावेज़ों की पहचान करना
  3. CGKA synchronization: BeeKEM operations को merge करना
  4. document body synchronization: Sedimentree-आधारित compressed transfer
  • सामान्य रूप से केवल 1 बदलाव के मामले में सिर्फ 2 round-trip requests में पूरा synchronization पूरा हो जाता है

आगे की योजना

  • Keyhive वर्तमान में pre-alpha version public release स्थिति में है, और Rust-आधारित implementation तथा WASM/TypeScript bindings प्रदान करता है
    • keyhive_core: signature·encryption·delegation system
    • beelay-core: encrypted-data-आधारित synchronization engine
    • keyhive_wasm: browser support के लिए wrapper
  • आगे सुरक्षा सत्यापन और performance papers जारी किए जाएंगे, और लोकल-फर्स्ट collaboration systems के लिए सुरक्षा का standard model स्थापित करना लक्ष्य है

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

अभी कोई टिप्पणी नहीं है.

अभी कोई टिप्पणी नहीं है.