फ़ाइल ट्रांसफर के लिए एंड-टू-एंड एन्क्रिप्शन कैसे काम करता है

फाइल ट्रांसफर के लिए एंड-टू-एंड एन्क्रिप्शन का मतलब है कि आपके डिवाइस से जाने वाले बाइट्स एक ऐसी कुंजी से एन्क्रिप्ट होते हैं जो कभी सर्वर को नहीं छूती, और केवल आपके इच्छित प्राप्तकर्ता उन्हें डिक्रिप्ट कर सकते हैं। सर्वर सिफरटेक्स्ट संग्रहीत करता है, कुछ भी अर्थपूर्ण नहीं देखता, और यदि सर्वर हैक भी हो जाए तो आपकी फाइल की सामग्री उजागर नहीं होती। क्रिप्टोग्राफिक नुस्खे में लगभग हमेशा फाइल के लिए AES-256-GCM या XChaCha20-Poly1305 जैसा सममित सिफर शामिल होता है, जिसे कुंजी सामग्री के लिए X25519 ECDH या RSA-OAEP 2048/4096 जैसे कुंजी विनिमय के साथ लपेटा जाता है।

E2EE वास्तव में किस खतरे के मॉडल की रक्षा करता है

E2EE विशेष रूप से इनके विरुद्ध बचाव करता है: ट्रांसफर प्रदाता हैक, सब्पोना, या दुर्भावनापूर्ण होना; नेटवर्क हमलावर प्रॉक्सी पर TLS-डिक्रिप्टेड ट्रैफिक को इंटरसेप्ट करना; स्टोरेज बाल्टी के बैकअप स्नैपशॉट गलत हाथों में पड़ना; और सेवा के कर्मचारियों द्वारा इनसाइडर एक्सेस। यह प्रेषक या प्राप्तकर्ता के डिवाइस पर मैलवेयर, डिक्रिप्शन लिंक कैप्चर करने वाला फिशिंग, या समझौता किए गए प्राप्तकर्ता खाते के विरुद्ध बचाव नहीं करता। मॉडल को समझना महत्वपूर्ण है, क्योंकि "एन्क्रिप्टेड" का अक्सर गलत उपयोग होता है मतलब "ट्रांजिट में TLS प्लस सर्वर पर AES-at-rest," जो प्रदाता के हाथ में कुंजियाँ छोड़ता है।

फाइल पेलोड के लिए सममित एन्क्रिप्शन

फाइलें सममित एल्गोरिदम से एन्क्रिप्ट होती हैं क्योंकि पब्लिक-की क्रिप्टो बल्क डेटा के लिए बहुत धीमा है। आधुनिक पसंद है AES-256-GCM, NIST SP 800-38D में परिभाषित, एक पास में गोपनीयता और प्रमाणित अखंडता दोनों प्रदान करता है। एक यादृच्छिक 256-बिट कुंजी और एक अद्वितीय 96-बिट नॉन्स (एक ही कुंजी के साथ कभी पुनः उपयोग नहीं) प्रत्येक फाइल की रक्षा करते हैं। XChaCha20-Poly1305, RFC 8439 और RFC 8103 में परिभाषित, एक विकल्प है जो पुराने ARM प्रोसेसर जैसे AES-NI हार्डवेयर त्वरण के बिना डिवाइस पर अक्सर तेज़ होता है। दोनों एक सिफरटेक्स्ट प्लस 128-बिट प्रमाणीकरण टैग उत्पन्न करते हैं जो किसी भी छेड़छाड़ का पता लगाता है।

पासवर्ड से कुंजी व्युत्पत्ति

जब E2EE पासवर्ड का उपयोग करता है, पासवर्ड खुद कभी एन्क्रिप्शन कुंजी नहीं होता। यह ब्रूट फोर्स के विरुद्ध बहुत कमज़ोर होगा। इसके बजाय, 600,000 या अधिक पुनरावृत्तियों के साथ PBKDF2-HMAC-SHA256 (OWASP 2025 मार्गदर्शन), m=19 MiB और t=2 के साथ Argon2id (RFC 9106), या scrypt (RFC 7914) जैसा कुंजी व्युत्पत्ति फ़ंक्शन पासवर्ड को एक मज़बूत कुंजी में विस्तारित करता है। एक यादृच्छिक 128-बिट या 256-बिट सॉल्ट रेनबो टेबल हमलों को रोकता है। परिणामी कुंजी फाइल को एन्क्रिप्ट करती है। सॉल्ट और पुनरावृत्ति गणना सिफरटेक्स्ट के साथ संग्रहीत होते हैं ताकि जब प्राप्तकर्ता पासवर्ड दर्ज करे तो कुंजी पुनर्निर्माण हो सके।

