सादा टेक्स्ट

Web Crypto API के माध्यम से AES-256-GCM का उपयोग करता है। प्रत्येक एन्क्रिप्शन पर एक यादृच्छिक 96-बिट IV और 128-बिट सॉल्ट जनरेट होता है।

कैसे उपयोग करें

1. एन्क्रिप्ट या डिक्रिप्ट मोड चुनें।
2. अपना टेक्स्ट और एक पासवर्ड दर्ज करें।
3. क्रिया बटन पर क्लिक करें · परिणाम नीचे प्रकट होता है।
4. डिक्रिप्ट करने के लिए, एन्क्रिप्टेड आउटपुट पेस्ट करें और वही पासवर्ड उपयोग करें।

अक्सर पूछे जाने वाले प्रश्न

क्या यह एन्क्रिप्शन सुरक्षित है?

हाँ। AES-256-GCM सैन्य-ग्रेड एन्क्रिप्शन है। PBKDF2 कुंजी व्युत्पत्ति (100k पुनरावृत्तियाँ) के साथ, यह मज़बूत सुरक्षा प्रदान करता है।

क्या आप मेरा पासवर्ड पुनर्प्राप्त कर सकते हैं?

नहीं। सब कुछ आपके ब्राउज़र में चलता है। हम कभी आपका टेक्स्ट या पासवर्ड नहीं देखते। यदि आप अपना पासवर्ड खो देते हैं, तो टेक्स्ट वापस नहीं मिलेगा।

आउटपुट का प्रारूप क्या है?

एन्क्रिप्टेड आउटपुट Base64 स्ट्रिंग है जिसमें सॉल्ट, IV और सिफ़र टेक्स्ट शामिल है। डिक्रिप्ट करने के लिए इसे बस टूल में वापस पेस्ट करें।

Encrypt क्लिक करने पर वास्तव में क्या होता है

AES जैसे symmetric ciphers encrypt और decrypt करने के लिए एक ही key का उपयोग करते हैं। इसका मतलब है कि key रखने वाला कोई भी data को lock और unlock दोनों कर सकता है, इसलिए इसके उपयोग की पूरी चुनौती एक ही प्रश्न पर सिमट जाती है: sender और recipient बिना leak किए key कैसे share करें? इस tool का जवाब है «आप यह खुद संभालें», एक separate trusted channel के माध्यम से password पर agree करें, फिर आप दोनों वही string यहां paste करें।

पर्दे के पीछे tool browser के native Web Crypto API के माध्यम से चार steps चलाता है:

1. अपने password को key में stretch करें। Password एक short, low-entropy string है; AES-256 key 32 bytes of high-entropy random data है। Tool आपके password को PBKDF2-HMAC-SHA-256 with 100,000 iterations (RFC 8018 में specified) plus एक 128-bit random salt के माध्यम से feed करता है। Salt हर encryption को एक अलग key produce करने देता है, भले ही आप password reuse करें, rainbow-table attacks को समाप्त करते हुए। Iteration count per-attempt basis पर brute-force guessing को slow करता है।
2. एक fresh nonce generate करें। एक 96-bit random IV (AES-GCM के लिए NIST-recommended length) crypto.getRandomValues के माध्यम से create किया जाता है: वही cryptographically secure randomness source जो browser TLS के लिए उपयोग करता है।
3. AES-256-GCM से encrypt करें। Plaintext को UTF-8 bytes के रूप में encode किया जाता है और AES-256 in Galois/Counter Mode के माध्यम से पास किया जाता है, जो ciphertext plus एक 128-bit authentication tag produce करता है।
4. Package करें और Base64-encode करें। Salt, IV, और ciphertext+tag को एक single binary blob में concatenate किया जाता है और Base64-encode किया जाता है ताकि यह email, chat, या कहीं भी जो ASCII expect करता है वहां safely travel करे।

AES-256-GCM specifically क्यों

