एन्क्रिप्शन कार्यान्वयन संदर्भ
जो एन्क्रिप्शन वास्तव में चलता है वह उस एन्क्रिप्शन से संकीर्ण है जो लिखा गया है, और यह पृष्ठ उसी अंतर के लिए है। libsodium sealed box ही एकमात्र संदेश एन्क्रिप्शन है जिसे Railgun निष्पादित करता है — और वे केवल उसी क्लाइंट पथ पर निष्पादित होते हैं जहाँ नेटिव libsignal मॉड्यूल अनुपस्थित है। Electron डेस्कटॉप बिल्ड पर, जहाँ libsignal वास्तव में लोड होता है, सीधे संदेशों को एन्क्रिप्ट करने वाला हैंडलर अब भी एक प्लेसहोल्डर है जो प्लेनटेक्स्ट को base64 में एनकोड कर देता है। समुदाय और चैनल संदेश किसी भी पथ पर एन्क्रिप्ट नहीं किए जाते। इस पृष्ठ के दूसरे भाग में वर्णित Signal-शैली प्रोटोकॉल लिखा और समीक्षित है, और किसी भी ऐसे क्लाइंट से जुड़ा हुआ नहीं है जिसे आप डाउनलोड कर सकते हैं।
यह एक आर्किटेक्चर संदर्भ है, स्वतंत्र सुरक्षा ऑडिट नहीं। खंड 1 और 2 बताते हैं कि क्या शिप होता है। खंड 4 से 7 उस डिज़ाइन का वर्णन करते हैं जिसकी ओर Railgun काम कर रहा है और उन्हें पूरे पृष्ठ में नियोजित के रूप में चिह्नित किया गया है। यहाँ किसी भी बात को इस दावे के रूप में नहीं पढ़ा जाना चाहिए कि कोई Railgun क्लाइंट फ़िलहाल नियोजित चिह्नित किसी गुण को लागू करता है।
आज क्या शिप होता है
| पथ | तंत्र | स्थिति |
|---|---|---|
| सीधे संदेश — ब्राउज़र और डेवलपमेंट बिल्ड | libsodium sealed box — X25519 कुंजी समझौता, XSalsa20-Poly1305 प्रमाणित एन्क्रिप्शन। तब चुना जाता है जब नेटिव libsignal मॉड्यूल अनुपस्थित हो। | एन्क्रिप्टेड |
| सीधे संदेश — Electron डेस्कटॉप बिल्ड | libsignal लोड होता है, इसलिए encryptDm को Electron IPC हैंडलर पर भेज दिया जाता है — एक प्लेसहोल्डर जो प्लेनटेक्स्ट को base64 में एनकोड करता है। रिले को पढ़ने योग्य टेक्स्ट मिलता है। | एन्क्रिप्टेड नहीं |
| समुदाय और चैनल संदेश | base64 में लिपटे प्लेनटेक्स्ट के रूप में भेजे जाते हैं। चैनल एन्क्रिप्शन लिखा गया है पर वह एक प्लेनटेक्स्ट मार्कर लौटाता है। | एन्क्रिप्टेड नहीं |
| X3DH + Double Ratchet | libsignal के विरुद्ध कार्यान्वित, केवल एक टाइप के रूप में इम्पोर्ट किया गया। कोई रनटाइम पथ इसे इंस्टैंशिएट नहीं करता। | नियोजित |
| निजी कुंजी संग्रहण | कुंजियाँ डिवाइस पर ही उत्पन्न होती हैं और वहीं रखी जाती हैं। कोई भी कोड पथ निजी या पहचान कुंजी सामग्री प्रसारित नहीं करता। | कार्यान्वित |
1. Sealed box — वह एन्क्रिप्शन जो चलता है
जहाँ Railgun किसी सीधे संदेश को एन्क्रिप्ट करता भी है, वहाँ वह ऐसा libsodium sealed box — crypto_box_seal संरचना — से करता है। यह X25519 कुंजी समझौते को XSalsa20-Poly1305 प्रमाणित एन्क्रिप्शन के साथ जोड़ता है। यह वास्तविक, अच्छी तरह समीक्षित क्रिप्टोग्राफ़ी है। यह जानबूझकर बनाई गई एक सरल संरचना भी है, और इसकी सीमाएँ मायने रखती हैं। कौन-से क्लाइंट इस तक पहुँचते हैं, यह खंड 2 का विषय है: ब्राउज़र और डेवलपमेंट बिल्ड पहुँचते हैं; Electron डेस्कटॉप बिल्ड नहीं पहुँचता।
sealed box कैसे बनाया जाता है
// Sender has only the recipient's public key, PK_r
(pk_e, sk_e) = crypto_box_keypair() // fresh, single-use
nonce = BLAKE2b(pk_e || PK_r) // derived, not random
ct = crypto_box(plaintext, nonce, PK_r, sk_e)
sealed = pk_e || ct // ephemeral key is prepended
erase(sk_e)
प्राप्तकर्ता संदेश के आरंभ से क्षणिक सार्वजनिक कुंजी निकालता है, अपनी निजी कुंजी से वही साझा गुप्त पुनः गणना करता है, और बॉक्स खोल लेता है। Poly1305 टैग का अर्थ है कि बदला हुआ सिफरटेक्स्ट कचरे में डिक्रिप्ट होने के बजाय खुलने में ही विफल हो जाता है।
यह आपको क्या देता है
- • रिले के विरुद्ध और तार पर मौजूद किसी भी व्यक्ति के विरुद्ध गोपनीयता।
- • अखंडता — छेड़छाड़ का पता चल जाता है, वह चुपचाप डिक्रिप्ट नहीं होती।
- • प्रेषक गुमनामी: क्षणिक कुंजी इस बारे में कुछ भी उजागर नहीं करती कि इसे किसने भेजा।
- • कोई सत्र सेटअप नहीं, इसलिए यह तब भी काम करता है जब प्राप्तकर्ता ऑफ़लाइन हो।
यह आपको क्या नहीं देता
- • कोई फ़ॉरवर्ड सीक्रेसी नहीं। प्राप्तकर्ता की दीर्घकालिक निजी कुंजी उन्हें अब तक भेजा गया हर संदेश खोल देती है। यदि वह लीक होती है, तो उसके साथ पकड़ा गया सिफरटेक्स्ट भी लीक हो जाता है।
- • कोई प्रेषक प्रमाणीकरण नहीं। sealed box अपनी संरचना से ही गुमनाम है; यह इस बारे में कुछ भी सिद्ध नहीं करता कि इसे किसने लिखा।
- • समझौते के बाद कोई पुनर्प्राप्ति नहीं। कुंजी के समझौते से आगे बढ़ने के लिए कोई ratchet नहीं है।
ये तीनों कमियाँ ठीक वही हैं जिन्हें बंद करने के लिए X3DH और Double Ratchet मौजूद हैं, और इसीलिए वह काम चल रहा है। जब तक वह पूरा नहीं होता, sealed-box DM का ईमानदार सारांश यह है: निष्क्रिय नेटवर्क पर्यवेक्षक और रिले के विरुद्ध मज़बूत, पर ऐसे प्रतिद्वंद्वी के विरुद्ध कमज़ोर जो अंततः प्राप्तकर्ता की डिवाइस कुंजी हासिल कर ले। यह सारांश केवल वहीं लागू होता है जहाँ यह कोड वास्तव में चलता है।
2. क्या एन्क्रिप्ट नहीं किया जाता
समुदाय और चैनल संदेश — अधिकांश Railgun उपयोगकर्ता वास्तव में जो लिखते हैं उसका बड़ा हिस्सा — आज किसी भी क्लाइंट पथ पर एन्क्रिप्ट नहीं किए जाते। चैनल एन्क्रिप्शन फ़ंक्शन मौजूद है, और वह अपने बारे में स्पष्टवादी है: यह एक चेतावनी लॉग करता है और एक मार्कर स्ट्रिंग के पीछे base64 में लिपटा प्लेनटेक्स्ट लौटाता है, ताकि आगे कोई भी इसे सिफरटेक्स्ट न समझ बैठे।
// What encryptChannel actually returns
logger.warn("Channel encryption not yet implemented")
ciphertext = base64("[DEVCRYPTO:PLAINTEXT]" + plaintext)
व्यावहारिक परिणाम: समुदाय और चैनल सामग्री के लिए Railgun सर्वर उसी स्थिति में है जिसमें कोई भी साधारण चैट सर्वर होता है। आप वहाँ जो लिखते हैं, वह उसे पढ़ सकता है। समूह कुंजी वितरण — प्रति-चैनल एक कुंजी जो सदस्यों को sealed box के भीतर सौंपी जाती है — नियोजित समाधान है और शिप नहीं किया गया है।
Electron डेस्कटॉप बिल्ड पर सीधे संदेश
दूसरी कमी उस क्लाइंट पर सीधे संदेशों की है जिसे अधिकांश लोग चलाते हैं, और इसे उलटा कह देना आसान है, इसलिए यहाँ वह चयन तर्क है जैसा कोड उसे निष्पादित करता है। initCrypto() मुख्य प्रक्रिया से पूछता है कि क्या libsignal लोड हुआ। @signalapp/libsignal-client एक वास्तविक निर्भरता है और स्टार्टअप पर आवश्यक है, इसलिए शिप की गई Electron बिल्ड पर यह वास्तव में लोड होता है — और वही उत्तर sealed-box कार्यान्वयन के बजाय Electron IPC कार्यान्वयन का चयन करता है। इसका encryptDm crypto:encryptDm हैंडलर को आगे भेज देता है, जो एक प्लेसहोल्डर है:
// crypto:encryptDm, Electron main process
const plaintextBytes = new TextEncoder().encode(plaintext)
ciphertext: toBase64(plaintextBytes) // not encryption
इसलिए खंड 1 के sealed box तब पहुँच में आते हैं जब libsignal अनुपस्थित हो — ब्राउज़र में और डेवलपमेंट में। डेस्कटॉप क्लाइंट पर, एक सीधा संदेश रिले तक base64-एनकोडेड प्लेनटेक्स्ट के रूप में पहुँचता है। libsignal वहाँ एक पहचान कुंजी और एक प्रीकी बंडल उत्पन्न करने के लिए लोड किया जाता है; यह कोई सत्र स्थापित नहीं करता और कुछ भी ratchet नहीं करता — crypto:ensureDmSession एक डिबग लॉग है जिसका कोई मुख्य भाग नहीं है।
3. Curve25519 — अंतर्निहित वक्र
जो sealed box शिप होते हैं और जो X3DH डिज़ाइन शिप नहीं होता, दोनों एक ही दीर्घवृत्तीय वक्र पर टिके हैं: Curve25519, जिसे Daniel J. Bernstein ने उच्च-गति Diffie-Hellman कुंजी विनिमय के लिए डिज़ाइन किया था। यह खंड स्वयं वक्र का वर्णन करता है, और दोनों पर लागू होता है।
वक्र समीकरण
y² = x³ + 486662x² + x
over the prime field 𝔽ₚ where p = 2²⁵⁵ − 19
अभाज्य संख्या 2²⁵⁵ − 19 इसलिए चुनी गई क्योंकि यह अत्यंत तेज़ मॉड्यूलर अंकगणित संभव बनाती है। गुणांक 486662 इसलिए चुना गया क्योंकि यह वह सबसे छोटा मान है जो आवश्यक सुरक्षा गुणों वाला एक सुरक्षित वक्र उत्पन्न करता है।
कुंजी उत्पादन
1. निजी कुंजी: CSPRNG (क्रिप्टोग्राफ़िक रूप से सुरक्षित छद्म-यादृच्छिक संख्या जनरेटर) का उपयोग करके 32 यादृच्छिक बाइट उत्पन्न करें। सबसे निचले 3 बिट और सबसे ऊपरी बिट को साफ़ करके तथा दूसरे-सबसे-ऊपरी बिट को सेट करके कुंजी को क्लैंप करें। इससे यह सुनिश्चित होता है कि कुंजी 8 की गुणज है और वैध परास में है।
a = random(32 bytes)
a[0] &= 248 // Clear low 3 bits
a[31] &= 127 // Clear high bit
a[31] |= 64 // Set second-highest bit
2. सार्वजनिक कुंजी: आधार बिंदु G = 9 के साथ निजी कुंजी का अदिश गुणन गणना करें।
A = a · G // Scalar multiplication on Curve25519
सुरक्षा दीर्घवृत्तीय वक्र असतत लघुगणक समस्या (ECDLP) पर निर्भर करती है: A और G दिए जाने पर a को पुनः प्राप्त करना संगणनात्मक रूप से असंभव है। Curve25519 लगभग 128 बिट सुरक्षा प्रदान करता है।
Diffie-Hellman कुंजी विनिमय
दो पक्ष (ऐलिस और बॉब) साझा गुप्त की गणना उसे कभी प्रसारित किए बिना कर सकते हैं:
Alice: a (private), A = a·G (public)
Bob: b (private), B = b·G (public)
Alice computes: S = a · B = a · (b·G)
Bob computes: S = b · A = b · (a·G)
Both arrive at S = ab·G — the same shared secret
एक श्रोता जो A और B (दोनों सार्वजनिक) जानता है, ECDLP हल किए बिना S की गणना नहीं कर सकता। यही संगणनात्मक Diffie-Hellman (CDH) अवधारणा है।
एक sealed box यही विनिमय है जिसमें एक पक्ष को क्षणिक बनाकर फेंक दिया जाता है। नीचे दिया गया X3DH यही विनिमय है जो अलग-अलग कुंजी युग्मों पर चार बार किया जाता है, ताकि परिणाम सामग्री छिपाने के साथ-साथ दोनों पक्षों को प्रमाणित भी करे।
4. X3DH — विस्तारित त्रिगुण Diffie-Hellman
नियोजितX3DH एक कठिन समस्या हल करता है: दो लोग एन्क्रिप्टेड सत्र कैसे स्थापित करें जब उनमें से एक ऑफ़लाइन हो? पारंपरिक Diffie-Hellman के लिए दोनों पक्षों का ऑनलाइन होना आवश्यक है। X3DH अतुल्यकालिक कुंजी समझौता संभव बनाने के लिए पूर्व-अपलोड किए गए कुंजी बंडलों का उपयोग करता है।
कुंजी प्रकार
पहचान कुंजी (IK)
दीर्घकालिक Curve25519 कुंजी युग्म। एक बार उत्पन्न होती है, उपयोगकर्ता को क्रिप्टोग्राफ़िक रूप से पहचानती है। जब तक उपयोगकर्ता पुनः पंजीकरण न करे, कभी नहीं बदलती।
हस्ताक्षरित प्री-की (SPK)
मध्यम-अवधि Curve25519 कुंजी युग्म, पहचान कुंजी द्वारा हस्ताक्षरित। समय-समय पर घुमाया जाता है। हस्ताक्षर सिद्ध करता है कि यह पहचान कुंजी धारक की है।
एक-बारगी प्री-की (OPK)
क्षणिक Curve25519 कुंजी युग्म जो बैचों में अपलोड किए जाते हैं। प्रत्येक एक बार उपयोग होकर हटा दिया जाता है। यह आरंभिक संदेश के लिए फ़ॉरवर्ड सीक्रेसी की एक अतिरिक्त परत देता है।
क्षणिक कुंजी (EK)
प्रेषक द्वारा हर नए सत्र के लिए उत्पन्न किया गया एक नया Curve25519 कुंजी युग्म। सर्वर पर कभी संग्रहीत नहीं होता।
X3DH हैंडशेक
जब ऐलिस बॉब को संदेश भेजना चाहती है (जो ऑफ़लाइन हो सकता है), तो वह सर्वर से बॉब का प्री-की बंडल लाती है और चार Diffie-Hellman गणनाएँ करती है:
// Alice has: IKₐ (her identity key), EKₐ (fresh ephemeral)
// Bob published: IKᵦ, SPKᵦ, OPKᵦ
DH1 = DH(IKₐ, SPKᵦ) // her identity ↔ his signed pre-key
DH2 = DH(EKₐ, IKᵦ) // her ephemeral ↔ his identity
DH3 = DH(EKₐ, SPKᵦ) // her ephemeral ↔ his signed pre-key
DH4 = DH(EKₐ, OPKᵦ) // her ephemeral ↔ his one-time pre-key
SK = KDF(DH1 || DH2 || DH3 || DH4)
// SK is the shared secret, derived via HKDF-SHA-256
चार DH संक्रियाएँ क्यों?
- DH1 पारस्परिक प्रमाणीकरण देता है (दोनों पहचान कुंजियाँ शामिल होती हैं)
- DH2 सुनिश्चित करता है कि क्षणिक कुंजी बॉब की पहचान से बंधी है
- DH3 क्षणिक कुंजी के माध्यम से फ़ॉरवर्ड सीक्रेसी देता है
- DH4 अतिरिक्त फ़ॉरवर्ड सीक्रेसी देता है। यदि कोई OPK उपलब्ध न हो, तो X3DH केवल DH1–DH3 के साथ भी काम करता है
DH1 वही संक्रिया है जो sealed box के पास नहीं है। यही कारण है कि शिप होने वाला पथ आपको यह नहीं बता सकता कि संदेश किसकी ओर से आया।
KDF — कुंजी व्युत्पत्ति फ़ंक्शन
कच्चे DH आउटपुट को HKDF-SHA-256 (HMAC-आधारित कुंजी व्युत्पत्ति फ़ंक्शन) का उपयोग करके संयोजित किया जाता है। HKDF संयुक्त DH आउटपुट से एन्ट्रॉपी निकालता है और उसे एक समान रूप से यादृच्छिक साझा गुप्त में विस्तारित करता है:
PRK = HKDF-Extract(salt="", input=DH1||DH2||DH3||DH4)
SK = HKDF-Expand(PRK, info="RailGunX3DH", length=32)
5. Double Ratchet एल्गोरिदम
नियोजितएक बार X3DH आरंभिक साझा गुप्त स्थापित कर दे, तो Double Ratchet कमान सँभाल लेता है। यह हर संदेश के लिए एक नई अनूठी कुंजी व्युत्पन्न करने हेतु दो परस्पर जुड़े "ratchet" उपयोग करता है। यह डिज़ाइन पिछले संदेशों की रक्षा करता है और एक नए ratchet चरण के बाद भविष्य के संदेशों की सुरक्षा बहाल करने के लिए बनाया गया है।
DH ratchet (असममित)
हर बार जब बातचीत की दिशा बदलती है (ऐलिस → बॉब, फिर बॉब → ऐलिस), तो नई क्षणिक कुंजियों का उपयोग करते हुए एक नया Diffie-Hellman कुंजी विनिमय होता है। यह मूल कुंजी को आगे "ratchet" करता है:
dh_out = DH(my_ratchet_key, their_ratchet_key)
root_key, chain_key = KDF(root_key, dh_out)
यही समझौते-पश्चात सुरक्षा प्रदान करेगा: जो हमलावर वर्तमान स्थिति चुरा लेता है, नया DH ratchet चरण होते ही उसकी पहुँच समाप्त हो जाती है।
सममित ratchet (हैश शृंखला)
DH ratchet चरणों के बीच, एक हैश-आधारित ratchet हर संदेश के लिए शृंखला कुंजी से एक नई संदेश कुंजी व्युत्पन्न करता है:
message_key = HMAC-SHA256(chain_key, 0x01)
chain_key = HMAC-SHA256(chain_key, 0x02)
पुरानी शृंखला कुंजी हर चरण के बाद हटा दी जाती है। संदेश कुंजी ठीक एक संदेश एन्क्रिप्ट करती है, फिर हटा दी जाती है। यही फ़ॉरवर्ड सीक्रेसी तंत्र है।
ratchet की प्रगति
देखने में, Double Ratchet ऐसा दिखता है। हर तीर एक एकदिशीय फ़ंक्शन है — आप आगे जा सकते हैं पर कभी पीछे नहीं:
Root Key Chain:
RK₀ ──DH──→ RK₁ ──DH──→ RK₂ ──DH──→ RK₃ ...
Each RK step produces a Chain Key:
↓ ↓ ↓
CK₀ CK₁ CK₂
↓ ↓ ↓
Each CK step produces Message Keys:
CK₀→MK₀ CK₁→MK₃ CK₂→MK₅
CK₀→MK₁ CK₁→MK₄ CK₂→MK₆
CK₀→MK₂ CK₂→MK₇
प्रत्येक MKₙ ठीक एक संदेश एन्क्रिप्ट करेगा और फिर हटा दिया जाएगा, इसलिए जिस हमलावर को MK₄ मिल जाए वह MK₃ या MK₅ व्युत्पन्न नहीं कर सकेगा। जो sealed-box पथ आज शिप होता है, उस पर चुराने के लिए कोई प्रति-संदेश कुंजी नहीं है और चलने के लिए कोई शृंखला नहीं है — वहाँ एक ही दीर्घकालिक कुंजी है जो सब कुछ खोल देती है।
6. फ़ॉरवर्ड सीक्रेसी — इसके लिए क्या चाहिए
नियोजितफ़ॉरवर्ड सीक्रेसी का अर्थ है कि दीर्घकालिक कुंजियों के साथ समझौता होने से पिछली सत्र कुंजियों के साथ समझौता नहीं होता। Railgun के पास यह आज नहीं है। दो तंत्र इसे प्रदान करेंगे, और दोनों ऊपर वर्णित नियोजित प्रोटोकॉल का हिस्सा हैं:
X3DH में क्षणिक कुंजियाँ
प्रेषक हर नए सत्र के लिए एक नया क्षणिक कुंजी युग्म उत्पन्न करता है और हैंडशेक के बाद निजी आधा हिस्सा हटा देता है। जो हमलावर बाद में दोनों पक्षों की पहचान कुंजियाँ चुरा ले, वह फिर भी सत्र गुप्त का पुनर्निर्माण नहीं कर सकता। sealed box प्रेषक की ओर एक नई क्षणिक कुंजी का उपयोग करते तो हैं — पर विनिमय में प्राप्तकर्ता का आधा हिस्सा उनकी दीर्घकालिक कुंजी है, और ठीक इसीलिए यह गुण कायम नहीं रहता।
ratchet कुंजी विलोपन
Double Ratchet उपयोग के बाद पुरानी शृंखला कुंजियाँ और संदेश कुंजियाँ हटा देता है। KDF शृंखला एकदिशीय है — CKₙ दिए जाने पर आप CKₙ₊₁ की गणना कर सकते हैं पर CKₙ₋₁ की नहीं, इसलिए समय T पर हुआ समझौता T से पहले भेजी गई किसी भी चीज़ को उजागर नहीं करता।
समझौते-पश्चात सुरक्षा
DH ratchet भविष्य की गोपनीयता भी प्रदान करता है: जो हमलावर वर्तमान सत्र स्थिति से समझौता कर लेता है, वह उसे अगले ratchet चरण पर खो देता है, क्योंकि वह चरण ऐसी यादृच्छिकता लाता है जो उसके पास नहीं है। ratchet के बिना, समझौता की गई कुंजी हमलावर के लिए अनिश्चित काल तक उपयोगी बनी रहती है।
7. रिले और क्यू आर्किटेक्चर
Railgun लिफ़ाफ़ों को रिले करता है और ऑफ़लाइन डिलीवरी के लिए उन्हें अस्थायी रूप से क्यू में रख सकता है। रिले इस तरह बनाया गया है कि उसे संदेश के प्लेनटेक्स्ट की ज़रूरत न पड़े, पर आज उसे दो मामलों में प्लेनटेक्स्ट मिलता है: चैनल संदेश, जिन्हें कोई भी क्लाइंट एन्क्रिप्ट नहीं करता, और Electron डेस्कटॉप बिल्ड से आने वाले सीधे संदेश, जिनका IPC हैंडलर एन्क्रिप्ट करने के बजाय base64 में एनकोड करता है। sealed-box पथ से आया सीधा संदेश ऐसे सिफरटेक्स्ट के रूप में पहुँचता है जिसे रिले खोल नहीं सकता।
सर्वर क्या देखता है
सर्वर के पास रहता है:
- • सार्वजनिक कुंजी बंडल
- • उपयोगकर्ता पंजीकरण जानकारी
- • समुदाय/चैनल मेटाडेटा और सदस्यता
- • sealed-box सिफरटेक्स्ट जिसे वह खोल नहीं सकता (ब्राउज़र/डेव पथ से आए DM)
- • Electron डेस्कटॉप बिल्ड से आया base64-एनकोडेड DM प्लेनटेक्स्ट
- • चैनल संदेश सामग्री, जब तक चैनल एन्क्रिप्शन शिप नहीं होता
- • प्रमाणीकरण ऑडिट रिकॉर्ड
सर्वर को कभी नहीं मिलता:
- • निजी या पहचान कुंजियाँ
- • क्लाइंट सत्र स्थिति
- • आपके संदेश इतिहास की कोई स्थायी प्रति
ऑनलाइन प्राप्तकर्ताओं को संदेश WebSocket पर वास्तविक समय में रिले किए जाते हैं। ऑफ़लाइन डिवाइसों के लिए, लिफ़ाफ़े अधिकतम 30-दिन TTL के साथ Redis में क्यू किए जाते हैं और डिवाइस द्वारा पुष्टि मिलते ही हटा दिए जाते हैं। सर्वर पर कोई संदेश संग्रह नहीं है — क्लाइंट इतिहास आपके अपने डिवाइस के स्थानीय संग्रहण में रहता है, इसलिए खोया हुआ डिवाइस खोया हुआ इतिहास है।
8. सुरक्षा गुणों का सारांश
| गुण | तंत्र | स्थिति |
|---|---|---|
| DM गोपनीयता | sealed box केवल ब्राउज़र/डेवलपमेंट पथ पर; Electron डेस्कटॉप हैंडलर base64 में एनकोड करता है | आंशिक |
| DM अखंडता | sealed-box पथ पर Poly1305 टैग; Electron डेस्कटॉप पथ अप्रमाणित base64 भेजता है | आंशिक |
| कुंजियाँ डिवाइस पर ही रहती हैं | स्थानीय कुंजी संग्रह; कोई भी कोड पथ निजी कुंजियाँ प्रसारित नहीं करता | कार्यान्वित |
| ऑफ़लाइन डिलीवरी | लिफ़ाफ़े 30-दिन TTL के साथ Redis में क्यू किए जाते हैं, पुष्टि पर हटा दिए जाते हैं | कार्यान्वित |
| चैनल गोपनीयता | समूह कुंजी वितरण कार्यान्वित नहीं है; सामग्री पढ़ने योग्य रूप में भेजी जाती है | कार्यान्वित नहीं |
| प्रेषक प्रमाणीकरण | sealed box अपनी संरचना से ही गुमनाम हैं | कार्यान्वित नहीं |
| फ़ॉरवर्ड सीक्रेसी | इसके लिए Double Ratchet चाहिए, जिसे कोई भी क्लाइंट इंस्टैंशिएट नहीं करता | नियोजित |
| समझौते-पश्चात पुनर्प्राप्ति | इसके लिए DH ratchet चाहिए, जिसे कोई भी क्लाइंट इंस्टैंशिएट नहीं करता | नियोजित |
| स्वतंत्र ऑडिट | किसी पूर्ण तृतीय-पक्ष क्रिप्टोग्राफ़िक ऑडिट का दावा नहीं किया जाता | पूर्ण नहीं |
| पोस्ट-क्वांटम गारंटी | किसी भी प्रकार की सर्वव्यापी पोस्ट-क्वांटम सुरक्षा गारंटी का दावा नहीं किया जाता | दावा नहीं किया गया |
यह पृष्ठ कहाँ से आता है
ऊपर दी गई हर स्थिति किसी डिज़ाइन दस्तावेज़ से नहीं, बल्कि क्लाइंट स्रोत कोड से पढ़ी गई है। क्लाइंट रिपॉज़िटरी फ़िलहाल सार्वजनिक नहीं है, इसलिए हम आपसे स्वयं इसकी जाँच करने को नहीं कह सकते — और यही एक कारण है कि इस पृष्ठ को प्रमाण के रूप में नहीं, बल्कि एक प्रकटीकरण के रूप में तौला जाए। किसी विशिष्ट दावे के बारे में प्रश्नों का security@railgun.chat पर स्वागत है।