क्लाइंट-साइड एन्क्रिप्शन क्या है? आपका ब्राउज़र करता है काम

Client-side encryption का मतलब है आपका browser या app network पर कुछ जाने से पहले ही device पर files encrypt कर देता है। Server सिर्फ ciphertext प्राप्त करता है — AES-256-GCM output जो random noise से अलग नहीं दिखता — और decryption key कभी client से नहीं निकलती। यह server-side encryption का उल्टा है, जहां provider keys रखता है और technically आपकी files पढ़ सकता है। Web Crypto API (window.crypto.subtle) किसी भी modern browser में plugins के बिना यह possible बनाता है, AES-NI hardware पर roughly 2-3 GB/s पर चलता है। HexaTransfer, SwissTransfer, Tresorit Send और Proton Drive यह model इस्तेमाल करते हैं ताकि files private रहें, यहां तक कि अगर सर्विस खुद compromise हो जाए।

Browser का cryptographic engine के रूप में उभरना

पांच साल पहले real encryption के लिए desktop app install करना या command line पर PGP इस्तेमाल करना पड़ता था। W3C ने 2017 में standardize किया Web Crypto API ने यह बदल दिया। यह AES-GCM, RSA-OAEP, ECDH, HMAC, PBKDF2 और SHA-256 को किसी भी mainstream browser में JavaScript को directly expose करता है — Chrome, Firefox, Safari, Edge।

Performance अब blocker नहीं है। Intel AES-NI instructions AES-256-GCM के लिए 3-5 GB/s per core hit करते हैं। Apple M-series और Qualcomm Snapdragon chips पर ARM Cryptography Extensions similar throughput देते हैं। Browser में 1 GB file encrypt करने में mid-range laptop पर roughly 300-500 ms लगते हैं।

बाकी challenge है browser memory से बड़ी files handle करना। Streams API और ReadableStream code को 4 MB chunks में files process करने देते हैं, हर chunk को unique counter-mode IV से independently encrypt करते हुए। इसी तरह services ceiling 10 GB या उससे ज़्यादा तक push करती हैं।

Minimal client-side encryption flow

Typical browser-based service यह sequence चलाती है:

// 1. Random 256-bit AES key generate करें
const key = await crypto.subtle.generateKey(
  { name: "AES-GCM", length: 256 }, true, ["encrypt", "decrypt"]
);

// 2. File chunks में पढ़ें
const file = fileInput.files[0];
const chunkSize = 4 * 1024 * 1024;

// 3. हर chunk को unique 12-byte IV से encrypt करें
for (let offset = 0; offset < file.size; offset += chunkSize) {
  const chunk = file.slice(offset, offset + chunkSize);
  const iv = crypto.getRandomValues(new Uint8Array(12));
  const ciphertext = await crypto.subtle.encrypt(
    { name: "AES-GCM", iv }, key, await chunk.arrayBuffer()
  );
  // 4. [iv || ciphertext] server पर upload करें
}

// 5. Key export करें और share URL fragment में embed करें
const keyBytes = await crypto.subtle.exportKey("raw", key);
const shareUrl = `https://example.com/d/${fileId}#k=${base64url(keyBytes)}`;

Server को random-looking bytes, एक file ID, और कुछ नहीं दिखता। Key सिर्फ user के browser memory और URL fragment में exist करती है।

Server-side encryption से यह क्यों बेहतर है?

Server-side encryption का मतलब है provider request पर decrypt करता है — thumbnails generate करने के लिए, virus scans चलाने के लिए, search queries process करने के लिए, या legal demands पर। Apple ने 2023 में disclose किया कि iCloud backups (जो Advanced Data Protection launch से पहले end-to-end encrypted नहीं थे) Apple और US law enforcement को valid requests पर accessible थे।

Client-side यह flip करता है। क्योंकि key provider तक कभी नहीं पहुंचती:

Rogue employees कुछ नहीं देखते। Database access वाले engineer को ciphertext मिलता है।
Subpoenas से ciphertext मिलता है। Provider warrants पर encrypted blob दे सकता है, जो key के बिना बेकार है।
Breaches ciphertext leak करते हैं। 2021 LastPass incident ने यह prove किया — stolen vaults encrypted थे, सिर्फ weak master passwords वालों को real risk था।
Provider outages data compromise नहीं करते। Company collapse भी हो जाए, आपके पास key का local copy (URL) file decrypt करता है।

Server अभी भी क्या देख सकता है?

Client-side encryption file contents protect करती है, सब कुछ नहीं। Server typically observe करता है:

