Rift is built for trust between teammates, with security defaults that prevent accidents.
| Layer | How it works |
|---|---|
| Explicit approval | Every connection triggers a Y/N prompt — no silent access |
| End-to-end encrypted | QUIC transport + Noise Protocol (X25519, ChaCha20-Poly1305) |
| Peer-to-peer | Direct connection — no relay sees your plaintext traffic |
| Localhost by default | Client binds to 127.0.0.1 — your tunnel isn't exposed to your network |
| Secrets are opt-in | Must explicitly use --secrets to share, --request-secrets to receive |
| Session-scoped | Connections and secrets live only for the session |
- QUIC — UDP-based, multiplexed, built-in encryption
- Noise Protocol — Modern cryptographic handshake framework
- X25519 — Elliptic curve Diffie-Hellman key exchange
- ChaCha20-Poly1305 — Authenticated encryption for all tunnel traffic
# Host explicitly shares specific config
rift share 3000 --secrets .env.rift # Only what's in .env.rift
# Peer explicitly requests and saves
rift connect rift://... --request-secrets --save-secrets .env.localEncryption process:
- X25519 key exchange → unique shared secret per session
- AES-256-GCM encryption → secrets encrypted before transit
- No automatic persistence → secrets saved only with
--save-secrets - System keyring storage → identity keys stored securely via OS keyring
✅ DO:
- Create a
.env.riftwith only the variables needed (subset of your.env) - Review what you're sharing before using
--secrets - Use
--request-secretsexplicitly when you need config - Audit what secrets were received before using them
❌ DON'T:
- Share your entire
.envfile (may contain production credentials) - Use
--auto-approveon untrusted networks - Share secrets with people you don't trust
- Commit
.env.riftto version control if it contains real secrets
✅ DO:
- Keep default
127.0.0.1binding unless you need LAN access - Approve connections only from teammates you recognize
- Use
--no-tuimode for automation, but monitor logs
❌ DON'T:
- Use
--publicbinding without understanding the implications - Share links publicly (they contain your peer ID)
- Run on untrusted networks without reviewing approval prompts
Rift assumes:
- You trust the peers you connect to
- You're in a collaborative environment (team, OSS project)
- Connections are temporary (for debugging/pairing sessions)
Rift does NOT:
- Authenticate users (it's peer-to-peer)
- Prevent a malicious peer from reading traffic
- Protect against compromised teammate machines
If you need zero-trust networking, use a VPN solution like Tailscale instead.
✅ Passive network eavesdropping (encryption)
✅ Accidental exposure to local network (localhost binding)
✅ Silent secret exfiltration (explicit approval + opt-in)
✅ Relay server snooping (P2P design)
❌ Malicious peers you approve
❌ Compromised teammate machines
❌ Network-level attacks if peers are untrusted
❌ Long-term credential storage (use a proper secret manager)
If you discover a security vulnerability, please email the maintainers instead of opening a public issue.