एंड-टू-एंड एन्क्रिप्शन क्या है: शुरुआती गाइड

एंड-टू-एंड एन्क्रिप्शन (E2EE) का मतलब है आपकी फ़ाइल आपके डिवाइस पर एक ऐसी key से scramble होती है जिसे केवल रिसीवर ही reconstruct कर सकता है। ट्रांसफर सर्विस ciphertext move करती है लेकिन decryption key कभी नहीं रखती, इसलिए कर्मचारी, हैकर और सरकारी subpoena — कोई भी कंटेंट नहीं पढ़ सकता। व्यावहारिक रूप से: आपका ब्राउज़र एक random 256-bit AES key बनाता है, फ़ाइल को लोकली encrypt करता है, ciphertext अपलोड करता है, और key को share link में # fragment के बाद रखता है — जो ब्राउज़र कभी सर्वर को नहीं भेजते। यही पूरी trick है, और यही असली प्राइवेसी को marketing copy से अलग करती है।

"एंड-टू-एंड" का असल मतलब

दो "end" आप और आपका रिसीवर हैं। बीच में सब कुछ — ISP router, CDN edge, ट्रांसफर कंपनी के सर्वर, रिसीवर का ISP — बीच में बैठा है। E2EE के साथ, उन बीच के हॉप को सिर्फ encrypted bytes दिखते हैं। इसकी तुलना केवल transport-layer encryption (TLS) से करें: TLS आपके ब्राउज़र से सर्वर तक डेटा protect करता है, फिर सर्वर decrypt करता है, plaintext store करता है, और रिसीवर के डाउनलोड पर दोबारा encrypt करता है। WeTransfer का standard tier इसी तरह काम करता है। कंपनी request पर (और US और EU कानून के तहत कभी-कभी) फ़ाइलें दे सकती है।

E2EE के साथ, अगर कोई prosecutor प्रोवाइडर को warrant दे भी दे, तो प्रोवाइडर के पास देने के लिए random-दिखने वाले bytes और IP logs के अलावा कुछ नहीं। यही गुण है जिसकी वजह से पत्रकार, वकील और डॉक्टर तेज़ी से E2EE पर जोर देते हैं।

सिर्फ TLS काफी क्यों नहीं है

TLS 1.3 जो करता है उसमें बेहतरीन है: coffee-shop attacker या rogue ISP को कनेक्शन snoop करने से रोकना। लेकिन TLS सर्वर पर terminate होती है। Encrypted tunnel खत्म होने के बाद सर्वर raw फ़ाइल process करता है। अगर वह सर्वर breach हो जाए — जैसा 2022 में Dropbox के साथ हुआ जब source code और कुछ customer data leak हुई — तो storage में पड़ी फ़ाइलों के लिए TLS ज़ीरो protection देती है।

E2EE एक दूसरी परत जोड़ती है जो सर्वर compromise से बचती है। फ़ाइल wire छूने से पहले encrypt होती है और रिसीवर का ब्राउज़र decrypt करे तब तक encrypted रहती है। पूरे database dump में भी सिर्फ ciphertext और metadata मिलता है।

Key exchange की समस्या, हल

E2EE का मुश्किल हिस्सा है key को रिसीवर तक पहुँचाना बिना सर्वर के देखे। आधुनिक browser-based सर्विसेज़ यह URL fragment trick से हल करती हैं। Share link ऐसा दिखता है:

https://hexatransfer.com/download/abc123#k=base64-encoded-256-bit-key

ब्राउज़र # के बाद सब कुछ client-side fragment मानते हैं। जब आप लिंक क्लिक करते हैं, सर्वर को HTTP request में सिर्फ /download/abc123 मिलता है — fragment कभी आपके ब्राउज़र से नहीं निकलता। JavaScript फिर fragment से key पढ़ता है, ciphertext fetch करता है, और Web Crypto API के crypto.subtle.decrypt() से लोकली decrypt करता है।

यह RSA key exchange या Diffie-Hellman से सरल है और ब्राउज़र वाले किसी के लिए काम करता है। Tradeoff: लिंक मिलने वाले किसी को भी फ़ाइल मिलती है, इसलिए लिंक अभी भी सुरक्षित चैनल से शेयर करना ज़रूरी है — Signal, व्यक्तिगत रूप से, encrypted email।

सर्वर क्या देखता है, क्या नहीं देख सकता

ठीक से implement E2EE के साथ, सर्वर logs में आमतौर पर होता है: random फ़ाइल ID, ciphertext साइज़, अपलोड IP, अपलोड timestamp, और deduplication के लिए ciphertext का SHA-256 hash। वह नहीं देखता: filename, फ़ाइल कंटेंट, रिसीवर की पहचान, या decryption key। Filename अक्सर कंटेंट के साथ encrypt होती है और ciphertext header के हिस्से के रूप में store होती है।

