Dead Drop Encryption

Everything else rests on this. You do not need it to build, but it is what the claims stand on.

The primitive: Dead Drop Encryption

Two parties who both have HexaEight identities can derive a shared key without exchanging public keys, without a certificate, and without ever having met. The platform issues each side their half when they need it.

Two consequences are worth stating loudly, because they are unusual.

The platform is not in the data path

The platform issues keys. That is all it does. It never sees your ciphertext, never relays a message, and never holds plaintext. Your messages do not travel through it.

This is a claim you should not have to take on trust — so the working algorithm is published with sample key values, and you can run the encryption yourself and confirm what it does.

You can encrypt to someone who does not exist yet

You can encrypt a message to [email protected] today, when Alice has never heard of HexaEight, has no account, and no software installed. When she later registers that address, she can decrypt it.

The same works for agents: address a request to [email protected] before that agent exists.

Nothing in the conventional identity stack does this. With certificates you cannot encrypt to somebody who has no certificate; with OAuth there is nobody to authorise. Here the address itself is enough.

Two paths, and the hour applies to only one

Collecting a key directly. The platform serves a given key for a window of about an hour, so a recipient taking that path collects their half inside it. Once collected, it is permanent.

Reaching somebody who may act next week. The message itself carries what the destination needs to identify the sender — the first-communication JWT, a token minted with the message rather than fetched from anywhere. There is no window to miss, which is what makes “encrypt to someone who has not registered yet” hold in the general case.

So both statements on this page are true: the address is enough, and the hour is a collection window on one of the two paths — not a deadline for the recipient to exist.

Transport stops mattering

Because encryption is end to end, what carries the bytes is irrelevant. Plain HTTP, a queue, a relay, a file on disk. Nothing in the middle can read or alter a message, so nothing in the middle has to be trusted. The agent is not giving you a secure channel; it is making the channel irrelevant.

The primitives, for those who want them

Skip this section if you are building rather than evaluating

Nothing below is needed to deploy an agent or write an engine. It is here for people who want to know what the claims above rest on. Every item names the method that implements it.

Five operations carry everything else.

Getting a key for a recipient

FetchAskAsync(recipient, kgt)          the implementation

Takes the recipient as a string and a key generation time. There is no lookup of a directory, no certificate exchange, and no requirement that the recipient exists — which is exactly why you can encrypt to an address nobody has registered yet. The call returns your half of the shared key.

Answers are cached locally, so a repeated send to the same recipient in the same window does not call out again.

The time window

CurrentKgt()                           minutes since epoch, rounded down to 15

Keys are derived per fifteen-minute bucket. Both sides derive the same bucket independently, so no negotiation is needed. The platform serves keys for a given bucket for a limited period — this is the practical window mentioned above, and the reason a recipient must collect their half reasonably promptly. Once collected, the key does not expire.

Sealing to one recipient

EncryptEnvelopeAsync(recipient, body, kgt, ...)     the implementation
DecryptEnvelopeAsync(envelope, pinAsk)             the implementation

The envelope carries who sent it, who it is for, and the window it was made in. Decryption is what proves the sender: producing a message that opens under the recipient’s half required the sender’s half, which only that identity could obtain.

DecryptEnvelopeAsync returns the sender and the authorization decision alongside the body, so the receiving code does not have to trust anything the message claims about itself.

Sealing to several recipients

MultiEncryptMessageUsingSharedKeyAsync(recipients, message, sharedKey)   the implementation

One ciphertext, several recipients, each able to open it with their own key. This is what relays and approval chains are built from.

Keys an identity holds for itself

FetchInternalKeyAsync(seed)            the implementation

A key derived from this identity plus a seed, used to encrypt things at rest that only this identity should read — its policy, its session store, its engine configuration. Nobody else can derive it, so a stolen file is inert.

What is not here

There is no key exchange step, no certificate validation, no revocation list, and no public-key directory. The absence is the point: those are the parts of the conventional stack that cost the most to operate.

Next

• Identity — where the identities come from
• Architecture — what is built on this