Dead Drop Encryption — reference client transport

Reference implementation and test vectors for the client message transport of Dead Drop Encryption (DDE), the construction analyzed in the accompanying preprint Dead Drop Encryption: Asymmetric Shared Keys (ASK) for No-PKI, Identity-Addressed Communication, and the Security of its Client Transport.

DDE is a no-PKI communication model: a sender encrypts to a peer by identity name, with no key exchange, no certificates, and no requirement that the recipient be online (dead-drop delivery). Two parties derive the same channel secret (CS) without transmitting it — from client-held password material combined with per-peer pairing material issued by a semi-trusted broker.

Scope

This repository is about the transport only. It takes the channel secret as an assumed high-entropy shared key and implements the message layer built on top of it: a KMAC-256 extract-then-expand key schedule driving four interchangeable ciphers, with test vectors for byte-for-byte cross-language reproducibility.

The construction that produces the channel secret from passwords and brokered pairing material is a proprietary platform component. It is out of scope here and is neither disclosed nor relied upon — the transport is analyzed over an assumed CS. See the preprint's threat model and hexaeight-alice-bob-demo/SECURITY-MODEL.md for the trust boundaries, and note that the transport does not by itself establish system-level properties that depend on the derivation.

The four ciphers

All key an independent per-cipher key from the same CS via the extract-then-expand schedule (PRK = KMAC256(salt, be(CS)), k = KMAC256(PRK, label)):

Marker	Cipher	Standard
.FM1	AES-256-GCM (default)	FIPS 197 / SP 800-38D
.CM1	ChaCha20-Poly1305	RFC 8439
.SM1	AES-256-GCM-SIV (nonce-misuse-resistant)	RFC 8452
.EM1	SHAKE-256 keystream + KMAC-256 Encrypt-then-MAC	FIPS 202 / SP 800-185

.FM1/.CM1/.SM1 are the recommended default; .EM1 is a standards-based keystream alternative (and the building block for a peelable multi-hop mode, not included here).

Build and run

Requires the .NET 8 SDK.

cd hexaeight-alice-bob-demo
dotnet restore
dotnet build
dotnet run                 # Alice -> Bob over all four ciphers: round-trip + tamper-reject
dotnet run -- vectors      # regenerate the deterministic test vectors

NuGet dependencies: BouncyCastle.Cryptography 2.4.0, Newtonsoft.Json 13.0.3.

Note: pass vectors after -- exactly as shown. Extra dotnet verbosity flags before -- are not forwarded to the program and will run the demo instead.

Test vectors

hexaeight-alice-bob-demo/TEST-VECTORS.md lists deterministic vectors — the canonical channel-secret encoding be(CS), the extracted PRK, each per-cipher key, and the ciphertext/tag for each of .FM1, .CM1, .SM1, .EM1 under a fixed nonce and plaintext — so an independent port can check byte-for-byte agreement. They are regenerated by dotnet run -- vectors and match the preprint's appendix.

Contents

• hexaeight-alice-bob-demo/AliceBobDemo.vb — the reference implementation (single file).
• hexaeight-alice-bob-demo/TEST-VECTORS.md — deterministic test vectors.
• hexaeight-alice-bob-demo/SECURITY-MODEL.md — threat model and trust boundaries.
• hexaeight-alice-bob-demo/AI-REVIEW.md — the client-side review request.
• hexaeight-alice-bob-demo/LOGINTOKEN-SAMPLE-FOR-REVIEW.md — a sample login token (safe to publish).

Status and posture

The transport is deliberately a conventional composition of standard primitives; the contribution is the precise, reproducible specification (with vectors) and the model. The message path uses only symmetric cryptography and contains no public-key exchange, so it has no Shor-vulnerable component in the data path; we make no specific quantum-security-level claim for the scheme, and no security claim about the out-of-scope derivation.

We welcome scrutiny of the transport. Please open an issue.