How Secure File Transfer Works: Ephemeral Keys and AES-GCM-256
Kamal Tripathi
Founder & Lead Engineer, Share2Me
In an era of frequent cloud data breaches, uploading sensitive files to cloud drives represents a measurable security risk. Secure file transfer requires end-to-end encryption (E2EE), ensuring only the sender and receiver can access the data. But what does E2EE actually mean mathematically? How do two browsers that have never communicated before derive a shared encryption key without transmitting that key over the network? And what makes AES-GCM-256 specifically better than older encryption modes for this purpose? This article explains the full cryptographic pipeline behind secure browser-to-browser file transfer.
1. The Key Exchange Problem
Symmetric encryption — where both parties use the same key — is the fastest method for encrypting large files. AES-256 can encrypt data at speeds exceeding 10 GB/s on modern hardware. But symmetric encryption has a fundamental challenge: both parties need the same key, and transmitting that key over the network exposes it to eavesdroppers. If the key is intercepted, all future encrypted data is compromised. Public-key cryptography solves this by splitting the key into two mathematically related parts: a public key (which can be shared openly) and a private key (which never leaves the device). The sender encrypts with the recipient's public key, and only the recipient's private key can decrypt it. But public-key encryption algorithms like RSA are too slow for encrypting large files directly — encrypting a 1 GB file with RSA would take minutes. The solution is a hybrid approach: use public-key cryptography exclusively for the key exchange, and use the faster symmetric AES for the actual file data. This is exactly what ECDH key exchange accomplishes.
2. Ephemeral Key Exchange: ECDH on the P-256 Curve
ECDH (Elliptic Curve Diffie-Hellman) allows two parties to derive the same shared secret using only public information, without either party transmitting the secret itself. The 'Elliptic Curve' part refers to the mathematical structure used. An elliptic curve over a finite field is defined by an equation of the form y² = x³ + ax + b (mod p), where p is a large prime. Points on this curve form a mathematical group — you can 'add' two points together to get a third point. The useful property is that multiplying a point by a large integer (called scalar multiplication) is computationally easy, but figuring out the integer from the resulting point is computationally infeasible for properly chosen parameters. This one-way function is the foundation of elliptic curve security. In ECDH on the P-256 curve, each party picks a random private key (a large integer between 1 and n-1, where n is the curve order) and computes their public key by multiplying the curve's standard Generator Point G by their private key. They exchange public keys. Party A then multiplies their own private key by Party B's public key, and Party B multiplies their own private key by Party A's public key — due to the mathematical properties of elliptic curve groups, both computations yield the same point on the curve, whose x-coordinate becomes the shared secret.
- P-256 Curve: NIST-standardised, 128-bit security level, natively supported by Web Crypto API.
- Shared Secret Derivation: Both parties arrive at the same 32-byte secret independently — neither party transmits it.
- Ephemeral: New key pairs are generated for each transfer session. Compromising one session reveals nothing about others.
- Web Crypto API: window.crypto.subtle.generateKey() and deriveKey() implement ECDH natively in browser.
3. AES-GCM-256: Authenticated Encryption
The 32-byte ECDH shared secret is passed through HKDF (HMAC-based Key Derivation Function) with SHA-256 to derive a properly structured 256-bit AES key. The file is then split into chunks (typically 128 KB each), and each chunk is encrypted using AES-GCM. GCM (Galois/Counter Mode) is a stream cipher mode that combines the AES block cipher with a Galois field multiplication authentication mechanism. It produces two outputs: the encrypted ciphertext and a 16-byte authentication tag. The authentication tag is a cryptographic hash of the ciphertext computed using the Galois field. When decrypting, the receiver recomputes the tag and compares it to the transmitted tag. If they match, the data is authentic and unmodified. If even a single bit was altered in transit — by a network error, a malicious actor, or storage corruption — the tags will not match and decryption will throw a DOMException. This authenticated encryption property is what makes GCM superior to CBC mode: CBC mode provides only confidentiality, not integrity. An attacker can make targeted modifications to CBC-encrypted data that survive decryption without detection, a class of attack called a padding oracle attack.
- Authentication Tag: 128-bit GHASH tag proves integrity — any bit flip in ciphertext is detected before acceptance.
- Counter Mode: GCM uses AES in Counter Mode, which is fully parallelisable unlike sequential CBC chains.
- AEAD: Authenticated Encryption with Associated Data — the 'AD' portion can authenticate non-encrypted metadata like the file name.
- Per-Chunk IV: Each 128 KB chunk uses a unique 12-byte random IV to prevent IV-reuse attacks.
4. Forward Secrecy and Why It Matters
Perfect Forward Secrecy (PFS) means that compromising the encryption key for one session does not compromise any other session. Traditional systems using long-lived RSA keys do not have this property — if an attacker records encrypted traffic today and later obtains the private key (through a breach, a court order, or a vulnerability), they can retroactively decrypt all recorded traffic. Ephemeral ECDH provides PFS because each transfer session generates completely new key pairs. The private keys are generated in browser memory, never stored anywhere, and are discarded when the browser tab is closed or the transfer completes. Even if an attacker somehow obtained the private key from one session (which is already effectively impossible in practice), they would only be able to decrypt data from that single session — not any previous or future sessions.
Conclusion
A modern secure file transfer pipeline combines ECDH key exchange (to establish a shared secret without transmitting it), HKDF key derivation (to produce a properly formatted AES key), and AES-GCM-256 authenticated encryption (to provide confidentiality and integrity). Ephemeral keys provide Perfect Forward Secrecy. The Web Crypto API makes all of this available natively in modern browsers without external dependencies. Share2Me implements this complete cryptographic stack to ensure that your files are protected by the same mechanisms used in TLS and Signal Protocol.
Written by Kamal Tripathi
Founder & Lead Engineer, Share2Me
Kamal is the founder of Share2Me and a full-stack engineer specialising in real-time browser communications, WebRTC, and cryptographic systems. He built Share2Me to solve the problem of cross-platform, privacy-first file sharing without requiring app installations.
Last updated: August 10, 2026