feat: replace connection keys with short seed-derived rtun3 keys
CI / cargo fmt (push) Canceled after 0s
CI / cargo clippy (macos-latest) (push) Canceled after 0s
CI / cargo clippy (ubuntu-latest) (push) Canceled after 0s
CI / cargo clippy (windows-latest) (push) Canceled after 0s
CI / cargo test (macos-latest) (push) Canceled after 0s
CI / cargo test (ubuntu-latest) (push) Canceled after 0s
CI / cargo test (windows-latest) (push) Canceled after 0s
CI / cargo build (macos-latest) (push) Canceled after 0s
CI / cargo build (ubuntu-latest) (push) Canceled after 0s
CI / cargo build (windows-latest) (push) Canceled after 0s
CI / cargo build --release (macos-latest) (push) Canceled after 0s
CI / cargo build --release (ubuntu-latest) (push) Canceled after 0s
CI / cargo build --release (windows-latest) (push) Canceled after 0s
CI / CLI smoke (macos-latest) (push) Canceled after 0s
CI / CLI smoke (ubuntu-latest) (push) Canceled after 0s
CI / CLI smoke (windows-latest) (push) Canceled after 0s
CI / Minimal E2E (macos-latest) (push) Canceled after 0s
CI / Minimal E2E (ubuntu-latest) (push) Canceled after 0s
CI / Minimal E2E (windows-latest) (push) Canceled after 0s

Connection keys are now a ~49-char seed (rtun3.) instead of a bundled
~1740-char certificate blob. Both endpoints deterministically derive an
identical Ed25519 CA from the seed and mint ephemeral server/client leaves
at startup (keyderive.rs); the app-layer auth token is derived from the seed.
Target is passed separately on connect (resocks-style).

- connkey.rs: rtun3 seed parse/format
- keyderive.rs: CA/server/client/token derivation
- keygen takes no args; connect requires --target
- remove miniz_oxide; TLS layer unchanged
- add determinism + key-based e2e + wrong-seed-rejected tests
- update wiki, README, design spec, CI smoke
This commit is contained in:
bzuccaro
2026-08-02 12:31:53 -06:00
parent 6bc3c00b64
commit 2bf8da739b
20 changed files with 616 additions and 338 deletions
+8 -7
View File
@@ -76,26 +76,27 @@ curl --proxy socks5h://127.0.0.1:1180 http://127.0.0.1:4181/
## Using a connection key
Instead of passing individual certificate paths, you can generate a single connection key:
Instead of passing individual certificate paths, you can use a short connection key
from which both ends derive identical credentials:
```sh
./target/release/rustunnel keygen --target 127.0.0.1:4180
./target/release/rustunnel keygen
```
Then start the listener with the key (it auto-generates credentials):
Start the listener with the key:
```sh
./target/release/rustunnel listen --connection-key <key>
./target/release/rustunnel listen --listen 0.0.0.0:4180 --connection-key <key>
```
And connect with the same key:
Connect with the same key, passing the listener address explicitly:
```sh
./target/release/rustunnel connect <key>
./target/release/rustunnel connect --target 127.0.0.1:4180 <key>
```
## Defaults
- Listener bind address: `0.0.0.0:4180`
- Connector target: required (or taken from connection key)
- Connector target: required (not stored in the key)
- Connector SOCKS5 proxy: `127.0.0.1:1180`