सामग्री पर जाएँ
HexaTransfer
ब्लॉग पर वापस
एन्क्रिप्शन और सुरक्षा

एन्क्रिप्शन कीज़ कैसे काम करती हैं: फ़ाइल सुरक्षा की नींव

सरल भाषा में समझें एन्क्रिप्शन कीज़ कैसे काम करती हैं। की जेनरेशन, एक्सचेंज और मैनेजमेंट के बारे में जानें।

एन्क्रिप्शन की एक random bits की string है जो डेटा को lock और unlock करती है। आधुनिक फ़ाइल ट्रांसफर में यह आमतौर पर 256-bit AES की होती है — एक cryptographically secure random number generator (CSPRNG) से बनाए गए 32 bytes का random डेटा। वही algorithm जो एक 10 GB वीडियो को ciphertext में बदलती है, उसे केवल उसी exact की से वापस decode कर सकती है। की की सुरक्षा ही वह बिंदु है जहाँ encryption सफल या विफल होती है: एक perfect AES-256 cipher बेकार है अगर की कमज़ोर, अनुमानित या उजागर हो। यह लेख बताता है कि HexaTransfer, Tresorit और Proton Drive जैसी सेवाओं में कीज़ कैसे बनती, शेयर होती, स्टोर होती और नष्ट होती हैं।

कीज़ बस random नंबर हैं

एक 256-bit की में 32 bytes होते हैं। ब्राउज़र में generate की जाए तो यह कुछ ऐसी दिखती है:

const key = crypto.getRandomValues(new Uint8Array(32));
// Uint8Array(32) [183, 45, 201, 77, ...]

इसे "की" बनाता है वह algorithm जो इसे use करती है। AES-256-GCM एक 256-bit की लेती है, key schedule के ज़रिये उसे 15 round keys में expand करती है, और 14 rounds में 128-bit blocks को scramble करती है। गणित को इससे फ़र्क नहीं कि bits कहाँ से आए — बस यह ज़रूरी है कि वे secret और unpredictable हों।

"Unpredictable" होना कठिन हिस्सा है। अगर attacker आपके RNG की state का अनुमान लगा सके, तो वह की फिर से generate कर सकता है। 2006 का Debian OpenSSL bug दो साल तक की entropy को 15 bits तक घटाए रहा — यह randomness के विफल होने का textbook उदाहरण है।

Cryptographically secure randomness

ब्राउज़र crypto.getRandomValues() प्रदान करते हैं जो OS के CSPRNG से pull करता है: Linux पर /dev/urandom, Windows पर BCryptGenRandom, macOS पर SecRandomCopyBytes। ये कई entropy sources — interrupt timings, disk seek times, Intel के RDRAND जैसे hardware RNG chips — को mix करते हैं।

कीज़ के लिए Math.random() का इस्तेमाल न करें। यह एक predictable Mersenne Twister है और इसकी state कुछ outputs से recover की जा सकती है।

Server-side में Node.js का crypto.randomBytes() और Python का secrets.token_bytes() OS CSPRNG को wrap करते हैं और safe हैं। NIST SP 800-90A और SP 800-90B standards CSPRNG requirements define करते हैं; Linux kernel 5.17+ BLAKE2s-based design उपयोग करता है जो इन मानकों को पूरा करता है।

Symmetric keys: एक की, दो दिशाएं

AES जैसे symmetric algorithms encrypt और decrypt दोनों के लिए एक ही की उपयोग करते हैं। की size के विकल्प:

  • 128-bit — 2^128 संभावित values, अधिकांश उद्देश्यों के लिए सुरक्षित, NSA CNSSP-15 द्वारा SECRET के लिए approved।
  • 192-bit — दुर्लभ, कुछ सरकारी contexts में उपयोग।
  • 256-bit — 2^256 values, TOP SECRET के लिए approved, फ़ाइल ट्रांसफर सेवाओं का वर्तमान default।

