You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: PROTOCOL.md
+55-17Lines changed: 55 additions & 17 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -2,6 +2,43 @@
2
2
3
3
This document describes TYPHOON protocol design, goals and proposed implementation in rust.
4
4
5
+
## Design philosophy
6
+
7
+
TYPHOON is designed to be **flexible and false-fingerprintable** rather than uniformly high-entropy.
8
+
9
+
Uniform randomness is itself an identifiable pattern, and a static traffic profile — even a well-obfuscated one — can eventually be fingerprinted once an adversary has collected enough samples.
10
+
TYPHOON instead aims to look like _different things to different observers_.
11
+
Configuration is randomized independently **per [communication channel](#architecture)**, at a finer granularity than a typical connection: even within a single user's activity, different channels can exhibit completely different statistical properties — varying packet sizes, padding strategies, decoy rates, and cleartext header layouts.
12
+
Because configuration is re-randomized every time a new channel is established, two sessions between the same endpoints will not share a common traffic profile, even without restarting the server.
13
+
14
+
The [fake header](#fake-header) mechanism reinforces this: cleartext header fields can be made to resemble headers of arbitrary known protocols, making the traffic false-fingerprintable rather than merely hard to classify.
15
+
Combined with independently randomized [fake bodies](#fake-body) and [decoy traffic](#decoy-packets), the result is a protocol whose traffic signature is intentionally unstable and hard to pin to a single classification.
16
+
17
+
Because no single configuration is universally best, the protocol exposes a set of [tunable constants](#constants-and-defaults) that govern the probability distributions used when generating channel configurations.
18
+
Users are encouraged to adapt them to their threat model and performance requirements.
19
+
The following scenarios illustrate the trade-off space:
20
+
21
+
-**Throughput-critical** (e.g. private infrastructure over a trusted or monitored-but-not-filtered link):
22
+
minimize or disable padding and decoy traffic. The protocol still provides strong encryption but makes no attempt to disguise statistical properties. Overhead drops to near the cryptographic minimum.
23
+
24
+
-**Low-latency interactive** (e.g. a remote shell, collaborative editing, or real-time control):
25
+
keep packet padding light and decoy injection sparse to avoid adding per-packet delay.
26
+
Traffic volume stays close to actual application demand.
27
+
28
+
-**Protocol-transparent operation** (e.g. managed networks or transit infrastructure that classifies and policies traffic by protocol fingerprint):
29
+
enable [fake headers](#fake-header) to match the expected traffic profile of a locally common protocol, and keep decoy traffic at a moderate rate.
30
+
The goal is to appear indistinguishable from permitted traffic rather than to resist deep analysis.
31
+
32
+
-**High-security / traffic-analysis-resistant** (e.g. communicating under active network surveillance):
33
+
maximize padding, decoy traffic rates, and fake-header randomization.
34
+
Overhead increases substantially, but the traffic becomes hardest to characterize, correlate, or block.
35
+
36
+
-**Default (balanced)**:
37
+
a random mix of configurations is chosen per channel at startup, producing varied traffic that resists classification without being tuned for any single adversary model.
38
+
39
+
The defaults documented throughout this specification represent a reasonable starting point for the balanced mode and are not optimized for any particular scenario.
40
+
Explicit configuration always takes precedence over the defaults.
41
+
5
42
## Assumptions and limitations
6
43
7
44
There is one important assumption, required for proceeding with this protocol.
@@ -69,7 +106,7 @@ While it is technically possible for client flow managers to operate using diffe
@@ -139,12 +176,12 @@ It can be either empty, random or constant:
139
176
-`empty`: body is always empty, `0` bytes length.
140
177
-`random`: body length is random, it is bound between `TYPHOON_FAKE_BODY_LENGTH_MIN` and `TYPHOON_FAKE_BODY_LENGTH_MAX` constant values, making all the packets different in size.
141
178
-`service`: same as `random`, but is only applied to [health check](#health-check-packets) and [handshake](#handshake-packets) packets.
142
-
-`constant`: body length depends on the lengths of the other packet parts and complement them to a constant size.
179
+
-`constant`: body length depends on the lengths of the other packet parts and complement them to a constant size equal to `TYPHOON_FAKE_BODY_CONSTANT_LENGTH` (clamped to `[TYPHOON_FAKE_BODY_LENGTH_MIN, MTU]`).
143
180
144
181
> Handling `constant` body length might not be trivial, as it imposes a strict limit on packet data contents length.
145
182
> TYPHOON protocol specifically does not support data fragmentation, so `constant` body length just won't have any effect if real packet body length is not always strictly limited.
146
183
147
-
By default, fake body mode is chosen with equal probability for every option except for `service`, which is `TYPHOON_FAKE_BODY_SERVICE_PROBABILITY` heavier than the others.
184
+
By default, fake body mode is chosen with equal probability for every option except for `random`, which is `TYPHOON_FAKE_BODY_RANDOM_PROBABILITY` heavier than the others.
148
185
149
186
### Fake header
150
187
@@ -440,7 +477,7 @@ Even though replication is only applied to the decoy packets, it does not result
440
477
Also note that only the decoy packet "bodies" are replicated, while [fake headers](#fake-header) and [fake bodies](#fake-body) are generated anew; this represents lower-level protocol headers.
441
478
442
479
Packet duplicates are sent with a probability within `TYPHOON_DECOY_REPLICATION_PROBABILITY_MIN` and `TYPHOON_DECOY_REPLICATION_PROBABILITY_MAX`, selected upon a flow manager initialization.
443
-
After the first duplication, the subsequent duplication probability is multiplied by `TYPHOON_DECOY_REPLICATION_PROBABILITY_REDUCE`, becoming effectively lower.
480
+
After the first duplication, the subsequent duplication probability is divided by `TYPHOON_DECOY_REPLICATION_PROBABILITY_REDUCE`, becoming effectively lower.
444
481
Packet duplicates are sent within `TYPHOON_DECOY_REPLICATION_DELAY_MIN` and `TYPHOON_DECOY_REPLICATION_DELAY_MAX` milliseconds since the original packet departure.
445
482
446
483
The replication mode can have these values:
@@ -698,11 +735,11 @@ For the packets going from client to server, tailors are encrypted using the fol
698
735
3. Client performs X25519 key exchange using `EphSecKey` and `OPK`, deriving a shared secret (`ShrSec`).
699
736
4. Client obfuscates the `EphPubKey` using [`anonymous` encryption](#anonymous-encryption) (the key is derived using `BLAKE3` from concatenation of `OPK` and `Nnc`), producing `EphPubKeyObf`.
700
737
5. Client encrypts the `Tailor` using [marshalling encryption](#marshalling-encryption) using `BLAKE3` on `ShrSec` as key and `Nnc` as additional data, producing `TailorEnc`.
701
-
6. Client constructs the encrypted tail by concatenating `Nnc`, `EphPubKeyObf` and `TailorEnc`.
738
+
6. Client constructs the encrypted tail by concatenating `TailorEnc`, `EphPubKeyObf` and `Nnc`.
702
739
703
740
The tailors are decrypted using the following steps:
704
741
705
-
0. Server extracts `Nnc`, `EphPubKeyObf` and `TailorEnc` from the client message.
742
+
0. Server extracts `TailorEnc`, `EphPubKeyObf` and `Nnc` from the client message.
706
743
1. Server deobfuscates the `EphPubKeyObf` using [`anonymous` encryption](#anonymous-encryption) (the key is derived using `BLAKE3` from concatenation of `OPK` and `Nnc`), producing `EphPubKey`.
707
744
2. Server performs X25519 key exchange using `EphPubKey` and `OSK`, deriving a shared secret (`ShrSec`).
708
745
3. Server decrypts the `TailorEnc` using [marshalling encryption](#marshalling-encryption) using `BLAKE3` on `ShrSec` as key and `Nnc` as additional data, producing `Tailor`.
@@ -993,11 +1030,12 @@ These constants are used in some of the protocol values computation:
993
1030
994
1031
| Constant | Meaning | Default |
995
1032
| --- | --- | :---: |
996
-
|`TYPHOON_FAKE_BODY_LENGTH_MIN`| Minimum length of the fake body random byte string |`0`|
997
-
|`TYPHOON_FAKE_BODY_LENGTH_MAX`| Maximum length of the fake body random byte string |`256`|
998
-
|`TYPHOON_FAKE_BODY_SERVICE_PROBABILITY`| Multiplier of `service` fake body mode probability |`5`|
1033
+
|`TYPHOON_FAKE_BODY_LENGTH_MIN`| Minimum length of the fake body random byte string |`32`|
1034
+
|`TYPHOON_FAKE_BODY_LENGTH_MAX`| Maximum length of the fake body random byte string |`512`|
1035
+
|`TYPHOON_FAKE_BODY_CONSTANT_LENGTH`| Target packet length for `constant` fake body mode; clamped to `[FAKE_BODY_LENGTH_MIN, MTU]`|`1500`|
1036
+
|`TYPHOON_FAKE_BODY_RANDOM_PROBABILITY`| Multiplier of `random` fake body mode probability |`3`|
999
1037
|`TYPHOON_FAKE_HEADER_LENGTH_MIN`| Minimum length of the fake header structure |`4`|
1000
-
|`TYPHOON_FAKE_HEADER_PROBABILITY`| Probability of fake header presence |`0.35`|
1038
+
|`TYPHOON_FAKE_HEADER_PROBABILITY`| Probability of fake header presence |`0.6`|
1001
1039
|`TYPHOON_FAKE_HEADER_LENGTH_MAX`| Maximum length of the fake header structure |`32`|
1002
1040
|`TYPHOON_HEALTH_CHECK_NEXT_IN_MIN`| Minimum delay between health checking packets |`64000`|
1003
1041
|`TYPHOON_HEALTH_CHECK_NEXT_IN_MAX`| Maximum delay between health checking packets |`256000`|
@@ -1013,26 +1051,26 @@ These constants are used in some of the protocol values computation:
1013
1051
|`TYPHOON_RTT_MIN`| Minimum RTT value (in milliseconds) |`200`|
1014
1052
|`TYPHOON_RTT_MAX`| Maximum RTT value (in milliseconds) |`8000`|
1015
1053
|`TYPHOON_DECOY_REFERENCE_PACKET_RATE_DEFAULT`| Default reference packet rate (in milliseconds) |`200`|
1016
-
|`TYPHOON_DECOY_CURRENT_PACKET_RATE_DEFAULT`| Default current packet rate (in milliseconds) |`200`|
1054
+
|`TYPHOON_DECOY_CURRENT_PACKET_RATE_DEFAULT`| Default current packet rate (in milliseconds) |`1`|
1017
1055
|`TYPHOON_DECOY_CURRENT_BYTE_RATE_DEFAULT`| Default reference byte rate (in bytes) |`5000`|
1018
1056
|`TYPHOON_DECOY_BYTE_RATE_CAP`| Maximum bytes that can be sent in a flow per second |`1000000`|
1019
1057
|`TYPHOON_DECOY_BYTE_RATE_FACTOR`| Multiplier of bytes per second cap for bursts |`3`|
1020
1058
|`TYPHOON_DECOY_CURRENT_ALPHA`| Current byte rate calculation multiplier (updates fast) |`0.05`|
0 commit comments