Security architecture

How LiteSig protects your Litecoin

This page explains exactly what LiteSig can and cannot do with your coins, how your keys are protected, and what the open-source crypto modules that power the app actually do.

The core guarantee

LiteSig is non-custodial. Private key material is generated in your browser, encrypted with a passphrase only you know, and never transmitted to our servers in any form. Even if LiteSig's infrastructure were completely breached, an attacker would find only encrypted blobs — useless without your passphrase.

This isn't a policy claim. It's enforced at the code level: the server has a tripwire that rejects any API request whose payload contains known private key prefixes (xprv, Ltpv, tprv, ttpv). A bug that accidentally transmitted a private key would be blocked by the server before it persisted.

Key generation & derivation

All key material is derived in the browser using audited JavaScript cryptographic primitives. The derivation path follows Bitcoin Improvement Proposals that are also used by hardware wallets and other software wallets — your vault is not proprietary.

1
Entropy → BIP39 mnemonic 128 bits of cryptographically random entropy (via crypto.getRandomValues) are mapped to a 12-word BIP39 seed phrase. You write this down on paper — it is the master key to your wallet.
2
Mnemonic → HD seed (BIP39) The mnemonic is converted to a 512-bit seed using PBKDF2-HMAC-SHA512 with 2048 iterations. An optional BIP39 passphrase can be added (distinct from the LiteSig encryption passphrase).
3
HD seed → master key → account key (BIP32 / BIP48) For multisig vaults, derivation follows BIP48 (m/48'/2'/0'/2' for P2WSH on Litecoin). This produces an account-level extended public key (xpub/Ltub) that is safe to share with cosigners — it reveals public keys but not private keys.
4
Cosigner xpubs → multisig address (BIP67) All cosigner xpubs are collected client-side. Public keys are sorted using BIP67 deterministic ordering, then combined into a P2WSH (or P2SH / P2SH-P2WSH) multisig address. All parties independently arrive at the same address.

Encryption at rest

Your wallet configuration (xpubs, derivation path, m/n, address index) and private key material are encrypted locally before anything is sent to the server.

Algorithm
AES-256-GCM

Authenticated encryption — both confidentiality and integrity. Tampered ciphertext is detected and rejected.

Key derivation
PBKDF2-SHA-256

Your passphrase is stretched with 200,000 iterations and a random 16-byte salt. Brute force is deliberately expensive.

Where it runs
Web Crypto API

All encryption uses the browser's built-in SubtleCrypto — no third-party crypto library handles your key derivation.

What's stored
Encrypted blob only

The server stores the resulting ciphertext. The passphrase is never sent. The plaintext is never stored.

Your passphrase cannot be recovered. If you forget it, only your BIP39 seed phrase backup can recover the wallet. There is no "forgot passphrase" flow — by design.

PSBT signing flow

Spending from a multisig vault uses Partially Signed Bitcoin Transactions (PSBT), the same format used by hardware wallets and Electrum. The server coordinates but never signs.

1
Initiator builds the PSBT One cosigner (the initiator) constructs the unsigned transaction in their browser using bitcoinjs-lib with Litecoin parameters. The PSBT is uploaded to LiteSig as a base64 blob.
2
Cosigners are notified LiteSig emails cosigners (if their addresses are registered) that a signature is required. Each cosigner downloads the PSBT, decrypts their key locally, signs, and uploads the partial signature.
3
Signatures are combined The initiator downloads all partial PSBTs, combines them in the browser, and finalizes once the m-of-n threshold is met.
4
Broadcast The finalized transaction is broadcast to the Litecoin network directly from the browser. LiteSig's server is not in the broadcast path.

At no point does the server hold a signing key, see plaintext transaction inputs, or have the ability to initiate or modify a transaction.

What the server sees

The LiteSig server is intentionally designed to be as blind as possible. Here is what it actually stores:

  • Your email address — for login and notifications.
  • A bcrypt hash of your password (cost factor 12) — the plaintext is never stored.
  • Encrypted wallet blobs — AES-256-GCM ciphertext of your wallet configuration. The server cannot read it.
  • Wallet metadata — network (mainnet/testnet), script type, m, n. These are not sensitive.
  • PSBT blobs — base64-encoded PSBT data during the signing round. The server does not parse or inspect them.
  • Stripe customer/subscription IDs — for billing. Payment details are held by Stripe, not LiteSig.

The server never stores: private keys, seed phrases, unencrypted wallet configurations, or transaction signing keys of any kind.

