ज़ीरो-नॉलेज आर्किटेक्चर: सर्वर आपकी फ़ाइलें क्यों नहीं देख सकता

ज़ीरो-नॉलेज आर्किटेक्चर का मतलब है सर्विस प्रोवाइडर के पास तकनीकी रूप से आपकी फ़ाइलें पढ़ने की क्षमता नहीं है — encryption keys उनके सर्वर तक कभी नहीं पहुँचतीं, और कोई master key नहीं, कोई back door नहीं, "हम पर भरोसा करो" की ज़रूरत नहीं। आपका ब्राउज़र अपलोड से पहले स्थानीय रूप से generated key से AES-256-GCM से फ़ाइलें encrypt करता है, और वह key रिसीवर तक सिर्फ URL fragment के ज़रिए # के बाद पहुँचती है — जो ब्राउज़र सर्वर को कभी नहीं भेजते। वैध subpoena के तहत भी प्रोवाइडर सिर्फ ciphertext दे सकता है। यह Tresorit, Proton, SwissTransfer और HexaTransfer का model है — और यह "encrypted at rest" से गणितीय रूप से अलग है।

प्रमाण इस बात में है कि सर्वर क्या दे सकता है

ज़ीरो-नॉलेज का सबसे साफ़ टेस्ट: अगर compelled किया जाए तो कंपनी क्या दे सकती है? पारंपरिक cloud storage — Google Drive, Dropbox, OneDrive — में जवाब है: आपकी फ़ाइलें, plaintext में। Google की 2023 transparency report दिखाती है उन्होंने 83% US government data requests का अनुपालन किया, जहाँ कानूनी रूप से required था user content produce किया। यह Google की security की विफलता नहीं — यह आर्किटेक्चर का काम करना है।

ज़ीरो-नॉलेज के साथ, कंपनी दे सकती है:

• Encrypted फ़ाइल blobs (key के बिना बेकार)
• Account metadata (email, signup IP)
• अपलोड और डाउनलोड IP addresses, timestamps
• Payment information अगर applicable हो

वे filename, कंटेंट, रिसीवर की पहचान, या decryption keys produce नहीं कर सकते। इसलिए नहीं कि वे मना करते हैं — बल्कि इसलिए कि उनके पास है ही नहीं।

URL fragment trick, सटीक रूप से समझाई

तकनीकी core move URL fragment को covert key channel की तरह इस्तेमाल करना है। जब ब्राउज़र https://hexatransfer.com/d/xyz789#k=BASE64KEY request करता है, वह सर्वर को सिर्फ GET /d/xyz789 भेजता है। Fragment ब्राउज़र के address bar में रहता है। JavaScript फिर window.location.hash से key पढ़ता है और उसे crypto.subtle.decrypt() को pass करता है।

यह 2013 के आसपास Mega.nz ने pioneer किया था और Mozilla के Firefox Send से refined हुआ जब तक Mozilla ने 2020 में बंद नहीं किया। Pattern अब standard है। nginx या Caddy पर server-side logs — access logs सहित — fragment कभी capture नहीं करते क्योंकि HTTP RFC 3986 इसे client-side only define करता है।

एक प्रोवाइडर सैद्धांतिक रूप से client-side JavaScript के ज़रिए fragment log कर सकता है — इसीलिए ज़ीरो-नॉलेज सर्विसेज़ अपना client code inspection के लिए publish करती हैं और अक्सर इसे अलग origin से serve किए signed static assets के रूप में ship करती हैं।

यह "encrypted at rest" से कैसे अलग है

हर cloud प्रोवाइडर files को at rest encrypt करता है — यह basic requirement है और आमतौर पर SOC 2 Type II और ISO 27001 certifications के लिए ज़रूरी है। लेकिन provider-held keys के साथ "encrypted at rest" का मतलब है encryption चुराई गई disk वाले attackers के लिए invisible है और आपके लिए इस अर्थ में invisible है कि provider request पर अपने आप decrypt करता है।

ज़ीरो-नॉलेज key custody पलट देता है: आप key रखते हैं, provider ciphertext रखता है। Provider decrypt करके कुछ नहीं पाता क्योंकि कर ही नहीं सकता। यह तीन खास threats के तहत मायने रखता है:

1. Rogue employees. Database access वाला provider employee सिर्फ ciphertext देखता है।
2. Government requests. GDPR Article 48 और US CLOUD Act requests disclosure compel कर सकती हैं, लेकिन जो नहीं है वह नहीं दे सकते।
3. Server breaches. 2021 LastPass breach ने encrypted vaults expose किए; कमज़ोर master passwords अभी भी crack हुए, लेकिन ज़ीरो-नॉलेज design ने mass plaintext exposure रोका।

क्या encrypt होता है, क्या metadata है

Naive implementation फ़ाइल कंटेंट encrypt करता है लेकिन filename, sizes और folder structure visible छोड़ देता है। सच्चा ज़ीरो-नॉलेज filename भी encrypt करता है, आमतौर पर AES-GCM encryption से पहले file bytes में JSON header {"name": "Q4-financials.pdf", "type": "application/pdf"} prepend करके।