एक उपयोगी टेस्ट: प्रोवाइडर से पूछें warrant पर वे क्या देंगे। ईमानदार E2EE सर्विस कहेगी "encrypted blobs और IP logs।" अगर वे plaintext फ़ाइलें produce कर सकते हैं, तो एन्क्रिप्शन end-to-end नहीं है।

हुड के नीचे algorithms

असली E2EE स्टैक अच्छी तरह audited primitives की एक छोटी list पर converge करते हैं:

• AES-256-GCM bulk फ़ाइल encryption के लिए। GCM confidentiality और authentication दोनों देता है, इसलिए tampered ciphertext garbage produce करने की जगह decrypt करने में fail होती है।
• PBKDF2 कम से कम 100,000 iterations के साथ, या Argon2id, जब password protection जोड़ी जाए तो user passwords से keys derive करने के लिए।
• SHA-256 integrity hashes के लिए।
• TLS 1.3 outer transport के रूप में, क्योंकि belt-and-suspenders सस्ता है।

अभी भी AES-CBC without HMAC (malleable), MD5 या SHA-1 (broken), या PBKDF2 10,000 से कम iterations (आधुनिक GPU पर brute-forceable) वाली सर्विसेज़ से बचें।

फ़ाइल ट्रांसफर बनाम मेसेजिंग में E2EE

Signal ने Double Ratchet protocol से E2EE को चैट के लिए popular किया जो forward secrecy के लिए हर मेसेज के बाद keys rotate करता है। फ़ाइल ट्रांसफर को वह complexity नहीं चाहिए क्योंकि यह one-shot है — आप ongoing conversation नहीं कर रहे। प्रत्येक अपलोड के लिए fresh generate की गई per-file single symmetric key सरल भी है और audit करना भी आसान।

फ़ाइल ट्रांसफर को मेसेजिंग से अलग जो चाहिए: resumable chunked अपलोड (फ़ाइलें 10 GB हो सकती हैं), chunks में integrity verification, और ऐसे links जो रिसीवर के अकाउंट के बिना काम करें। Tresorit, Proton Drive, SwissTransfer और HexaTransfer सभी इस दृष्टिकोण से minor variations के साथ काम करते हैं।

सर्विस वाकई end-to-end है या नहीं जाँचें

भरोसा करने से पहले चार व्यावहारिक टेस्ट:

1. एक छोटी फ़ाइल अपलोड करते समय DevTools → Network खोलें। अगर request body में plaintext दिखे, तो client-side encrypted नहीं है।
2. URL fragment में key ढूंढें (# के बाद)। Fragment key न हो तो आमतौर पर सर्वर key रखता है।
3. Privacy policy में "we cannot access your files" के साथ technical explanation पढ़ें।
4. क्लाइंट कोड auditable हो या नहीं देखें — open source या कम से कम documented। E2EE claims वाले closed binary yellow flag हैं।

चारों pass करने वाली सर्विसेज़: SwissTransfer (client-side encryption tier), Tresorit Send, Proton Drive share links, और HexaTransfer।

E2EE किससे protect नहीं करता

E2EE जादू नहीं है। यह protect नहीं करता:

• Compromised endpoint से। अगर लैपटॉप पर malware है, तो attacker encryption से पहले फ़ाइलें पढ़ता है।
• Leaked share links से। Link मिलने वाला कोई भी download और decrypt कर सकता है।
• Password-protected transfers पर कमज़ोर passwords से। PBKDF2 brute force धीमा करता है, लेकिन "summer2024" अभी भी सेकंडों में गिर जाता है।
• Metadata correlation से। Timestamp, फ़ाइल साइज़ और IP addresses अभी भी कहानी बता सकते हैं।

E2EE को expiring links (24 घंटे sensible default है), download limits (अक्सर 1–10 downloads), और संवेदनशील transfers के लिए strong passwords के साथ pair करें।

इसे उपयोग में लाएं

एक quick sanity check: 5 MB test फ़ाइल अपलोड करें, share link को private window में fragment के बिना खोलें (# के बाद सब delete करें), और download का प्रयास करें। असली E2EE सर्विस decrypt करने में fail होगी। अगर फ़ाइल फिर भी खुले, तो सर्वर ने key पहले से रखी थी। DPDP Act 2023 के तहत भारत में personal data transfer करने वालों के लिए यह sanity check खास अहमियत रखता है — E2EE सुनिश्चित करता है कि सिर्फ सेंडर और रिसीवर ही फ़ाइल देख सकें।

hexatransfer.com पर आज़माएं — मुफ्त, बिना अकाउंट, 10 GB तक।