खाता-आधारित ट्रांसफर के लिए पब्लिक-की रैपिंग

जब प्राप्तकर्ताओं के पास प्रकाशित सार्वजनिक कुंजियों वाले खाते होते हैं, तो पासवर्ड प्रविष्टि की आवश्यकता नहीं होती। प्रेषक एक यादृच्छिक फाइल एन्क्रिप्शन कुंजी (FEK) उत्पन्न करता है, FEK का उपयोग करके AES-256-GCM से फाइल एन्क्रिप्ट करता है, फिर RFC 7748 के अनुसार X25519 ECDH कुंजी समझौते और RFC 5869 के अनुसार HKDF-SHA256 का उपयोग करके, या PKCS#1 v2.2 के अनुसार SHA-256 के साथ RSA-OAEP का उपयोग करके प्रत्येक प्राप्तकर्ता की सार्वजनिक कुंजी से FEK एन्क्रिप्ट करता है। रैप्ड FEK सिफरटेक्स्ट के बगल में रहता है। केवल प्राप्तकर्ता की निजी कुंजी धारक FEK अनरैप और फाइल डिक्रिप्ट कर सकता है। यह Signal और WhatsApp का संदेशों के लिए मॉडल है, फाइल पेलोड के लिए अनुकूलित।

URL फ्रैगमेंट का उपयोग करके लिंक-आधारित E2EE