की size दोगुनी करने से brute-force कठिनाई दोगुनी नहीं होती — यह squared होती है। 2^128 पहले से ही पहुँच से बाहर है (ब्रह्मांड की आयु गुणा 10 अरब, पृथ्वी के सभी कंप्यूटरों के साथ)। 256-bit quantum computers के खिलाफ एक hedge है, जहाँ Grover's algorithm symmetric key strength को effectively आधा कर देता है।

Symmetric keys की कठिन समस्या: बिना किसी के intercept किए दोनों पक्षों को एक ही की कैसे पहुँचाई जाए।

Asymmetric keys: जोड़ी की तरकीब

Public-key cryptography key distribution को solve करती है। प्रत्येक पक्ष गणितीय रूप से linked key pair generate करता है: एक public key (खुले तौर पर share की जाती है) और एक private key (गुप्त रखी जाती है)। Public key से encrypt की गई किसी भी चीज़ को केवल private key से decrypt किया जा सकता है।

सामान्य asymmetric key types:

  • RSA-2048 — 2048-bit modulus, व्यापक support, धीमा। TLS certificates में use।
  • RSA-4096 — मज़बूत, और भी धीमा।
  • Curve25519 (X25519) — 256-bit elliptic curve key, तेज़, Signal और WireGuard द्वारा use।
  • Ed25519 — 256-bit signing key, SSH और Git commit signing द्वारा use।

Private key अकेले algorithm के अनुसार 32–512 bytes होती है। RSA private keys बड़ी होती हैं क्योंकि उनमें multiple primes होते हैं; Curve25519 private keys केवल 32 random bytes होती हैं।

Hybrid: वास्तविक systems के लिए दोनों को combine करें

कोई भी व्यावहारिक system RSA से सीधे बड़ी फ़ाइलें encrypt नहीं करता। इसके बजाय, हर real protocol — TLS, PGP, Age, Signal, हर serious file transfer service — hybrid encryption use करती है:

  1. एक random 256-bit AES की ("session key" या "file key") generate करें।
  2. AES-256-GCM से फ़ाइल encrypt करें।
  3. Session key को recipient की public key से encrypt करें।
  4. दोनों भेजें।

Recipient अपनी private key से session key decrypt करता है, फिर उससे फ़ाइल decrypt करता है। आपको symmetric encryption की speed और asymmetric के key-distribution की सुविधा दोनों मिलती है।

Browser-based file transfer में, "public key" को अक्सर URL fragment से बदल दिया जाता है: sender एक session key generate करता है, उसे # के बाद URL में embed करता है, और recipient का browser इसे locally पढ़ता है। सरल, और recipients को key pair की ज़रूरत नहीं।

Passwords से keys derive करना

Users passwords टाइप करते हैं; algorithms को uniform random bits चाहिए। एक key derivation function (KDF) उन्हें जोड़ती है:

  • PBKDF2-HMAC-SHA-256 — hash function iterate करता है। OWASP 2023 में 600,000 iterations recommended। Web Crypto API में उपलब्ध।
  • scrypt — memory-hard, GPU attacks को resist करती है। Parameters: N=2^17, r=8, p=1
  • Argon2id — वर्तमान best practice, 2015 Password Hashing Competition की विजेता। Parameters: memory=64 MB, iterations=3, parallelism=4

KDF एक salt (random, ciphertext के साथ store) और work factor (iterations) जोड़ती है brute force को धीमा करने के लिए। एक 12-character random password को Argon2id के साथ 64 MB memory से exhaust करने में GPU farm को हज़ारों साल लगेंगे। summer2024 जैसा weak password KDF के बावजूद सेकंडों में fall होगा — KDF वह entropy नहीं जोड़ सकती जो वहाँ थी ही नहीं।

Key storage: कीज़ कहाँ रहती हैं?

