WebAssembly एन्क्रिप्शन: ब्राउज़र में नियर-नेटिव क्रिप्टो स्पीड

WASM-compiled क्रिप्टो लाइब्रेरीज़ ब्राउज़र में native C speed का roughly 60-80% चलाती हैं — pure JavaScript implementations से 3-10x तेज़। Web Crypto API में missing algorithms (ChaCha20-Poly1305, Argon2id, XChaCha20, post-quantum KEMs जैसे Kyber) के लिए WASM usable performance का practical path है। libsodium.js dominant option है, जो 200 KB WASM binary के साथ full libsodium API provide करता है। AES-256-GCM जैसे Web Crypto-supported primitives के लिए browser की native hardware-accelerated implementation WASM को handily beat करती है, इसलिए WASM हमेशा सही tool नहीं है। यह guide बताती है कब इसे use करना है और trade-offs कैसे benchmark करें।

जब Native Web Crypto जीतता है

Web Crypto जो algorithms already expose करता है — AES-GCM, AES-CBC, AES-CTR, PBKDF2, HMAC, RSA-OAEP, ECDH, ECDSA, SHA-256/384/512 — उनके लिए browser का native implementation hardware acceleration उपयोग करता है: x86 पर AES-NI और mobile पर ARMv8 crypto extensions। Typical AES-256-GCM throughput:

• Web Crypto (Chrome on Apple Silicon): 1.7 GB/s
• Web Crypto (Chrome on Intel x86 with AES-NI): 1.2 GB/s
• libsodium WASM AES-GCM: 400-800 MB/s
• Native OpenSSL reference: 3-5 GB/s

WASM sandbox के अंदर से AES-NI तक पहुँच नहीं है; यह bitsliced AES implementations पर fall back करता है जो slower लेकिन constant-time होते हैं। Web Crypto जो support करता है उसके लिए उसे पहले उपयोग करें।

जहाँ WASM जीतता है

Web Crypto में missing algorithms के लिए:

• ChaCha20-Poly1305: AES-NI के बिना devices पर AES से fast। 2026 में native browser support नहीं।
• XChaCha20-Poly1305: 192-bit nonces random-nonce use को किसी भी scale पर safe बनाते हैं।
• Argon2id: PHC-winning password-hashing function। Browser में native support नहीं।
• X25519 / Ed25519: Safari 17 और Firefox 129 ने native support add किया, लेकिन WASM अभी भी portable path है।
• BLAKE2b / BLAKE3: fast hash functions जो Web Crypto में नहीं हैं।
• Kyber, Dilithium, SPHINCS+: post-quantum primitives; library territory।
• Streaming AEAD: libsodium का crypto_secretstream large-file streaming encryption cleanly handle करता है; Web Crypto में कोई equivalent नहीं।

इनके लिए JavaScript implementations exist करते हैं लेकिन WASM से 5-20x धीमे हैं। ChaCha20-Poly1305 के साथ 1 GB file पर WASM ~2 seconds लेता है जबकि pure JS 15-40 seconds।

libsodium.js: The Workhorse

libsodium-wrappers (Emscripten-built libsodium with JS wrappers) go-to library है। 200 KB WASM + ~50 KB JS wrapper, gzipped।

import _sodium from 'libsodium-wrappers';
await _sodium.ready;
const sodium = _sodium;

// ChaCha20-Poly1305 authenticated encryption
const key = sodium.crypto_aead_xchacha20poly1305_ietf_keygen();
const nonce = sodium.randombytes_buf(sodium.crypto_aead_xchacha20poly1305_ietf_NPUBBYTES);
const ciphertext = sodium.crypto_aead_xchacha20poly1305_ietf_encrypt(
  plaintext, null, null, nonce, key
);

"Sumo" build (more algorithms) ~600 KB है; default build 90% use cases cover करता है — AEAD, password hashing (Argon2id), X25519, Ed25519 सहित।

Initial page render block न करने के लिए dynamically load करें:

async function getSodium() {
  if (!window._sodium) {
    const mod = await import('libsodium-wrappers');
    await mod.ready;
    window._sodium = mod;
  }
  return window._sodium;
}

crypto_secretstream से Streaming AEAD

Large file transfer के लिए libsodium का crypto_secretstream_xchacha20poly1305 browser में cleanest streaming AEAD है:

const { state, header } = sodium.crypto_secretstream_xchacha20poly1305_init_push(key);
const chunk1 = sodium.crypto_secretstream_xchacha20poly1305_push(
  state, plaintext1, null,
  sodium.crypto_secretstream_xchacha20poly1305_TAG_MESSAGE
);
// Last chunk TAG_FINAL use करता है ताकि recipient truncation detect कर सके
const chunkLast = sodium.crypto_secretstream_xchacha20poly1305_push(
  state, plaintextLast, null,
  sodium.crypto_secretstream_xchacha20poly1305_TAG_FINAL
);

TAG_FINAL marker recipient को truncation attacks detect करने देता है — अगर attacker trailing chunks drop करे, client पर decryption fail होती है। Web Crypto के AES-GCM में यह property नहीं है; truncation detection आपको खुद build करनी होगी।

ब्राउज़र में Argon2

Browser में password-based key derivation के लिए WASM के ज़रिए Argon2id 2026 best practice है। Options:

• argon2-browser: dedicated Argon2 WASM library, ~200 KB
• libsodium.js: Argon2id crypto_pwhash के ज़रिए, अगर आप already libsodium use करते हैं
• @noble/hashes: pure-JS Argon2id, ~15 KB bundle, WASM से 3-5x धीमा