File size — ciphertext length plaintext length approximate करती है (AES-GCM हर encryption में 16 bytes overhead जोड़ता है, plus 12-byte IV)।
Upload और download IP addresses timestamps के साथ।
Session metadata TLS handshakes से, client के TLS fingerprint सहित।
Encrypted filenames — जब तक filenames encrypted payload में include न हों, वे leak हो सकते हैं।

अच्छी client-side services filenames को ciphertext header के हिस्से के रूप में encrypt करती हैं और size obscure करने के लिए bucket sizes (1 MB, 10 MB, 100 MB) में pad करती हैं।

Password-protected client-side encryption

कई services users को URL fragment के ऊपर password add करने देती हैं। Flow:

Browser एक random 128-bit salt generate करता है और PBKDF2-HMAC-SHA-256 के 600,000 iterations (OWASP 2023 recommendation) या Argon2id के साथ memory=64 MB, iterations=3 से key derive करता है।
File derived key से encrypt होती है।
Salt URL fragment में जाता है; password out-of-band communicate होता है।
Recipient password type करता है, जो locally key re-derive करता है।

यह single-channel share (URL काफी है) को two-factor बनाता है: attacker को link और password दोनों चाहिए। PBKDF2 के 600,000 iterations offline brute force cost roughly 10 seconds per guess on modern GPU पर बनाते हैं, इसलिए passwords को 40+ bits of entropy चाहिए — diverse alphabet से 10+ characters।

Trust shift: service से client code तक

Client-side encryption trust boundary move करती है। पहले आप service पर trust करते थे कि वह plaintext अच्छी तरह handle करे। अब आप उस JavaScript पर trust करते हैं जो service हर page load पर आपके browser को ship करती है। Malicious update encryption से पहले या दौरान key exfiltrate कर सकता है।

तीन mitigations exist करते हैं, rigor में varying:

Subresource Integrity (SRI) script tags के लिए यह ensure करती है कि JS hash एक known value match करे।
Code audits Cure53, NCC Group, या Trail of Bits जैसी firms से encryption logic verify करती हैं।
Reproducible builds independent parties को confirm करने देते हैं कि shipped code published source match करता है।
Content Security Policy (CSP) headers third-party scripts block करते हैं जो encryption के साथ tamper कर सकते हैं।

Proton Mail's pmcrypto और कुछ Electron-based clients का strictest approach signed binaries ship करना है। Browser-based services कुछ rigor zero-install convenience के लिए trade करती हैं।

Client-side कहां shine करती है?

कुछ scenarios जहां client-side encryption slightly slower first load के लायक है:

Legal और medical documents। HIPAA 45 CFR § 164.312 और attorney-client privilege दोनों provider-blind architectures से strongly benefit करते हैं। भारत में वकीलों और डॉक्टरों के लिए client-side encryption professional duty का हिस्सा बन सकती है।
Journalism और source protection। Unredacted documents भेजना जहां metadata exposure भी risk carry करती है।
Corporate IP। Board packs, financial models, M&A materials जहां file transfer provider पर insider threats realistic concern हैं।
Personal records। Tax documents, passports, medical tests — files जो किसी provider breach headline में देखना uncomfortable हो।

Low-sensitivity files के लिए (meeting photo, recipe) traditional server-side encryption fine है।

Real client-side encryption कैसे पहचानें?

चार signs कि service actually client-side encryption करती है:

URL fragments key carry करते हैं। Share URL में # के बाद text है जो base64-encoded random bytes जैसा दिखता है।
Uploads ciphertext हैं। Upload के दौरान DevTools → Network खोलें; request body random bytes जैसी दिखनी चाहिए, आपका filename नहीं।
बड़ी files भी fast काम करती हैं। True client-side flow chunks stream करता है; यह server-side encryption gateway पर re-upload नहीं करता।
Privacy policy कहती है "हम आपकी files decrypt नहीं कर सकते।" Technical whitepaper के साथ, सिर्फ marketing copy नहीं।

Pass करने वाली services: SwissTransfer का E2EE tier, Tresorit Send, Proton Drive shared links, Mega.nz, और HexaTransfer। नहीं करने वाली: WeTransfer (standard), Google Drive, Dropbox share links।

आज use करें

अगर client-side encryption आज़माना है, तो file upload करते हुए DevTools खोलें और Network tab देखें। Server को encrypted blob जाना चाहिए और आपके URL bar में key होनी चाहिए जो किसी request में कभी नहीं दिखती। यही पूरा promise है।

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