Account security

Your LiteSig account protects access to your encrypted blobs. Compromising your account gives an attacker the ciphertext — which is useless without your passphrase. That said, we take account security seriously:

Passwords
bcrypt, cost 12

A minimum 10-character password, stored as a bcrypt hash. Never logged, never transmitted back.

2FA
TOTP (RFC 6238)

Optional but recommended. Compatible with any TOTP app (Authy, Google Authenticator, 1Password). The TOTP secret is encrypted at rest using AES-256-GCM.

Sessions
JWT + rotating refresh tokens

15-minute access tokens stay in memory only. Refresh tokens are stored in httpOnly, Secure, SameSite=Strict cookies and rotate on every use.

CSRF
Custom header + SameSite

All state-changing API calls require an X-Requested-With header and the refresh-token cookie enforces SameSite=Strict.

Rate limiting
10 req / 15 min

Auth endpoints are rate-limited to prevent credential stuffing and brute-force attempts.

Input validation
Zod schemas

Every API endpoint validates input with strict Zod schemas before touching the database.

Open-source crypto modules

The cryptographic core of LiteSig — everything that touches key material, address derivation, and transaction signing — is open source and independently auditable. The code is written in F# and compiled to JavaScript via Fable.

Crypto modules (open source)

  • Crypto.fs SHA-256, RIPEMD-160, Hash160 — thin wrappers over @noble/hashes, an audited pure-JS crypto library.
  • Bip32.fs BIP39 mnemonic generation & validation; BIP32 HD key derivation with Litecoin extended key versions (Ltub/Ltpv); BIP48 multisig account paths.
  • Script.fs m-of-n multisig script construction with mandatory BIP67 public key sorting.
  • Address.fs P2SH (M…), P2WSH (ltc1…), P2SH-P2WSH, P2PKH, and P2WPKH address encoding for Litecoin mainnet and testnet.
  • Psbt.fs PSBT build, sign, combine, finalize, and extract via bitcoinjs-lib with Litecoin network parameters.

These modules have a test suite (Fable.Mocha) that cross-validates address construction against bitcoinjs-lib's independent implementation and exercises the full 2-of-3 sign → combine → finalize → extract flow.

The server-side code (API, auth, billing) is not open source. However, the server is intentionally designed to be useless without the client: it stores only encrypted blobs and never participates in signing. You can verify this claim by auditing the client code independently.

Open standards & recovery

LiteSig does not use proprietary key formats. Every vault can be recovered using other standards-compliant wallets if LiteSig ceases to exist.

BIP-39 Mnemonic seed phrases — 12 words, standard wordlist
BIP-32 Hierarchical Deterministic key derivation
BIP-48 Multi-account hierarchy for multisig wallets
BIP-67 Deterministic public key sorting for multisig scripts
BIP-174 Partially Signed Bitcoin Transaction (PSBT) format
P2WSH Native SegWit multisig — lowest fees, widest compatibility

To recover a vault without LiteSig: import your BIP39 seed phrase into any BIP48-compatible wallet (Electrum-LTC with the right derivation path, or a hardware wallet that supports Litecoin multisig), re-enter your cosigners' xpubs, and reconstruct the same address. The funds are accessible.

Threat model & limits

We believe in being honest about what LiteSig does and doesn't protect against.

Protected against

  • LiteSig server breach — an attacker who fully compromises our servers gets encrypted blobs and email addresses. They cannot move any funds without your passphrase.
  • Single key loss or theft — the entire point of multisig. One compromised key is not enough to sign a transaction.
  • Single device failure — your BIP39 backup restores your key; cosigners' keys are theirs independently.
  • LiteSig disappearing — your vault is recoverable in any BIP48-compatible wallet using your seed phrase.

Not protected against

  • Passphrase forgotten with no seed backup — there is no recovery path. Write down your seed phrase on paper and keep it somewhere safe.
  • Compromised browser or device — if malware runs in your browser at the time of signing, it could intercept the decrypted key before it is used. Use an up-to-date browser on a trusted device.
  • Coercion of m-of-n cosigners — if enough cosigners are forced to sign, funds can be moved. Choose cosigners you trust and whose keys are geographically or organizationally separated.
  • LiteSig account compromise without 2FA — an attacker who logs in to your account can download your encrypted blob and attempt to brute-force your passphrase offline. Enable TOTP 2FA and use a strong, unique passphrase.
Have a security finding? Email security@litesig.com. We will respond within 48 hours.