Encryption & Security

What is ECIES?

ECIES — the Elliptic Curve Integrated Encryption Scheme — is how you seal a secret for exactly one person using nothing but their public key. No shared password or shared secret sent in plaintext; the sender does need an authentic copy of the recipient’s public key. It's the mechanism that lets NDEVR OWL hand a file's key to a specific recipient so only they can open it.

What
A standard hybrid scheme: elliptic-curve key agreement + symmetric encryption.
You need
Only the recipient's public key. Nothing secret is exchanged in advance.
NDEVR's recipe
P-256 key agreement (ECDH) → HKDF-SHA256 → AES-256-GCM.
Result
A sealed blob only the recipient's private key can open — with built-in tamper detection.

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:

  1. Ephemeral key pair. The sender generates a brand-new, throwaway elliptic-curve key pair just for this one message.
  2. 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.
  3. 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.
  4. 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 client-held decryption keys, 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.

OPAQUE handles the step before that: password sign-in and local unlocking of the encrypted account private key. The unlocked P-256 key can then open ECIES-wrapped file keys. OPAQUE’s Ristretto255 authentication keys are separate from that P-256 account key, and neither protocol’s name implies that every stored file has forward secrecy.

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