Docs

Security Model

How Redshift protects your secrets and what threats it defends against.

Overview

Redshift is designed with a "zero trust" architecture. We assume that relay operators, network observers, and even the Redshift servers themselves could be compromised. Your secrets are protected through client-side encryption using keys only you control.

Client-Side Encryption

Secrets are encrypted before leaving your device

Your Keys Only

Only you hold the keys to decrypt your data

Cryptographic Signatures

All data is signed to prevent tampering

Decentralized Storage

No single point of failure or control

Encryption

Data at Rest

Your secrets are encrypted using your Nostr private key before being stored on relays. The encryption uses:

  • NIP-44 - Modern Nostr encryption standard
  • XChaCha20-Poly1305 - Authenticated encryption
  • secp256k1 ECDH - Key derivation from your Nostr keypair

Gift Wrap (NIP-59)

Redshift uses NIP-59 Gift Wrap to provide an additional layer of metadata protection. Gift wrapping involves three layers:

  • Rumor - Your actual secret data, unsigned (provides deniability if leaked)
  • Seal (Kind 13) - The rumor encrypted to the recipient, signed by you (proves authorship without revealing content)
  • Gift Wrap (Kind 1059) - The seal encrypted with a random ephemeral key (hides the true author from relay operators)

This layered approach ensures:

  • Content privacy - Only you can decrypt your secrets
  • Metadata privacy - Relay operators cannot link events to your identity
  • Deniability - Unsigned rumors cannot be authenticated if leaked

What relay operators see:

{
  "kind": 1059,
  "pubkey": "random_ephemeral_key",
  "content": "encrypted_seal_they_cannot_read",
  "tags": [["p", "your_public_key"]],
  "sig": "ephemeral_key_signature"
}

Data in Transit

All communication with relays uses WebSocket Secure (WSS), providing TLS encryption for the transport layer. Combined with application-layer encryption, this means:

  • Network observers see encrypted TLS traffic
  • Relay operators see encrypted Nostr events
  • Only you can decrypt the actual secret values

Key Management

Browser Extension (NIP-07)

When using a browser extension like Alby:

  • Your private key is stored in the extension's encrypted storage
  • Redshift never sees your private key
  • Each signing request requires extension approval (unless auto-approved)

nsec Direct Entry

When entering your nsec in the web admin:

  • The nsec is encrypted with a non-extractable AES-256-GCM key
  • The encryption key is stored in IndexedDB (browser-protected)
  • The encrypted nsec is stored in sessionStorage (cleared on tab close)
  • Decryption only happens in memory during signing operations

Bunker (NIP-46)

When using a bunker:

  • Your private key stays on the bunker server
  • Signing requests are encrypted end-to-end
  • The relay cannot read signing requests or responses
  • Security depends on the bunker's security

Threat Model

What Redshift Protects Against

Compromised Relay Operators

Relay operators cannot read your secrets - they only see encrypted blobs.

Network Eavesdropping

Double encryption (TLS + Nostr) protects against network observers.

Service Shutdown

Data is replicated across multiple relays. If one goes down, others have your data.

Data Tampering

Cryptographic signatures ensure data integrity. Tampered events are rejected.

Account Termination

No accounts to terminate. Your identity is a cryptographic key you control.

What Redshift Does NOT Protect Against

Compromised Device

If your computer is compromised, an attacker could steal your private key or read decrypted secrets from memory.

Lost Private Key

If you lose your nsec with no backup, your secrets are permanently inaccessible. There is no recovery mechanism.

Stolen Private Key

If someone obtains your nsec, they have full access to your identity and all secrets.

Malicious Browser Extension

A compromised NIP-07 extension could sign malicious events or leak your key.

Best Practices

Key Security

  • Back up your nsec - Store it in a password manager or secure offline location
  • Use a unique key - Consider a dedicated Nostr identity for Redshift
  • Prefer extensions - NIP-07 extensions provide better key isolation
  • Use a bunker for CI/CD - Don't embed your main nsec in CI secrets

Device Security

  • Keep devices updated - Apply security patches promptly
  • Use full-disk encryption - Protects data if device is stolen
  • Lock your screen - Don't leave sessions unattended
  • Avoid public computers - Never enter your nsec on untrusted devices

Operational Security

  • Rotate secrets regularly - Change API keys and passwords periodically
  • Use separate environments - Don't use production secrets in development
  • Audit access - Review who has access to shared identities
  • Disconnect when done - End sessions explicitly

Open Source & Auditing

Redshift is open source. You can review the code, run your own instance, or audit the cryptographic implementations:

  • GitHub Repository
  • Encryption uses well-audited libraries (nostr-tools, @noble/hashes)
  • No proprietary cryptography - standard Nostr NIPs only

Reporting Security Issues

If you discover a security vulnerability, please report it responsibly:

  • Email: [email protected]
  • Do not disclose publicly until we've had a chance to address it
  • We'll acknowledge receipt within 48 hours