ब्राउज़र-आधारित ट्रांसफर में एक चतुर तरकीब URL फ्रैगमेंट (#के बाद का भाग) में डिक्रिप्शन कुंजी संग्रहीत करना है। फ्रैगमेंट HTTP अनुरोध में कभी सर्वर को नहीं भेजे जाते। https://example.com/d/abc123#k=B9kZtR... जैसा लिंक सर्वर-साइड फाइल ID और क्लाइंट-साइड कुंजी ले जाता है। ब्राउज़र सिफरटेक्स्ट डाउनलोड करता है, JavaScript में फ्रैगमेंट पढ़ता है, और स्थानीय रूप से डिक्रिप्ट करता है। सेवा कभी कुंजी नहीं देखती। Firefox Send (अब बंद), Send via ownCloud, और इसी तरह की सेवाएं इस पैटर्न का उपयोग करती हैं। चेतावनी यह है कि यदि लिंक कहीं लीक हो जाता है — लॉग, स्क्रीनशॉट, WhatsApp Business प्रीव्यू — तो कुंजी उसके साथ लीक हो जाती है।

AEAD और हैश के साथ अखंडता

GCM और ChaCha20-Poly1305 जैसे Authenticated Encryption with Associated Data (AEAD) मोड छेड़छाड़ को रोकते हैं। सिफरटेक्स्ट में एक बिट पलटने से प्रमाणीकरण टैग सत्यापन विफल हो जाता है, और डिक्रिप्शन फ़ंक्शन गार्बेज प्लेनटेक्स्ट के बजाय एक त्रुटि लौटाता है। AEAD के ऊपर, कई कार्यान्वयन प्लेनटेक्स्ट का SHA-256 या BLAKE3 हैश एक मेनिफेस्ट एंट्री के रूप में कम्प्यूट करते हैं ताकि प्राप्तकर्ता डिक्रिप्शन के बाद सत्यापित कर सके कि फाइल प्रेषक के इरादे से मेल खाती है।

बड़ी फाइलों के लिए चंक्ड एन्क्रिप्शन

एक AES-GCM ऑपरेशन में 10 GB फाइल एन्क्रिप्ट करने के लिए 10 GB स्टेट रखना आवश्यक है, जो ब्राउज़र में अव्यावहारिक है। वास्तविक कार्यान्वयन फाइल को चंक में विभाजित करते हैं, आमतौर पर प्रत्येक 1 MB से 16 MB, और प्रत्येक चंक को एक व्युत्पन्न उपकुंजी और काउंटर-आधारित नॉन्स के साथ स्वतंत्र रूप से एन्क्रिप्ट करते हैं। age एन्क्रिप्शन टूल, age-encryption.org पर परिभाषित, ChaCha20-Poly1305 के साथ 64 KB चंक का उपयोग करता है। Magic Wormhole प्रोटोकॉल एक स्ट्रीमिंग निर्माण उपयोग करता है। चंक सीमाएं ब्राउज़रों को Streams API के माध्यम से डिक्रिप्शन स्ट्रीम करने देती हैं, पूरी फाइल पहुँचने से पहले डिस्क पर डाउनलोड शुरू करती हैं।

E2EE के ऊपर ट्रांसपोर्ट सुरक्षा

RFC 8446 में परिभाषित TLS 1.3 अभी भी E2EE के ऊपर मायने रखता है — पेलोड की गोपनीयता के लिए नहीं (पेलोड पहले से ही एन्क्रिप्टेड है) बल्कि मेटाडेटा, फाइल नाम, आकार, और टाइमिंग की गोपनीयता के लिए। X25519 जैसे फॉर्वर्ड-सीक्रेट कुंजी विनिमय के साथ TLS 1.3 का मतलब है कि यदि सर्वर की दीर्घकालिक कुंजी बाद में समझौता हो जाती है, रिकॉर्ड किए गए सत्रों को डिक्रिप्ट नहीं किया जा सकता। सर्टिफिकेट पिनिंग या HSTS प्रीलोड डाउनग्रेड हमलों को रोकता है। E2EE प्लस TLS 1.3 मिलकर फाइल सामग्री और कौन क्या किसको भेज रहा है इसके परिचालन पैटर्न दोनों की रक्षा करता है।

सामान्य कार्यान्वयन गलतियाँ

तीन गलतियाँ बार-बार होती हैं। पहला, AES-GCM में एक ही कुंजी के साथ नॉन्स का पुनः उपयोग गोपनीयता को विनाशकारी रूप से तोड़ता है; हमेशा एक ताज़ा यादृच्छिक नॉन्स या एक काउंटर उपयोग करें जो कभी दोहराता नहीं। दूसरा, libsodium, Web Crypto API (SubtleCrypto), या BoringSSL जैसी ऑडिटेड लाइब्रेरी के बजाय घरेलू रूटीन से क्रिप्टो लागू करना; टाइमिंग हमलों को रोकने के लिए कॉन्स्टेंट-टाइम ऑपरेशन महत्वपूर्ण हैं। तीसरा, सामग्री के साथ फाइल मेटाडेटा को प्रमाणित न करना; यदि प्रेषक की पहचान, फाइलनाम, या प्राप्तकर्ता सूची AAD (Associated Authenticated Data) में नहीं है, तो हमलावर बिना पता लगाए मेटाडेटा बदल सकता है। HexaTransfer जैसी सेवाएं समीक्षित पैटर्न के साथ क्लाइंट-साइड मानक Web Crypto प्राइमिटिव उपयोग करके इन्हें संबोधित करती हैं।

यह सत्यापित करना कि कोई सेवा वास्तव में E2EE करती है

मार्केटिंग दावों को संदेहपूर्वक पढ़ें। सच्चे E2EE का मतलब है कि प्रदाता न्यायालय आदेश द्वारा मजबूर होने पर भी फाइलें डिक्रिप्ट नहीं कर सकता। सटीक एल्गोरिदम (AES-256-GCM, X25519, HKDF, PBKDF2 पुनरावृत्ति गणना) का वर्णन करने वाले प्रकाशित तकनीकी दस्तावेज़ीकरण, ऑडिट योग्य ओपन-सोर्स क्लाइंट कोड, और एक थ्रेट मॉडल खोजें जो स्वीकार करता है कि E2EE क्या बचाव करता है और क्या नहीं। जो सेवाएं एन्क्रिप्टेड फाइलों पर सर्वर-साइड पासवर्ड रिकवरी प्रदान करती हैं वे सच्ची E2EE नहीं कर रही हैं — वे कुंजियाँ रखती हैं। "जीरो-नॉलेज" का दावा करने वाली सेवाओं को केवल नारे के बजाय क्रिप्टोग्राफिक प्रोटोकॉल विवरण के साथ इसे समर्थित करना चाहिए।

hexatransfer.com पर मुफ्त में आज़माएं — कोई खाता नहीं, 10 GB अधिकतम।