AES (Advanced Encryption Standard) वह symmetric cipher है जिसे NIST ने 2000 में 15 candidates की public competition से चुना। Winning design Belgian cryptographers Joan Daemen और Vincent Rijmen का Rijndael था, जिसे 26 November 2001 को FIPS PUB 197 के रूप में formalize किया गया। NIST तीन key sizes (128, 192, 256 bits) को approve करता है और NSA तीनों को SECRET data के लिए approve करता है, AES-256 को TOP SECRET के लिए भी। दो दशकों से अधिक की public scrutiny के बाद भी ठीक से implemented AES के विरुद्ध कोई practical attack नहीं है, cipher itself essentially unbreakable है, इसलिए security argument पूरी तरह key management और password strength पर shift हो जाता है।

AES जैसा block cipher केवल एक fixed-size 128-bit block encrypt करता है, इसलिए किसी भी real message को blocks को glue करने के लिए एक mode of operation की जरूरत होती है। Mode cipher जितना ही important है। कुख्यात पुराना default, ECB: प्रत्येक block को independently encrypt करता है, जो patterns leak करता है; encryption के बाद भी recognizable Tux की प्रसिद्ध «ECB Penguin» image standard cautionary illustration है। कई पुराने online «AES» tools अभी भी ECB expose करते हैं; यह नहीं करता।

GCM (Galois/Counter Mode), McGrew और Viega द्वारा designed और NIST द्वारा SP 800-38D (November 2007) में standardize, counter-mode encryption को Galois-field authentication tag के साथ combine करता है। यह एक AEAD mode (Authenticated Encryption with Associated Data) है, जिसका मतलब है कि यह एक ही operation में confidentiality और integrity प्रदान करता है। यदि encrypted output का एक single byte flip हो जाए, तो decryption garbled plaintext return करने की जगह error raise करता है। Same mode TLS 1.2 और TLS 1.3 उपयोग करते हैं। यह genuinely modern internet cryptography का workhorse mode है।

Password एक key नहीं है

AES-256 key 32 bytes of uniform randomness है। User का password (एक strong भी) short है, mostly printable ASCII है, और dictionary patterns के आसपास cluster करता है। आप बिना help के password को directly AES में feed नहीं कर सकते। वह help है एक password-based key derivation function (KDF)। PBKDF2, scrypt, और Argon2 वे तीन हैं जो आप modern code में देखेंगे:

• PBKDF2 (RFC 8018), original। एक HMAC pseudo-random function को कई बार iterate करता है। CPU पर fast, लेकिन memory-hard नहीं: GPUs और ASICs PBKDF2 hashes को उससे कहीं तेजी से crack करते हैं जितना iteration count एक normal computer पर सुझाव देता है। यह tool PBKDF2 का उपयोग करता है क्योंकि यह Web Crypto API द्वारा natively expose किया जाने वाला एकमात्र password KDF है, Argon2 और scrypt को extra JavaScript या WebAssembly shipping की जरूरत होगी।
• scrypt (RFC 7914, 2016, by Colin Percival)) ने memory-hardness जोड़ी: attacker को per guess RAM का एक large block allocate करने के लिए मजबूर करता है, cheap parallel hardware को defeat करते हुए।
• Argon2id (RFC 9106, 2021), 2015 Password Hashing Competition का winner; OWASP की current first-choice recommendation। Memory-hard, side-channel resistant।

ईमानदार सावधानी: 100,000 PBKDF2 iterations original RFC floor of 1,000 से काफी ऊपर है, लेकिन PBKDF2-SHA-256 के लिए OWASP के current 2026 guidance of 600,000 से नीचे है। Trade-off है slow phones पर encryption time, 600,000 iterations पर, budget Android device पर key derive करना एक noticeable pause add करने लगता है। High-stakes long-term secrets के लिए, compensate करने के लिए एक लंबा password चुनें, या एक dedicated password manager का उपयोग करें जो typically stronger parameters के साथ Argon2id उपयोग करता है।

Salt और IV, वे समान दिखते हैं, वे अलग-अलग काम करते हैं

• Salt key derivation का input है। यह password→key mapping को प्रत्येक encryption के लिए unique बनाता है, इसलिए एक stolen ciphertext को common-password keys की precomputed table का उपयोग करके crack नहीं किया जा सकता। Salt को secret होने की जरूरत नहीं, बस unique और unpredictable।
• IV / nonce cipher mode का input है। AES-GCM के लिए specifically, यह 96-bit counter starting point है। यह per (key, message) pair unique होना चाहिए; GCM में एक को reuse करना catastrophic है, यह attacker को GHASH key recover करने और arbitrary ciphertexts forge करने देता है। Tool हर encryption पर crypto.getRandomValues से एक fresh random IV generate करता है, जो उस risk से बचता है।

