Interactive simulation. Mock data, no functional backend, no deployable code. Built to study detection, not to operate.

Proxy re-encryption, explained from zero

No cryptography background assumed. Six diagrams, three of them step-through, that take you from "the relay sees everything" to "the relay can't see anything, and seizing it proves nothing."

The trusted-relay problem

Every widely used command-and-control framework concentrates trust, and therefore evidence, in its relay server.

Fig. D1 · where the evidence lives
The trusted-relay problem An operator and beacon exchange traffic through a central team server that holds plaintext queues and keys. A seizure marker on the server has a blast radius covering the full traffic history. OPERATOR sends commands BEACON returns results TEAM SERVER plaintext queue session keys full history SEIZED One seizure exposes every command, key, and result the relay ever touched.
Text equivalent
  1. The operator sends commands to a central team server; the beacon collects them and returns results the same way.
  2. The server terminates encryption, so it holds the plaintext queue, session keys, and complete traffic history.
  3. When that server is seized or monitored, its blast radius covers everything: every command, key, and result it ever relayed.

Key insight

TLS does not fix this. TLS protects traffic from outside observers, but the relay itself terminates the encryption, so the relay can still read everything. The trust problem lives inside the encrypted channel.

First, ordinary public-key encryption

The vocabulary for everything after: public key pk, secret key sk, ciphertext.

Fig. D2 · encrypt to a public key, only the secret key opens it
Ordinary public-key encryption Alice encrypts a message to Bob's public key, producing a ciphertext that only Bob's secret key can open. ALICE has Bob's pk(B) BOB holds sk(B) ciphertext ct(B) unreadable without sk(B) encrypt with pk(B) decrypt with sk(B) Anyone can encrypt to pk(B). Only Bob's sk(B) decrypts. No middleman is needed or possible.
Text equivalent
  1. Alice takes Bob's public key, which Bob publishes openly, and encrypts her message with it.
  2. The result is a ciphertext: readable by no one who lacks the matching secret key.
  3. Bob, and only Bob, opens it with his secret key.

Key insight

Public-key encryption removes the need to share secrets, but it locks each ciphertext to exactly one recipient. What if the recipient changes mid-route?

The core trick: re-encryption

Alice hands a semi-trusted proxy a special key that transforms ciphertexts without decrypting them. Step through it.

Fig. D3 · re-encryption through a semi-trusted proxy
Proxy re-encryption, step by step Alice encrypts a ciphertext, creates a re-encryption key from her secret key and Bob's public key, and hands it to a proxy. The proxy transforms the ciphertext for Bob without ever seeing plaintext or a decryption key. ALICE pk(A) · sk(A) PROXY semi-trusted BOB pk(B) · sk(B) ct(A) 1 · Alice encrypts with pk(A) 2 · rk(A→B) from sk(A) + pk(B) rk(A→B) 3 · proxy transforms ct(A) → ct(B) never sees plaintext · holds no decryption key ct(B) 4 · Bob decrypts with sk(B)

Text equivalent
  1. Alice encrypts a message under her own public key.
  2. She derives a re-encryption key from her secret key and Bob's public key, and delegates it to a semi-trusted proxy.
  3. The proxy uses that key to transform the ciphertext into one addressed to Bob; it never sees plaintext and holds no decryption key.
  4. Bob decrypts with his own secret key.

Key insight

The proxy is doing real cryptographic work, not copying plaintext. Re-encryption changes who can open a ciphertext without opening it. A compromised proxy exposes neither the message nor the keys.

Threshold splitting: no single point of seizure

One proxy is still one target. So the re-encryption key is split into fragments: any m of n suffice, and fewer than m reveal nothing.

Fig. D4 · one key, five fragments, threshold three
Threshold key splitting A re-encryption key splits into five k-frags distributed across five workers. With a threshold of three, greying out any two workers still leaves a working set; fewer than three fragments reveal nothing. rk(A→B) the whole key split k-frag 1w₁ k-frag 2w₂ k-frag 3w₃ k-frag 4w₄ k-frag 5w₅ threshold m = 3 of n = 5 w₄ seized w₅ seized w₁ w₂ w₃ still ≥ m re-encrypt still succeeds 2 frags = nothing

Text equivalent
  1. The re-encryption key is split into five fragments called k-frags, one held by each of five workers.
  2. The threshold is set at three: any three k-frags suffice to re-encrypt a ciphertext.
  3. Grey out (seize, block, or lose) any two workers: the remaining three still complete every re-encryption.
  4. The two seized fragments, below threshold, reveal nothing about the key or the traffic.

Key insight

This is the property that breaks takedown economics. There is no server whose seizure is decisive, and replacement workers cost minutes and near-zero dollars, as the simulation demonstrates.

Applied to command infrastructure

Map the roles and the whole model becomes the Novich0k research track: operator is Alice, beacon is Bob, edge workers are the proxies.

Fig. D5 · the roles, mapped
PRE applied to command-and-control The operator plays Alice, the beacon plays Bob, and a pool of edge workers plays the threshold proxy. Commands flow down and results flow up while the relay pool holds only k-frags and ciphertext blobs. OPERATOR = Alice edge worker · k-frag edge worker · k-frag edge worker · k-frag = threshold proxies (pool of n, any m) BEACON = Bob commands down results up relay holds: k-frags + ciphertext = random noise

Text equivalent
  1. Operator = Alice: encrypts commands and delegates re-encryption rights.
  2. Edge worker pool = threshold proxies: each worker holds one k-frag, any m suffice.
  3. Beacon = Bob: the only party that can decrypt.
  4. Commands flow down through the blind pool; results flow up the same way.
  5. The relay's entire holdings (k-frags plus ciphertext blobs) are indistinguishable from random data.

What the defender still sees

Blind relays remove content. They do not remove physics. These residual signals are the bridge to the detection work.

Fig. D6 · the residual signal strip
Residual signals visible to defenders Six signals survive blind relays: timing, byte counts, cadence, TLS fingerprint, relay churn rate, and DNS patterns. timing byte counts cadence TLS fingerprint relay churn DNS patterns Content is gone. Behavior remains, and behavior is collectible.
Text equivalent
  • Timing: when requests arrive and leave each relay.
  • Byte counts: request and response sizes, even when contents are unreadable.
  • Cadence: the rhythm of check-ins against human and machine baselines.
  • TLS fingerprint: the client library signature, which differs from browsers.
  • Relay churn: how often edge hostnames appear and vanish.
  • DNS patterns: the shape of disposable-worker name resolution.

Detection note

Every one of these signals is developed into a hunting hypothesis with a confidence rating on the Vileblood page, the defensive payload of this research.

Notation used on this site

SymbolMeaning
pk / skPublic key / secret key of a party (A = operator, B = beacon)
rk(A→B)Re-encryption key: transforms ciphertexts addressed to A into ciphertexts addressed to B
k-fragOne threshold fragment of a re-encryption key, held by a single worker
ctCiphertext: the encrypted payload (shown hatched in diagrams)
m-of-nThreshold: any m of n fragments suffice; fewer reveal nothing
capsule / cFragUmbral library terms: the packaged ciphertext, and a worker's re-encrypted fragment of it

Cryptography: Umbral proxy re-encryption on the secp256k1 curve: published, peer-adjacent, and library-available.

Next: the architecture Skip to detection

FURTHER READING · There Is No Handshake · Stateless Routing with HMAC