argon2-browser का example:

import argon2 from 'argon2-browser';
const result = await argon2.hash({
  pass: password,
  salt: salt, // Uint8Array, 16+ bytes
  type: argon2.ArgonType.Argon2id,
  time: 3,
  mem: 65536, // KiB, यानी 64 MiB
  parallelism: 4,
  hashLen: 32,
});
// result.hash एक Uint8Array है जिसे AES-256 key के रूप में उपयोग कर सकते हैं

Parameters को target user wait के लिए calibrate करें। OWASP 2024 baseline (m=19 MiB, t=2, p=1) ~300-500 ms चलता है। Strong (m=64 MiB, t=3, p=4) modern hardware पर ~1-2 seconds।

WASM के ज़रिए Post-Quantum Crypto

Kyber (key encapsulation) और Dilithium (signatures) NIST ने 2024 में ML-KEM और ML-DSA के रूप में standardize किए। JavaScript implementations exist करते हैं लेकिन liboqs-js जैसे WASM versions faster और ज़्यादा auditable हैं।

File transfer के लिए post-quantum KEMs symmetric file key को quantum-safe public-key primitive से wrap करने देते हैं। Hybrid schemes (ML-KEM + X25519) classical और future quantum attackers दोनों से protect करते हैं। Chrome ने version 116 (2023) में TLS handshakes में ML-KEM ship किया, लेकिन file content keys के लिए application-level WASM ही path रहता है।

Bundle Size Considerations

WASM binaries JS bundle के हिस्से के रूप में या lazily fetched ship होती हैं। Rough sizes (gzipped):

• libsodium.js default: 200 KB
• libsodium.js sumo: 600 KB
• argon2-browser: 200 KB
• liboqs-js (post-quantum): 1 MB+

एक landing page के लिए जो in-browser encrypt करती है, 200-300 KB WASM tolerable है अगर user interaction के बाद lazy-loaded हो। Encryption primary feature है तो initial load पर WASM shipping reasonable है। Subsequent loads instant रखने के लिए rel="modulepreload" hints या service worker caching उपयोग करें।

Browser dev tools के network panel में confirm करें कि first load के बाद WASM binary cached है। Misconfigured cache headers हर visit पर re-downloads करा सकते हैं।

Compilation और Instantiation Overhead

WebAssembly.instantiate() binary parse और compile करता है: desktop पर 200 KB module के लिए 20-100 ms, mobile पर 100-500 ms। यह प्रति session एक बार होता है। Faster subsequent loads के लिए compiled module को WebAssembly.Module serialization के ज़रिए IndexedDB में cache करें।

WebAssembly.instantiateStreaming() download और compilation pipeline करता है, instantiate() की तुलना में startup time का 30-50% बचाता है:

const response = fetch('/sodium.wasm');
const { instance } = await WebAssembly.instantiateStreaming(response, importObject);

Memory Management की जटिलताएं

WASM modules linear pages (64 KiB each) में memory allocate करते हैं। libsodium default small initial memory से शुरू होता है और ज़रूरत के अनुसार बढ़ता है, लेकिन unbounded growth browser limits hit कर सकती है (32-bit WASM में typically 4 GB linear memory cap)। Multi-GB file encryption के लिए:

• Chunks को WASM module के ज़रिए stream करें, full file WASM memory में न लोड करें
• sodium.memzero या references null करके हर chunk के बाद buffers free करें
• Long-running sessions में WebAssembly.Memory.buffer.byteLength monitor करें

Memory64 (proposed, Chrome में partially implemented) 4 GB cap हटाता है। अभी के लिए chunked processing reliable path है।

WASM-Specific Security Considerations

WASM उसी origin में चलता है जिस page ने इसे load किया, वही CSP और CORS rules inherit करता है। अगर attacker आपके origin में code inject करे (XSS), वे WASM module के exports call कर सकते हैं। WASM कोई extra security boundary नहीं देता।

Constant-time guarantees: ज़्यादातर crypto libraries WASM compile होने पर C source से constant-time properties preserve करती हैं, लेकिन WASM-to-JIT translation कुछ platforms पर variable-time code introduce कर सकता है। libsodium के audit logs कुछ WASM-specific constant-time concerns note करते हैं। ज़्यादातर threat models के लिए यह negligible है।

Practical Recipe

2026 में file transfer app के लिए:

• AES-256-GCM, PBKDF2, HMAC, SHA-256, RSA-OAEP के लिए Web Crypto उपयोग करें
• Argon2id password hashing के लिए WASM से libsodium.js उपयोग करें
• Large files की streaming encryption के लिए libsodium.js (crypto_secretstream)
• जहाँ supported हो native Ed25519/X25519, अन्यथा libsodium fallback
• Initial bundle light रखने के लिए user interaction के बाद WASM lazy-load करें
• Target devices पर benchmark करें; desktop numbers mobile match नहीं करते

HexaTransfer bulk file encryption के लिए Web Crypto AES-GCM पर रहता है क्योंकि hardware-accelerated path fastest है। WASM उन algorithms के लिए reserved है जो native APIs deliver नहीं कर सकते। DPDP Act 2023 के अंतर्गत Indian users के data की सुरक्षा के लिए यह layered approach — Web Crypto where possible, WASM where necessary — एक defensible cryptographic posture है।

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