इसे कब उपयोग करें, और कब नहीं

सही tool कब है:

• आपको एक single secret message किसी untrusted channel (email, Slack, SMS, एक notes app) के माध्यम से share करना है और आपके पास एक separate trusted channel (एक phone call, face-to-face meeting, एक Signal chat) है जहां आप password hand over कर सकते हैं।
• आप किसी cloud document या note-taking app में paste करने से पहले locally एक snippet encrypt करना चाहते हैं, ताकि provider के breach होने पर भी contents अपठनीय हों।
• आपको किसी partner के साथ workflow से जुड़ा एक «sealed envelope» चाहिए जिसने verbally password पर agree किया हो।

गलत tool कब है:

• आप और आपके recipient के पास कोई pre-shared secret नहीं है और कोई out-of-band channel नहीं है। Ciphertext के same channel से password भेजना निरर्थक है, जो कोई भी ciphertext पढ़ सकता है वह password भी पढ़ सकता है। यह classic chicken-and-egg key-distribution problem है जिसे public-key crypto हल करने के लिए exists है।
• आपको forward secrecy की जरूरत है। Signal और TLS 1.3 हर session के लिए एक अलग ephemeral key produce करते हैं, इसलिए आज का leak past messages expose नहीं करता। एक single fixed password इसके विपरीत property देता है: password सीखने वाला कोई भी हर उस message को decrypt कर सकता है जिसे आपने उससे encrypt किया।
• आपको prove करना है कि किसने कुछ encrypt किया। Shared password के साथ AES password का possession prove करता है, authorship नहीं। Digital signatures के लिए PGP, age, या S/MIME का उपयोग करें।
• आप scale पर या कई recipients के लिए encrypt कर रहे हैं। हर recipient को एक separately shared password की जरूरत है और rotation दर्दनाक है। Asymmetric tools (age, PGP) और Signal-style key servers इसे बेहतर handle करते हैं।

एक उपयोगी mental model: password के साथ AES एक luggage padlock का digital equivalent है, combination share करने के लिए phone call के साथ combined। यह perfectly काम करता है यदि आप phone call पर trust कर सकते हैं। यह Signal जैसे end-to-end-encrypted messaging का substitute नहीं है, जो key exchange को automate करता है और अपने Double Ratchet protocol के माध्यम से forward secrecy प्रदान करता है।

Password के लिए «strong enough» कितना strong है?

चूंकि cipher itself unbreakable है, scheme की पूरी security आपके password पर निर्भर करती है। Relevant math है entropy: H = L × log₂(N), जहां L length है और N वह character set का size है जिससे आप randomly draw कर रहे हैं। उदाहरण:

• 8 random lowercase letters → लगभग 37 bits। Modern GPU पर घंटों में crackable।
• 8 mixed-case characters with digits और symbols → लगभग 52 bits। Modern speeds पर घंटों से दिनों में।
• 12 mixed-case characters with digits और symbols → लगभग 79 bits। निकट भविष्य के लिए practical attack budgets से परे।
• 7,776-word Diceware list से छह random words → लगभग 78 bits। 12 random characters के समान security, लेकिन याद करना बहुत आसान।

Human-chosen passwords dramatically weaker होते हैं: NIST guidance में cited research average को लगभग 40 bits बताता है, यही कारण है कि dictionary attacks pure brute force पर dominate करते हैं। Memorised secrets के लिए NIST SP 800-63B की current advice: minimum 8 characters, कम से कम 64 allow करें, composition rules नहीं लगाएं (वे users को Password1! जैसे predictable patterns की ओर ले जाते हैं), periodic rotation की require नहीं करें, और known-breached passwords की lists के विरुद्ध screen करें। «long, memorable, never been in a breach» का aim रखें। चार से छह random words का passphrase जो आप actually याद कर सकते हैं, हर बार एक tortured 8-character «complex» password को beat करता है।

