Hermetic E2EE: Threshold Decryption with Proxy Re-encryption | Cyber Immunity Whitepaper

Overview

This document specifies the cryptographic protocol for Hermetic End-to-End Encryption (E2EE) - the threshold decryption construction that enables data encrypted to an ineffable key to be decrypted exclusively on an authorized user's device, without the decryption key materializing and without any intermediary observing the plaintext.

In conventional server-side encryption, the backend server retrieves ciphertext, fetches a decryption key from a Key Management System (KMS), decrypts in memory, and transmits plaintext over TLS. The server is a single point of absolute compromise: anyone who breaches it gains unrestricted access to cleartext. Hermetic E2EE eliminates this server-side decryption gap entirely.

The protocol defines three algorithms. Algorithm 0 (ElGamal Encryption) seals data to the public key of an ineffable key - a one-party local operation requiring no Tide Cybersecurity Fabric interaction. Algorithm 1 (Direct Threshold Decryption) is the baseline construction where the user communicates directly with the ORK swarm and interpolates partial results locally; it is presented for architectural contrast. Algorithm 2 (Proxy Re-encrypted Threshold Decryption) is the Hermetic E2EE construction: each ORK masks its partial decryption with the user's ephemeral session key, an intermediary server aggregates the masked results obliviously, and only the user's device - holding the session private key - can strip the mask and recover the cleartext. The plaintext exists solely on the user's terminal, strictly for the duration of the active session.

Loading diagram...

Preconditions

Requirement	Detail
Ineffable key $a$	Generated via Nested Shamir DKG (Article 3). Each ORK holds shard $a_i$ . Public key $A = G \cdot a$ is available to any encrypting party.
Encrypted data record $D$	Stored in the database: $D = (K, \mathcal{M}, T_{1..n}, \sigma_k)$ where $K = G \cdot k$ , $\mathcal{M} = \textsf{AES\_ENC}_{H(A \cdot k)}(m)$ , and $\sigma_k = \textsf{SIGN}_k(T_{1..n})$ .
User authentication	Completed via BYOiD (Article 4). The SWE generated ephemeral session key pair $(b, B)$ where $B = G \cdot b$ .
Doken $V$	VVK-signed delegated authority token containing: User ID $U$ , permission tags $T_{1..x}$ (from quorum-approved authorization - Article 5), session public key $B$ , and threshold signature $\sigma_a = \textsf{SIGN}_a(V)$ . The Doken is session-scoped, time-limited, and device-bound.
Threshold	$t = 14$ of $n = 20$ ORKs must participate for a valid result. This provides resilience against up to 6 unavailable nodes and security against up to 13 colluding nodes.

Protocol Flow

Algorithm 0: ElGamal Encryption (Data Sealing)

Algorithm 0 is a local, single-party operation. The encrypting party seals data to the ineffable key's public key

A

without interacting with the Fabric. The certification ceremony of the algorithm's result is done against the Tide Network to guarantee the authenticity of the data.

Loading diagram...

The tag signature

\sigma_k

binds the authorization tags to the ephemeral key - any post-encryption tag modification is detectable by the ORK swarm during decryption (via

\textsf{ValidateSignature}_k

). The symmetric key

z = \textsf{H}(A \cdot k)

is computationally equivalent to

\textsf{H}(K \cdot a)

: only the collective swarm holding shards of

a

can recompute it. See Algorithm 0 box for the formal construction.

This asymmetry - anyone can encrypt with

A

, only the swarm can decrypt via

a

- means data ingestion is fast and local (no network round-trips), while decryption is governed and distributed. A high-throughput service can seal millions of records locally, engaging the Fabric only when records must be unsealed.

Algorithm 1: Direct Threshold Decryption

In Algorithm 1, the user communicates directly with the ORK swarm. This is the simpler construction; Algorithm 2 addresses its architectural limitation.

Loading diagram...

Architectural limitation: In Algorithm 1, the interpolated value

Z = G \cdot k \cdot a

is the raw Diffie-Hellman shared secret from which the symmetric decryption key is derived. Any party who observes

