Designing for Security First

Security as Architecture

When you build security as a feature, you end up with encrypted columns in a database that is otherwise designed to work with plaintext. When you build security as architecture, the entire system assumes it will never see plaintext.

JumpTerm was designed from the first line of code with the assumption that our servers would be compromised. Every design decision flows from this premise. The server is a dumb sync pipe. It stores encrypted blobs and relays them between devices. It never has the keys to decrypt them, and the protocol does not require it to.

Key Management

The hardest part of any E2EE system is key management. How do you get the encryption key to a new device without exposing it to the server? JumpTerm uses X25519 key exchange. Each device generates a key pair locally. When you add a new device, you verify it from an existing trusted device by comparing a short code (derived from the public keys). Once verified, the vault master key is encrypted to the new device's public key and transferred.

This means the server never sees the vault master key in plaintext. The verification step prevents a server-side attacker from impersonating a new device because they would not be able to produce a matching verification code.

Auditable Design

We publish our cryptographic protocol specification and welcome third-party security audits. We use well-known, widely reviewed cryptographic primitives (XChaCha20-Poly1305, Argon2id, X25519) rather than custom constructions. Our threat model is documented and we are transparent about what the system does and does not protect against.