यह अन्य encryption tools के साथ कहां खड़ा है

• TLS / HTTPS आप और एक server के बीच transit में encrypt करता है। Server itself सब कुछ पढ़ सकता है जब यह land होता है। Eavesdropper problem को solve करता है, server problem को नहीं।
• Signal / WhatsApp / iMessage automatic key exchange और forward secrecy के साथ full end-to-end encryption हैं। दोनों को solve करते हैं, लेकिन दोनों parties को same app उपयोग करने की require करते हैं।
• PGP / age asymmetric हैं, आप बिना पहले shared secret की जरूरत के किसी के published public key पर encrypt करते हैं। Key distribution को solve करता है, लेकिन historically use करना painful था; age आधुनिक minimalist alternative है।
• OS-level disk encryption (FileVault, BitLocker, LUKS) AES-XTS का उपयोग करके एक single device पर data at rest को encrypt करता है। अलग threat model: device theft के विरुद्ध protect करता है, network interception के विरुद्ध नहीं।
• Password managers AES-GCM (या similar) का strong KDFs (आजकल typically Argon2id) के साथ एक encrypted vault के अंदर उपयोग करते हैं जो ciphertext को एक vendor backend के माध्यम से sync करता है जो इसे पढ़ नहीं सकता।

Password-based text encryptor इस family का सबसे कम specialized member है, identity, transport, या storage पर कोई opinion न रखने वाला pure cryptography। वही minimalism appeal है: यह सही tool है जब आपको specifically केवल AES-256 with a password चाहिए और कुछ नहीं।

और प्रश्न

क्या यह end-to-end encrypted है?

एक अर्थ में हां, encryption पूरी तरह आपके browser में होती है और Absolutool कभी plaintext या password नहीं देखता। Signal जैसे messaging products के strict sense में, नहीं: Signal additionally automatic asymmetric key exchange और identity binding प्रदान करता है ताकि users को password share करने के लिए separate trusted channel की जरूरत न हो। यह tool उन extras के बिना encryption half करता है, जो password-handoff को आपकी responsibility बनाता है।

क्या कोई «forgot password» recovery है?

नहीं, design से। Tool आपका password कभी नहीं देखता और कुछ भी store नहीं करता। यदि आप password खो देते हैं तो encrypted text unrecoverable है। Password को password manager में save करें या इसे कहीं physical लिखें।

Encrypted output random Base64 जैसा क्यों दिखता है?

क्योंकि वह exactly यही है। Salt, IV, और ciphertext-plus-authentication-tag को एक single binary blob में concatenate किया जाता है और Base64-encode किया जाता है ताकि result उन systems के माध्यम से safely travel करे जो printable ASCII (email, JSON, query strings) expect करते हैं। Decryption time पर तीनों components की जरूरत होती है, इसलिए वे packaged together हैं, जब आप blob back paste करते हैं तो tool उन्हें re-extract करता है।

क्या AES-256 कहीं illegal है?

Mass-market cryptography 2026 तक essentially दुनिया भर में हर consumer-facing product में broadly legal है। 1990s के US Crypto Wars Executive Order 13026 (1996) और 2000 mass-market relaxation के साथ समाप्त हुए। Specific embargoed destinations (Iran, North Korea, Syria, Cuba) और कुछ countries जिनके strong cryptography पर अपने import या use restrictions हैं (China, Russia, Vietnam और Saudi Arabia उनमें से) अभी भी local law के विरुद्ध checking के योग्य हैं यदि आप उन jurisdictions में tool का उपयोग कर रहे हैं।

क्या कुछ server पर भेजा जाता है?

नहीं। Web Crypto API browser में natively चलता है; crypto.subtle browser द्वारा TLS के लिए उपयोग की जाने वाली same crypto library में calls करता है (Chrome पर BoringSSL, Firefox पर NSS, Safari पर CommonCrypto)। कुछ भी आपके device को नहीं छोड़ता। Page को HTTPS की भी जरूरत है, जो browser द्वारा enforce की जाती है, Web Crypto केवल secure contexts पर available है ताकि network attacker के run से पहले JavaScript swap करने से बचाया जा सके।

संबंधित टूल