Noise_NNpsk0_25519_ChaChaPoly_SHA256 pattern for control, replication, and plugin Cap’n Proto channels instead of TLS.
Why Noise?
- Small footprint – fits into sidecar binaries and embedded agents that cannot afford a full TLS stack.
- Token-derived PSK – hashes the bearer token into a PSK so access control and transport security share the same credential.
- Deterministic configuration – concise patterns make audits straightforward and minimise configuration drift.
Handshake flow
- The initiator derives a PSK by hashing the bearer token; no static keys are exchanged out of band.
- The initiator sends an ephemeral key encrypted with the PSK (Noise
emessage). - The responder verifies the PSK, responds with its ephemeral key, and both sides derive symmetric session keys.
- Session keys protect all subsequent frames (control RPCs, replication data, plugin envelopes).
Configuration
Noise is on by default for control, replication, and Capnp plugin sockets; no extra TLS is required. The effective protocol string is fixed in the binary:dbx checkout --remote <host[:port]> --token <value> [--remote-tenant <id>]. Tokens are the only secret you need to rotate.
Operational guidance
- Monitor
noise_handshake_failures_total; spikes usually indicate bad or expired tokens. - Log handshake fingerprints only in debug mode—never expose tokens or derived PSKs.
- For zero-trust requirements, you can still layer WireGuard/IPSec, but the built-in Noise handshake already authenticates with the same token you use for authorization.