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 prior contact, no shared password, no key sent over the wire. 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 forward secrecy at the message level: every sealed blob uses an independent shared secret, so cracking one reveals nothing about any other. The ephemeral private key is discarded immediately after encryption — there's nothing left to steal.

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 file is encrypted with its own random AES key. To share that file, OWL doesn't move the file again — it simply ECIES-seals the file's key to each recipient's public key. The recipient's device unwraps it with their private key and can then decrypt the file. Because access lives in these wrapped keys rather than in the file itself, sharing and revoking are instant, and the server — which only ever holds ciphertext and sealed keys — can never read anything. That's the heart of OWL's zero-knowledge design.

References & Further Reading