Z

- including a network intermediary routing ORK responses - can compute

H(Z)

and decrypt the record. In a web architecture where a server necessarily mediates between the SWE and the ORK swarm, this server would gain full decryption capability, defeating E2EE.

Note that this is an intermediary exposure problem, not a user-side vulnerability. The user legitimately learns

Z

(they need it to decrypt), and

Z

for one record does not enable decryption of other records (each record has a unique

k

). The user cannot extract

k

from

Z

- that would require solving the Elliptic Curve Discrete Logarithm Problem.

Algorithm 1 is appropriate when the user communicates directly with ORKs without a server intermediary (e.g., a native application performing local-only decryption of the user's own data). For web applications where a Vendor server mediates communication, Algorithm 2 is required.

Algorithm 2: Threshold Decryption with Proxy Re-encryption (Hermetic E2EE)

Algorithm 2 is the primary construction. It introduces a Vendor intermediary for aggregation and a session-key masking term that makes the aggregation oblivious.

Additional precondition: The user's Doken

V

contains the session public key

B = G \cdot b

. The SWE holds the private session key

b

in browser memory.

Loading diagram...

Phase 2 detail: Each ORK computes two DH products and sums them: the partial decryption

K \cdot a_i

(identical to Algorithm 1) plus a session-key masking term

B \cdot a_i

. The ORK trusts

B

because it is embedded in the VVK-signed Doken - a forged

B

would require forging the threshold signature

\sigma_a

, which requires compromising 14 independent ORKs. By adding

B \cdot a_i

, the ORK ensures the final aggregate is bound to the user's session. No party without

b

can remove the masking term.

The ORK returns

Z_i

to the Vendor (not to the user). This routing is the architectural distinction from Algorithm 1: the Vendor collects all partial results, performs the interpolation centrally, and returns a single aggregate to the SWE - reducing client-side computation and ORK-to-client network traffic.

Phase 3 detail: The Vendor aggregates

t

partial results via Lagrange interpolation, producing

Z = G \cdot k \cdot a + G \cdot a \cdot b

. The Vendor knows

Z

A

, and

K

, but does not know

b

a

. It cannot separate the decryption term from the masking term and therefore cannot compute the symmetric key. To the Vendor,

Z

is computationally indistinguishable from a random group element (under the CDH assumption).

Phase 4 detail: Only the SWE holds

b

. It computes

A \cdot b = G \cdot a \cdot b

, subtracts to recover

Z' = G \cdot k \cdot a

, hashes to derive

z = H(Z')

, and decrypts

\mathcal{M}

locally. The plaintext

m

exists only in the SWE's volatile browser memory. When the session terminates - whether by logout, tab close, or timeout - the session key

b

is destroyed. Any intercepted aggregate

Z

from this session becomes permanently undecryptable: recovering the cleartext would require

b

, which no longer exists anywhere.

Forseti Integration: The Three Validations

Each ORK executes three validations before computing

Z_i

. These are the integration points with Forseti (detailed in Protocol: Forseti). All three must pass independently on each ORK; failure on any single validation causes the ORK to abort without computing its partial result.

Validation	Operation	Forseti Stage	Purpose
Token validation	$\textsf{ValidateToken}_A(V)$	`ValidateExecutor`	Verify the Doken was threshold-signed by the VVK ( $\sigma_a$ against $A$ ). Confirms the user completed BYOiD authentication, that the Doken was issued under quorum-approved governance, and that the embedded session key $B$ is authentic.
Signature validation	$\textsf{ValidateSignature}_k(T_{1..n})$	`ValidateData`	Verify tag signature $\sigma_k$ using the ephemeral public key $K = G \cdot k$ . Confirms the authorization tags have not been modified since encryption. A tampered tag set (e.g., removing a "classified" tag to bypass access control) produces an invalid signature.
Tag matching	$\textsf{MatchTags}(T_{1..n}, T_{1..x})$	`ValidateData`	Verify the data record's required tags $T_{1..n}$ are a subset of the user's permission tags $T_{1..x}$ from the Doken. This is the authorization check: the user can only decrypt data whose classification tags fall within their quorum-approved permissions (Article 5).

If any validation fails, the ORK aborts - it does not compute

Z_i

. The 14-of-20 threshold ensures that up to 13 compromised ORKs (which might skip validation) cannot produce a valid aggregate on their own.

Note that the Forseti validations are identical in Algorithm 1 and Algorithm 2 - the only difference is what the ORK computes after validation passes (

K \cdot a_i

in Algorithm 1 vs.

K \cdot a_i + B \cdot a_i

in Algorithm 2). The policy enforcement is the same regardless of whether proxy re-encryption is used.

Algorithms

Algorithm 0

The encrypting party requires only the public key

A

. No Fabric interaction occurs. The symmetric key

z = H(A \cdot k)

is equivalent to

H(K \cdot a)

- recomputable only by the collective swarm.

Algorithm 1

Algorithm 2

Notation Reference

Symbol	Description
$a$	Ineffable private key (never exists in complete form)
$a_i$	ORK $i$ 's Shamir shard of $a$
$A = G \cdot a$	Public key of the ineffable key
$\mathcal{G}$	Generator point on Curve25519
$k$	Random ephemeral scalar for encryption ( $k \in$ ℤ $_\ell$ )
$K = G \cdot k$	Ephemeral public key (stored with record)
$m$	Plaintext data
$H(\cdot)$	SHA-256 unless stated otherwise
$\mathcal{M} = \textsf{AES\_ENC}_{H(A \cdot k)}(m)$	Ciphertext
$\textsf{AES\_ENC}_{a}(B)$	AES256 encryption of message $B$ with key $a$
$\textsf{DEC}_{a}(B)$	X25519-based El-Gamal decryption of message $B$ with private key $a$
$T_{1..n}$	Data record authorization tags
$\sigma_k = \textsf{SIGN}_k(T_{1..n})$	Tag signature (tamper-evident binding)
$U$	User ID
$V$	Auth token (Doken)
$T_{1..x}$	User's permission tags (from Doken)
$\sigma_a = \textsf{SIGN}_a(V)$	Threshold signature over auth token
$b$	User's ephemeral session private key (SWE browser memory only)
$B = G \cdot b$	Session public key (embedded in Doken)
$Z_i$	ORK $i$ 's partial DH result
$Z$	Aggregate after Lagrange interpolation
$Z'$	Unmasked aggregate (after subtracting $A \cdot b$ )
$z = H(Z')$	Symmetric decryption key
$l_i$	Lagrange coefficient for ORK $i$
$t$	Threshold (14)
$n$	Total ORKs (20)

Actors and Trust Assumptions

Actor	Description	Trust Assumption
User (SWE)	End user with authenticated session. Holds ephemeral session key $b$ in browser memory and a valid Doken $V$ .	Potentially adversarial in Algorithm 1 (direct decryption). Trusted with their own data scope in Algorithm 2.
Database	Stores encrypted records $D$ .	Passive storage. No decryption capability.
TideCloak	Intermediary in Algorithm 2. Receives decryption requests, forwards to ORKs, performs Lagrange interpolation on masked partials, returns aggregate $Z$ to user.	Oblivious aggregator. Cannot recover cleartext - it sees $Z = G \cdot k \cdot a + G \cdot a \cdot b$ but holds neither $b$ nor $a$ .
VVK ORK Swarm	20 independent nodes holding shards $a_i$ . Each validates the Doken, enforces Forseti policy, and computes partial DH results.	Standard threshold trust ( $\leq 13$ may collude). Each ORK observes only $Z_i$ - a partial curve point, not the full key or plaintext.

Layer Traversal

Layer	How Hermetic E2EE Engages It
Legitimacy	Session key generation during BYOiD. ECDH channels between SWE, Vendor, and ORKs. Doken as bearer token with session binding.
Authority	ORK shard management. Each ORK holds $a_i$ and uses it for partial DH computation. The key $a$ is never reconstructed.
Agency	Primary layer. Threshold decryption with proxy re-encryption. Each ORK contributes $Z_i = K \cdot a_i + B \cdot a_i$ . Forseti governs participation. The Agency operation is "just-in-time data unlocking."
Settlement	Voucher validation for the decryption operation. Gas metering for Forseti contract execution.

Security Properties

Property	Mechanism	Assumption
No key reconstruction	The key $a$ never materializes. Each ORK computes a partial DH product $K \cdot a_i + B \cdot a_i$ - not a share of $a$ .	Threshold assumption ( $\leq 13$ compromised).
Proxy re-encryption	Each ORK masks its result with $B \cdot a_i$ . The Vendor aggregates to $Z = G \cdot k \cdot a + G \cdot a \cdot b$ but cannot separate the terms without $b$ or $a$ .	CDH hardness.
Session binding	Decryption is locked to the device holding $b$ . Only the SWE can compute $A \cdot b$ to unmask $Z$ . The Doken embeds $B$ and is VVK-signed.	Randomness of session key generation.
Forward secrecy	Each session generates a new $b$ , destroyed on termination. Compromising a future $b$ reveals nothing about past sessions.	SWE memory isolation.
Oblivious interpolation	The Vendor performs Lagrange interpolation without learning the plaintext. It sees $Z$ but cannot extract $G \cdot k \cdot a$ from $Z = G \cdot k \cdot a + G \cdot a \cdot b$ .	CDH hardness.
Tag-based authorization	ORKs enforce $\textsf{MatchTags}(T_{1..n}, T_{1..x})$ before computing $Z_i$ . Users can only decrypt records whose tags are a subset of their Doken permissions.	Quorum integrity of tag issuance (Article 5).
Tamper-evident tags	Tag signature $\sigma_k = \textsf{SIGN}_k(T_{1..n})$ prevents post-encryption tag modification.	Unforgeability of signature scheme.
Token validation (Forseti)	ORKs verify Doken signature $\sigma_a$ against VVK public key $A$ . Confirms BYOiD authentication and quorum-approved issuance.	Unforgeability of threshold signatures.
Threshold resilience	14 of 20 ORKs must independently validate and compute. Up to 13 compromised nodes cannot forge or bypass.	Honest-majority threshold assumption.
No offline decryption	Deliberate design choice. Offline decryption would require persisting $a$ , $k$ , or a derivative locally - recreating a stealable artifact. The Fabric must participate in every decryption, ensuring Forseti evaluates every access in real time.	-
Plaintext isolation	Plaintext $m$ exists only in the SWE's volatile browser memory during the active session. Never on any server or ORK.	Browser sandboxing integrity.
Encryption without Fabric	Algorithm 0 requires only $A$ (public). No Fabric interaction for encryption - any party can seal data, and the Fabric is engaged only for decryption.	-

Call Summary

Call	Direction	Payload	Purpose
`RecordRetrieval`	SWE → Database	Record ID	Fetch encrypted record $D = (K, \mathcal{M}, T_{1..n}, \sigma_k)$ .
`DecryptionRequest`	SWE → Vendor	$V, K, \sigma_k$	Submit decryption intent with Doken and record metadata.
`ProxyDecryptionReq`	Vendor → all $n$ ORKs	$V, K, \sigma_k$	Route request to ORK swarm for validation and partial computation.
`PartialResponse`	$t$ ORKs → Vendor	$Z_i$	Return proxy-re-encrypted partial DH results after Forseti validation passes.
`ObliviousAggregate`	Vendor → SWE	$Z, A$	Return Lagrange-interpolated masked aggregate for local unmasking.

References

Hall, J. L., Hertzog, Y., et al. (2023). Manifesting Unobtainable Secrets: Threshold Elliptic Curve Key Generation using Nested Shamir Secret Sharing. arXiv:2309.00915. Presented at AustMS 2021.
Blaze, M., Bleumer, G., & Strauss, M. (1998). Divertible Protocols and Atomic Proxy Cryptography. EUROCRYPT '98.
Tide Developer Documentation: docs.tidecloak.com