कीज़ को कहीं न कहीं exist करना पड़ता है, और वह स्थान एक security-critical निर्णय है:

  • Browser memory (session-only). Ephemeral file transfers के लिए default। की page load के भीतर generate, use और discard हो जाती है।
  • URL fragment. Link के ज़रिये share, recipient के browser history में store। Limited lifetime ज़रूरी है।
  • Local storage / IndexedDB. Persistent लेकिन origin पर किसी भी JavaScript के लिए accessible। किसी दूसरी की से encrypt न हो तो risky।
  • OS keychain — macOS Keychain, Windows DPAPI, Linux libsecret। कुछ platforms पर hardware-backed।
  • Hardware Security Module (HSM) — YubiKey, cloud HSM (AWS CloudHSM, Azure Dedicated HSM)। कीज़ hardware नहीं छोड़तीं।
  • Key Management Service (KMS) — AWS KMS, Google Cloud KMS, HashiCorp Vault। Centralized, auditable, लगभग $1/key/month।

Zero-knowledge file transfer के लिए, की URL fragment और sender के browser में रहती है। Server इसे कभी store नहीं करता।

Key rotation और destruction

लंबे समय तक जीवित कीज़ risk बढ़ाती हैं। Best practice है rotation:

  • TLS certificates: 90-day rotation (Let's Encrypt default), 2020 से public CAs के लिए 398-day maximum।
  • Data encryption keys: आमतौर पर compliant systems में हर 90 days से 1 साल में rotate होती हैं (PCI DSS 4.0 Requirement 3.6)।
  • Master keys: सालाना या personnel changes पर rotate।

Destruction भी महत्वपूर्ण है। Disk से key files को सिर्फ delete करना पर्याप्त नहीं — SSDs wear-leveling areas में डेटा retain कर सकते हैं। Secure destruction के लिए overwriting या dedicated HSM delete commands ज़रूरी हैं। Cryptographic erasure — की को फेंकना ताकि encrypted data permanently unreadable हो जाए — बल्क डेटा के लिए अक्सर सबसे clean approach है।

File transfer services आमतौर पर per-file keys use करती हैं जो केवल transfer के जीवनकाल (24 घंटे से 7 दिन) तक exist करती हैं और expiration पर ciphertext के साथ discard हो जाती हैं।

Weak key practices पहचानना

तीन common failure modes जिन पर ध्यान देना चाहिए:

  • Client code में hard-coded keys. अगर की हर user के लिए एक जैसी है, तो यह की नहीं — यह obfuscation है।
  • Ciphertext के साथ एक ही server या database पर store कीज़। Breach दोनों उजागर कर देता है।
  • कोई key rotation नहीं। दशक-पुरानी encryption keys वाले legacy systems में दशक भर का accumulated breach risk होता है।

एक reputable service cryptographic whitepaper publish करती है जो key generation, storage, rotation और destruction cover करती है — और Cure53 या Trail of Bits जैसी firms द्वारा third-party audits submit करती है।

परिप्रेक्ष्य में रखें

Sensitive file sharing के लिए: एक ऐसी service चुनें जो crypto.getRandomValues() के ज़रिये client-side 256-bit keys generate करती हो, उन्हें केवल URL fragment में embed करती हो (server को कभी नहीं भेजती), PBKDF2 या Argon2id के ज़रिये password-derived keys support करती हो, और 24 घंटों में key और ciphertext दोनों auto-expire करती हो।

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

एंड-टू-एंड एन्क्रिप्शन के साथ बड़ी फ़ाइलें सुरक्षित रूप से भेजें

एंड-टू-एंड एन्क्रिप्शन के साथ 10 GB तक की फ़ाइलें मुफ़्त में ट्रांसफ़र करें। अकाउंट की आवश्यकता नहीं। अपलोड से पहले आपकी फ़ाइलें ब्राउज़र में एन्क्रिप्ट की जाती हैं — कोई और उन्हें पढ़ नहीं सकता।

फ़ाइल भेजें