SECURITY

Juiced Security

ZestSSH Juiced uses zero-knowledge end-to-end encryption. Your SSH connections, keys, and credentials are encrypted on your device before anything leaves it. The server stores only opaque encrypted data — we cannot read your information, and neither can anyone else.

Security Whitepaper

Full architecture, threat model, and cryptographic primitives — for security reviews and compliance checks.

Download PDF

What zero-knowledge actually means

Your sync password never leaves your device
Your encryption keys are derived on-device and never transmitted
Our server stores encrypted blobs it cannot decrypt — not in aggregate, not under any circumstance
A full compromise of our servers would expose data that remains cryptographically unreadable without each user's individual password

The cryptography

Every piece of synced data is protected with industry-standard algorithms:

AES-256-GCM Data encryption — authenticated encryption that detects any tampering
Argon2id Password-based key derivation — memory-hard, OWASP-recommended, resistant to GPU and ASIC attacks
HKDF-SHA256 Verification-key derivation with domain separation
SQLCipher Local database encryption
OS-native secure storage Keychain on iOS/macOS, Android Keystore, Windows DPAPI, and libsecret on Linux

No custom or proprietary cryptography is used. Every primitive is a well-audited standard from maintained open-source libraries.

Key architecture

Your data is encrypted with a random 256-bit Data Encryption Key (DEK) that is generated once on your device and never leaves it in unencrypted form. This DEK is wrapped (encrypted) separately by two keys:

A key derived from your sync password
A key derived from your recovery key

Either path can unlock the DEK, which in turn decrypts your data. This means changing your password never requires re-encrypting your data, and your recovery key provides a fully independent decryption path.

How your data flows

Your Device Plaintext data
Encrypt AES-256-GCM
Encrypted Blob Unreadable
Server Can't decrypt

What gets encrypted

Everything syncable: SSH connections, identities, private keys, stored passwords, known_hosts entries, connection groups, snippets, and port-forwarding rules. Before any data leaves your device, it is serialized, compressed, and encrypted with AES-256-GCM. The server only ever sees the resulting ciphertext.

Recovery

When you first set up sync, you're issued a one-time recovery key formatted as:

ZEST-XXXX-XXXX-XXXX-XXXX-XXXX

This key is generated on your device, shown only once, and never transmitted to our servers. If you forget your password, the recovery key can unlock your data and let you set a new one.

Save it somewhere safe — a password manager, a printed copy in a drawer, wherever you keep things you genuinely can't afford to lose.

If you lose both your password and your recovery key, your data is permanently unrecoverable. That is the inherent tradeoff of real end-to-end encryption: in exchange for a server that can't read your data, we also can't help you recover it.

Transport security

All communication between the app and our servers uses TLS 1.2+ with certificate validation. Even if TLS were compromised on a given connection, your data would remain encrypted with keys the server never sees — the transport layer protects metadata, not your data's confidentiality.

Local data protection

On your device, your SSH credentials and sync keys are stored in your operating system's native secure storage (Keychain, Keystore, DPAPI, libsecret). The local ZestSSH database is independently encrypted with SQLCipher using a key held in that same secure storage. Both layers must be compromised for local data to be exposed.

Account protection

Destructive operations — deleting your sync data, deleting your account — require proof that you hold your sync password, not just a valid login token. This means an attacker who steals your session cannot wipe your data out of spite or ransom.

No tracking. Period.

ZestSSH contains zero analytics, zero crash reporting, and zero telemetry. No Firebase. No Crashlytics. No usage tracking of any kind. We have no idea how you use the app, how often you open it, what servers you connect to, or what commands you run. The only third-party service that receives any data is RevenueCat for purchase verification — and that contains only an anonymous app user ID.

Automation Security

ZestSSH's Automation Engine lets external apps trigger pre-configured SSH commands on your servers. Because this feature exposes an execution path, it's built with multiple layers of defense to keep that power under your control:

Default OFF — The Automation Engine must be explicitly enabled in Settings, with a security warning shown before activation
API Key Authentication — GitHub-style multi-key management. Each key has a label, creation date, last-used timestamp, and optional expiration (30/60/90 days or custom). Keys can be individually revoked at any time
Encrypted Key Storage — API keys are stored in OS-native secure storage (Android Keystore, iOS Keychain), never in plaintext
Constant-Time Comparison — API keys are hashed (SHA-256) and compared using constant-time equality to prevent timing side-channel attacks during validation
Rate Limiting — Failed API key attempts trigger exponential lockout to prevent brute-force enumeration
Credential Isolation — Triggering apps never gain access to your SSH keys or passwords. An external app can invoke a pre-configured automation, but cannot read, export, or exfiltrate the credentials that automation uses
Host Key Verification — Automations use the same Trust-On-First-Use model as manual connections. If a server's host key changes, the automation is rejected
No Shell Injection — Commands are passed directly to the SSH protocol, not interpolated into a shell string. Automation inputs cannot escape into unintended commands
Audit Trail — Every automation run is logged locally with timestamp, command, connection, exit code, and output for review

What automation cannot do

Execute arbitrary shell commands not pre-configured in your automation library
Bypass host key verification on unknown or changed servers
Access credentials for servers not in your saved connections
Run while the Automation Engine is disabled
Be enabled silently — every activation requires explicit user action in Settings

Backup Encryption

Local backups (.zest files) use the same encryption primitives as Juiced:

  • AES-256-GCM authenticated encryption
  • Argon2id key derivation from a password you choose (minimum 12 characters)
  • Auto-backups are created when the app is backgrounded after data modifications, saved to local app storage only — they never leave your device
  • Retention is capped at 3 auto-backup files; the oldest is deleted automatically as new ones are created
  • Manual backups use a password you choose, can be saved wherever you direct (local storage, cloud drive, external drive), and are never auto-deleted by ZestSSH

Because backups are encrypted with your password — not a ZestSSH-held key — you can safely store them in third-party cloud services (Google Drive, iCloud, Dropbox) without exposing your data to those providers.

Security research

ZestSSH is built by one person, and I take security reports seriously. If you've found a vulnerability, I'd love to hear about it.

Contact: [email protected]

I can't offer cash rewards — I'm a full-time college student working on this in my spare time — but validated security findings get a free ZestSSH Squeezed license or Juiced upgrade, public acknowledgment (if you want it), and my genuine thanks.

See the full disclosure policy for scope, safe harbor commitments, and disclosure timing.

What we cannot do

We cannot read your encrypted sync data
We cannot decrypt your local backups
We cannot recover your password or your recovery key
We cannot trigger automations on your behalf (API keys live on your device, not ours)
We cannot selectively modify your sync data (authenticated encryption would detect it)
We cannot delete your data without proof you hold the password

This is not a policy. It is a mathematical property of how the system is built.

Your data. Your keys. Your control.

Try Juiced with confidence. We built it so even we can't see what you store.