The Problem It Solves
You want to give a colleague access to an encrypted file. The file is locked with a fast AES key, so really you just need to hand them that key — securely. You can't email it (anyone could intercept it) and you can't encrypt it with AES (that just moves the same problem). ECIES is the standard answer: it lets you encrypt the key directly to the recipient's public key, so only their private key can recover it.
Because it pairs slow-but-clever public-key math with a fast symmetric cipher, ECIES is a form of hybrid encryption — the standard pattern behind almost all real-world public-key systems.
How ECIES Works
ECIES chains four well-understood building blocks. NDEVR's exact recipe:
- Ephemeral key pair. The sender generates a brand-new, throwaway elliptic-curve key pair just for this one message.
- Key agreement (ECDH). Using the Elliptic-Curve Diffie–Hellman trick, the sender combines their ephemeral private key with the recipient's public key to compute a shared secret. The remarkable part: the recipient can later compute the same secret from their own private key and the sender's ephemeral public key — without the secret ever being transmitted.
- Key derivation (HKDF-SHA256). The raw shared secret isn't used directly. It's run through HKDF, a key-derivation function, to produce a uniform, full-strength AES key.
- Symmetric encryption (AES-256-GCM). The actual data is encrypted with that key using AES-256-GCM, which also attaches an authentication tag so any tampering is detected on decryption.
The sender ships three things together: the ephemeral public key, the IV, and the ciphertext + tag. The recipient uses their private key to redo the key agreement, re-derives the same AES key, and decrypts. Nobody else can — they'd need the recipient's private key.
The One-Time Key Trick
Why a throwaway key every time
Generating a fresh ephemeral key for each message gives per-message key separation: every sealed blob uses an independent shared secret, so recovering one message key does not reveal any other. This alone is not forward secrecy — someone who later obtains the recipient's long-term private key can still decrypt recorded blobs using their stored ephemeral public keys.
NDEVR's implementation also stamps each ECIES blob with a version marker, so the format can evolve (for example, the move from older AES-CBC sealing to authenticated AES-256-GCM with HKDF) while older blobs still decrypt correctly.
How NDEVR Uses ECIES
In OWL, every resource file is encrypted with its own random AES key. For named-recipient CSD sharing, OWL ECIES-seals the file's key to each recipient's public key. With provider-held recovery disabled, the recipient's device unwraps it with the corresponding private key and decrypts locally while the server stores ciphertext and sealed keys without a usable Content Key. That is part of OWL's zero-knowledge content boundary.
ECIES does not hide account, recipient, routing or resource metadata. Revocation stops future server retrieval and wrapped-key delivery, but cannot erase a key, ciphertext or plaintext a recipient already retained. And when an OWL link uses server-side decryption (SSD), the Link Key is sent to the server so it can decrypt the requested content; that delivery trusts the provider and is outside the zero-knowledge claim. Public authored Sites are plaintext web pages, not ECIES-protected resources.
References & Further Reading
- Certicom/SECG, SEC 1: Elliptic Curve Cryptography — specifies ECIES and ECDH.
- IETF, RFC 5869: HKDF — the key-derivation step.
- NIST, SP 800-56A — Diffie–Hellman key agreement (the ECDH step).
- Wikipedia, Integrated Encryption Scheme and ECDH — accessible overviews.