Security

Minimize what the server can ever know.

The server temporarily stores only an encrypted envelope — never the secret, the password, or the keys used to unlock it.

Where each piece lives

Stays in your browser

  • The secret itself
  • The access password
  • The key half from the link — the part after #
  • The keys that encrypt and unlock the secret
Only encrypted data crosses the network

Held on the server

  • The encrypted envelope
  • Public parameters for strengthening the password
  • A check value for the correct password, protected by a server-side key
  • Timestamps for your status link and the number of wrong attempts

The encrypted copy is deleted after one successful claim or at expiry, whichever comes first. The status timestamps are kept 24 h longer so you can still check what happened.

How the encryption works

  1. Your password is strengthened

    In your browser, deliberately slowly and with a lot of memory, so guessing it takes an attacker far longer.

    Argon2id

  2. The link carries a second key

    A random 32-byte key lives only in the link's fragment, which browsers never send to the server.

    256-bit client key

  3. Both halves are combined

    Separate keys are derived for encrypting and for proving you know the password. Neither leaves your browser.

    HKDF-SHA256

  4. The secret is encrypted

    Before anything is sent over the network. The server receives only the result.

    XChaCha20-Poly1305

What "one-time" means

  • Opening the link uses nothing up — neither does a messenger's preview bot that opens it automatically.
  • Only Reveal with the correct password hands the secret out, and deletes the server copy in the same step.
  • A wrong password consumes nothing. The link alone can never use up the secret.
  • If two people reveal at the same moment, exactly one receives it; the other sees the same "unavailable" message as for an expired link.

Why the link and password travel separately

They are two independent halves of the key. Send them through different channels — the link in a messenger, the password by voice or from another device — so one compromised channel is never enough. Two apps on the same phone count as one channel once that phone is lost.

Keep the private status link. If it says "opened" and the recipient did not open it, treat the credential as exposed and change it.

What this protects against

  • Leaked Redis contents — only ciphertext, public metadata and a peppered verifier are stored there.
  • Accidental server logging — plaintext, passwords, ciphertext, and full secret URLs are never logged.
  • Link-preview bots and scanners that open links automatically without a user clicking Reveal.
  • Concurrent claim attempts on the same link.
  • An attacker who obtains only the link.
  • An attacker who obtains only the password.

What this does not protect against

SoloKeySplit is a browser-based product. It does not promise perfect anonymity or "no traces anywhere", and it cannot help once a device or the page itself is compromised.

  • A compromised sender or recipient device.
  • Keyloggers running on either device.
  • Malicious browser extensions.
  • Screenshots or screen recordings.
  • Clipboard monitoring software.
  • An actively compromised application server serving modified JavaScript.

Something not working?

Short answers about errors, phones, expiry and the status link.

Open help