Metadata जिसे छुपाना मुश्किल है:

• फ़ाइल साइज़ — ciphertext length plaintext length approximate करती है। Fixed buckets (1 MB, 10 MB, 100 MB, 1 GB) पर padding यह obscure करती है लेकिन bandwidth waste होती है।
• अपलोड timing — timestamps को दूसरे data के साथ correlate करना अभी भी information leak कर सकता है।
• IP addresses — provider देखता है किसने अपलोड और डाउनलोड किया। अगर यह मायने रखता है तो Tor या trusted VPN के साथ pair करें।

Proton और Tresorit detailed metadata exposure matrices publish करते हैं। SwissTransfer और HexaTransfer simpler approach लेते हैं: minimal metadata, short retention (24 घंटे से 7 दिन), और free transfers के लिए कोई account linkage नहीं।

Authentication की चुनौती

ज़ीरो-नॉलेज एक challenge पैदा करता है: अगर सर्वर आपकी files decrypt नहीं कर सकता, तो अजनबियों को डाउनलोड से रोकने के लिए आपको authenticate कैसे करे? तीन आम patterns:

• Link-based auth. URL (और fragment) का possession authorization है। SwissTransfer, HexaTransfer, Tresorit Send इस्तेमाल करते हैं। सरल, accounts के बिना काम करता है।
• Password-protected links. URL fragment में salt होता है; actual key password से PBKDF2 के साथ derive होती है। सर्वर verifier (key का hash) store करता है ताकि गलत guesses को जल्दी reject करे।
• Account-bound zero-knowledge. Proton और Tresorit आपका master key login password से Argon2id के ज़रिए derive करते हैं, फिर उससे per-file keys unlock करते हैं जो encrypted रूप से सर्वर पर store हैं।

हर एक के tradeoffs हैं। Link-based सबसे simple लेकिन URL मिलने वाले किसी को भी key leak करता है। Password-protected second factor जोड़ता है। Account-bound के लिए client code पर भरोसा चाहिए कि master key exfiltrate न करे।

Implementation pitfalls जो ज़ीरो-नॉलेज तोड़ते हैं

कुछ real-world failures जानने योग्य हैं:

• Server-side file previews. अगर provider thumbnails generate करे या search के लिए text extract करे, तो उन्हें plaintext चाहिए। ज़ीरो-नॉलेज सर्विसेज़ encrypted content पर ये features offer नहीं कर सकतीं।
• Sync conflict resolution. Devices में फ़ाइल कंटेंट compare करना normally plaintext चाहिए। Syncthing और Cryptomator client-side diffs से यह संभालते हैं।
• Analytics SDKs. Google Analytics या Segment के third-party scripts client code में window.location.hash पढ़ सकते हैं। ज़ीरो-नॉलेज सर्विसेज़ या self-host analytics करती हैं या fragment access strip करती हैं।
• Password reset. अगर provider आपका password reset कर सकता है और फिर भी पुरानी files तक access दे सकता है, तो उन्हें recovery key रखनी होगी — जो ज़ीरो-नॉलेज तोड़ता है। Proton explicitly warn करता है कि password reset का मतलब encrypted data खोना है।

कौन वाकई ज़ीरो-नॉलेज deliver करता है

Third-party audits (Cure53, NCC Group, Trail of Bits) से verified credible ज़ीरो-नॉलेज claims वाली सर्विसेज़ की short list:

• Tresorit — Swiss, SOC 2 Type II, ज़ीरो-नॉलेज file sync और Send।
• Proton Drive — Swiss, Proton Mail cryptography model पर आधारित।
• SwissTransfer — Infomaniak द्वारा चलाया, optional E2EE के साथ free tier।
• Mega.nz — New Zealand, published cryptography whitepaper।
• HexaTransfer — browser-based, कोई account नहीं, 10 GB प्रति ट्रांसफर।

Encrypted लेकिन ज़ीरो-नॉलेज नहीं: Google Drive, Dropbox, OneDrive, Box, iCloud (Advanced Data Protection tier को छोड़कर), और WeTransfer standard tier।

व्यवहार में लागू करें

संवेदनशील फ़ाइलों के साथ किसी सर्विस पर भरोसा करने से पहले यह checklist चलाएं:

• क्या privacy policy कहती है provider आपकी files नहीं पढ़ सकता?
• क्या AES-256-GCM और KDF का नाम लेते हुए published security whitepaper है?
• क्या share URL में fragment है (# के बाद text)?
• क्या पिछले 24 महीनों के third-party audit reports हैं?
• क्या client code open source या कम से कम auditable है?

चार हाँ का मतलब ज़ीरो-नॉलेज सर्विस मिली। तीन या कम का मतलब provider आपकी files देख सकता है। DPDP Act 2023 के तहत भारत में व्यक्तिगत या संवेदनशील डेटा ट्रांसफर करते समय ज़ीरो-नॉलेज आर्किटेक्चर चुनना डेटा फ़िड्युशरी की ज़िम्मेदारी को पूरा करने में मदद करता है।

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