Skip to content
Create free account
Create free account

How secure is Crunu?

We build Crunu on the assumption that its server will be attacked. Here is what each attacker from the product’s threat model gets, what they don’t, and which layer stands in the way, including where Crunu can’t help.

Create free accountRead the security model
  • AES-256-GCM encrypts every version
  • X25519 seals keys, Ed25519 signs
  • Account key from your password (PBKDF2-SHA256, 1,000,000 iterations) and a Secret Key of about 128 bits, neither sent to the server
  • No decryption key on the server, at any step

Three layers of protection, and releases you can check

Crunu’s threat model marks every defense with the layer that provides it. That matters most when the attacker is the server itself, because only some layers keep working then.

  • Cryptography

    Who holds the key

    Environment keys are sealed only to the people, machines and tokens you allow, and access lists and versions are signed. Without the key, ciphertext stays ciphertext.

    If the server is taken overKeeps working.

  • Server

    Whom it sends ciphertext to, and whose changes it accepts

    Sign-in limits, session expiry, network rules, the recovery code’s waiting period, and cutting off someone you removed.

    If the server is taken overStops working.

  • Client

    What your browser and the agent check

    Signatures, version numbers and fingerprints: devices refuse anything unsigned or older than what they’ve already seen. Hiding values on screen is a client rule too, and it prevents accidents, not copying.

    If the server is taken overKeeps working, unless the server sends a tampered web page.

  • Verifiable releases

    Whether the code you run is genuine

    Every release of the agent and the web app is signed with Ed25519. The web build is reproducible, and the page allows no third-party scripts.

    If the server is taken overAgent updates keep checking. The web app checks itself inside the page it checks, so it can’t catch a server that changes both.

Example. Kiteline is a fictional company.

Attack by attack

One card for each attacker in Crunu’s threat model. The verdict is about the values in your environments; everything else an attacker gets is listed on the card.

  • ProtectedYour values stay unreadable and unchanged.
  • LimitedThey get something real, named on the card.
  • Not protectedCrunu can’t stop it. The card says what helps.

  1. A copy of the database leaks

    Protected

    A leaked backup, a stolen disk, a breach of another service, or a hosting company acting in bad faith.

    They get

    • Ciphertext of every environment, public keys and signed records
    • Metadata: project and environment names, who is on the team, and how often things change
    • Tokens, but only as keyed hashes (HMAC)

    They don’t get

    • Your values: there’s no decryption key anywhere in it
    • A shortcut to your password: every guess also needs your Secret Key, which was never on the server, so checking one guess means searching about 2¹²⁸ possibilities
    • Working tokens: the key for those hashes isn’t stored in the database

    Keep secrets out of names: a project named after an unannounced deal tells whoever reads the copy about the deal.

    Protected byCryptographyServer

  2. Someone takes over the server

    Limited

    Control of its code and database: an intruder, a rogue operator or a hijacked cloud account. On app.crunu.com, Crunu runs that server; on your own, you do.

    They get

    • Everything in a database copy, plus who downloaded which version and when
    • The power to refuse service or lose your changes
    • The chance to send a tampered web page that captures your password and Secret Key as you sign in. This is the main remaining risk.

    They don’t get

    • A place among the recipients: environment keys are sealed only to keys your organization certified, and your devices check the signed access list
    • A swapped key or altered data: keys are committed in signed records, and each version is signed and bound to its environment and number
    • A quiet rollback on a device that has seen newer data. A device that has never seen it can’t tell.

    The app checks itself against Crunu’s signed manifest on every load, and the page allows no third-party scripts. That check runs inside the same page, so it can’t catch a server that changes both.

    Protected byCryptographyClient

  3. Someone intercepts the connection

    Limited

    A forged TLS certificate or a malicious proxy between your device and the server.

    They get

    • What the server sees on that connection: ciphertext and metadata
    • The same chance as a taken-over server to send a tampered web page

    They don’t get

    • Your password or Secret Key: neither crosses the network in any form
    • A sign-in to replay: each sign-in signature names the server’s address and a one-time value (nonce), so it works once, on that server only

    Protected byCryptographyClient

  4. A teammate leaves on bad terms

    Limited

    Someone you removed from the organization who kept everything they could.

    They get

    • Everything they saw before you removed them. Those values keep working at your providers until you reissue them.

    They don’t get

    • Anything more from the server: it stops serving them at once
    • New versions: every environment key they held is rotated, so their old keys open nothing new, even with stolen ciphertext

    The exposure report shows which versions they received, and the reissue checklist lists the values to change at each provider.

    Protected byServerCryptography

  5. A teammate looks past their role

    Protected

    An honest but curious member: a developer with development access, or an Operator who sets up machines.

    They get

    • The environments they were given, which they can copy. Hiding values in the app is a display choice, not encryption.

    They don’t get

    • Production, from development access: they don’t have its key
    • Any values as an Operator: Operators hold no environment key at all
    • Other files with the Specific files role: they get a sealed copy of only the chosen files

    Protected byCryptography

  6. A session token is stolen

    Limited

    Copied from browser memory or from a proxy log.

    They get

    • What the server allows that account until the session ends: after 12 hours without activity, or 7 days at most

    They don’t get

    • Your values: decrypting them takes keys the token doesn’t carry
    • Signed changes: an access list or a version needs your signing key
    • Control of your account: changing your password or Secret Key requires both of them

    Your account lists every device and session, and you can end one or all of them.

    Protected byServerCryptography

  7. Your laptop is stolen

    Limited

    A device you’ve signed in on, taken with the app open or locked.

    They get

    • Your Secret Key, which the browser keeps by default, leaving your password as the barrier
    • Whatever is open, until the app locks after 10 minutes without activity (the default)

    They don’t get

    • Your keys once the app has locked: they stay encrypted without your password
    • Your account: an open session can’t change your password, Secret Key or account keys

    From another device, remove the stolen one, or use Device compromised: it replaces your account keys and rotates every environment you held a key to.

    Protected byCryptographyServer

  8. Someone gets root on a machine with the agent

    Limited

    A server running the crunu agent is a legitimate recipient, and so is whoever controls it.

    They get

    • Everything delivered to that machine. A program that’s already running keeps its variables until it restarts.

    They don’t get

    • Other machines or environments: each machine has its own keys and gets only what it was given
    • Access for long: a lease ends after 24 hours without contact, and a revoked machine drops its environments within minutes while it’s online

    Protected byCryptographyServer

  9. An enrollment code leaks

    Protected

    The single-use code you give crunu enroll on a new machine.

    They get

    • A chance to enroll a machine of their own, if they use the code before your machine does

    They don’t get

    • Approval: an admin approves a machine only after matching the fingerprint that crunu enroll prints on the real one
    • A quiet second try: the code lasts 15 minutes by default, burns on first use, and a reused code raises an alert

    Protected byCryptographyServer

  10. A CI token leaks

    Limited

    A service token copied out of a pipeline’s secret store.

    They get

    • Exactly what the token was given, often a single environment, until you revoke it or it expires

    They don’t get

    • Any other environment: production’s key is never sealed to a token that wasn’t given production
    • A sign-in from anywhere else, if the token is bound with OIDC: without your CI provider’s token for the right repository and branch, it doesn’t get in

    Protected byCryptographyServer

  11. Someone guesses passwords against the server

    Protected

    Sign-in attempts from one address or spread across many.

    They get

    • 10 failed attempts per IP address and 5 per account every 15 minutes

    They don’t get

    • A hint that an account exists: an unknown email and a wrong password get the same answer
    • In with the password alone: signing in also needs your Secret Key, and a new device needs your second factor once you turn one on
    • A shortcut through codes and links: they carry at least 128 random bits and are stored as keyed hashes

    Protected byServerCryptography

  12. Someone tampers with an agent release

    Protected

    A modified crunu binary or install script.

    They get

    • A way in only if they also control the web app that shows your install command, as in a server takeover

    They don’t get

    • A quiet install: the install command in the web app carries SHA-256 checksums from the release manifest, and the web app checks the manifest’s Ed25519 signature
    • A quiet update: crunu self-update checks the release signature with a key built into the agent

    Protected byCryptographyClient

  13. Malware runs on your device

    Not protected

    A keylogger, a malicious browser extension, or someone with root on your computer.

    They get

    • Your password and Secret Key as you type them, and everything that device decrypts

    They don’t get

    • Environments your account can’t open

    No encryption can protect a device from itself. Use devices you control, and after a compromise use Device compromised from a clean device and reissue the values it could reach.

    Protected byNothing in Crunu

Every known limit, and what to do about it

The cryptography

Standard building blocks in two implementations: the browser’s built-in WebCrypto and the Go standard library in the agent. Both are tested against the same shared test vectors.

The cryptography
AlgorithmWhat it does in CrunuWhere it runs
AES-256-GCMEncrypts each version of an environment. Additional authenticated data (AAD) binds the ciphertext to its organization, environment and version number, so it can’t be passed off as another.Browser and agent
X25519Seals an environment key to one recipient: a person, a machine or a service token. Each sealed copy uses a fresh key pair.Browser and agent
Ed25519Signs access lists, versions, share links and releases. Devices check every signature before they trust a record.Browser and agent; Crunu signs releases
HKDF-SHA256Derives a separate key for each job from one secret, so no key serves two purposes.Browser, agent and server
PBKDF2-SHA256, 1,000,000 iterations, and the Secret KeyTurns your password into one half of your account key. Your Secret Key, about 128 random bits, is the other half. Neither leaves your device.Your browser, or crunu in the terminal
SHA-256Links audit log entries into a hash chain, and makes key fingerprints you can compare by eye.The server writes the chain; your browser and your own tools can recompute it
Padding to 4,096 bytesRounds every encrypted version up to whole 4 KB blocks, so its exact size doesn’t show.Browser and agent, before encrypting
  • A key for every environment. Access to development opens nothing in production. Each person, machine and token gets its own sealed copy of only the keys it’s allowed.
  • Every format carries its version. Each record states its format version ("v": 2), and key derivation has its own (kdf.v). Devices refuse versions they don’t know, so the server can’t lower the cost of guessing your password or slip in an older format.

Quantum computers

A large enough quantum computer would break some of these building blocks and barely dent others. No such computer exists today. Here is where Crunu stands, without guessing when one might.

Quantum computers
AlgorithmQuantum attackWhat it would mean for Crunu
AES-256-GCMGrover’s algorithm: a faster search for the keyAbout 128 bits of strength remain. NIST expects AES-256 to stay safe for a very long time.
SHA-256 and HMACGrover-style searchA wide margin remains for the audit log’s hash chain and for keyed hashes. NIST uses SHA-256 as a benchmark for its post-quantum security levels.
PBKDF2 and the Secret KeyGrover-style search; Shor’s algorithm doesn’t applyGuessing still needs the Secret Key’s 128 random bits, the size of an AES-128 key, which NIST expects to stay secure for decades. Neither reaches the server.
X25519Shor’s algorithm: the private key from the public oneBroken. Environment keys sealed with it could be opened.
Ed25519Shor’s algorithmBroken. Signatures could be forged, but only at the time of an attack. Past data isn’t exposed.

Harvest now, decrypt later

Each environment key is sealed to its recipients’ X25519 public keys, and the sealed copies are stored on the server next to those public keys. Someone who keeps a copy of the database could, once a large quantum computer exists, open those copies and read the versions saved in that copy. NIST calls this threat “harvest now, decrypt later”.

It reaches only what that copy holds. Versions saved after the copy was taken aren’t in it, and a credential you’ve reissued at its provider is worthless to whoever decrypts the old one.

Your password, Secret Key and account key aren’t exposed this way: they never reach the server, and only symmetric functions are used on them. The attack doesn’t need them either, because it goes after the X25519 keys directly.

Signatures

Ed25519 signatures protect access lists, versions and releases. A quantum computer would let someone forge new ones, but a forgery matters only when it’s made and accepted, so it’s a risk for the day such a computer exists, not for data recorded today. NIST makes the same point: signatures aren’t at risk from harvest now, decrypt later.

What Crunu uses today, and what comes next

Crunu doesn’t use post-quantum algorithms today. NIST published its first post-quantum standards in August 2024: ML-KEM for establishing keys (FIPS 203) and ML-DSA for signatures (FIPS 204). Its transition plan, finalized in October 2026, lists elliptic-curve key agreement and EdDSA among the algorithms it will deprecate after 2030 and disallow in NIST standards after 2035.

Moving to post-quantum cryptography is on the Crunu roadmap. We don’t announce algorithms or dates we can’t commit to yet: when Crunu’s cryptography changes, this page will say so.

What you can do now

  • Think about how long each secret stays valuable. A key you reissue every few months loses little to a copy decrypted years later; a long-lived root credential loses more.
  • Reissue long-lived values at their providers on a schedule, and save each new value as a new version.
  • If a database copy in someone else’s hands is your concern, run your own server. The database and its backups then stay with you.

Sources

  1. NIST: NIST Releases First 3 Finalized Post-Quantum Encryption Standards (August 13, 2024)
  2. NIST FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard (August 2024)
  3. NIST FIPS 204: Module-Lattice-Based Digital Signature Standard (August 2024)
  4. NIST IR 8547: Transition to Post-Quantum Cryptography Standards (October 2026)
  5. NIST: Post-Quantum Cryptography FAQs (AES and Grover’s algorithm)
  6. L. K. Grover: A fast quantum mechanical algorithm for database search (1996)
  7. P. W. Shor: Polynomial-Time Algorithms for Prime Factorization and Discrete Logarithms on a Quantum Computer (1997)

Checked October 28, 2026.

Check it yourself

We have no badges or certificates to show yet. Here is what you can check today, and what isn’t there.

  • Signed releases.Every release of the agent and the web app is signed with an Ed25519 release key. crunu self-update checks the signature with a key built into the agent, and the web app shows Signed build once it has checked itself against the signed manifest.
  • A reproducible web build.One source commit always produces the same files, byte for byte. The source code isn’t published, so today only Crunu can rebuild a release and compare.
  • No third-party scripts.The page’s content security policy (CSP) allows only Crunu’s own code, which it loads with integrity checksums (SRI).
  • Few dependencies.The agent uses only the Go standard library, and the browser code includes a single npm package, yaml.
  • An audit log you can check outside Crunu.Owners and admins can export the log as JSONL and recompute its SHA-256 hash chain with their own tools.
  • What’s missing.No external security audit, no SOC 2 or ISO 27001 certification, and no published source code. Crunu is in early access; Audits and paperwork lists the documents we do have.
  • Found a problem?Email security@crunu.com. The same contact is in our security.txt, and Known limitations lists every limit we already know of.
Example. Kiteline is a fictional company.

Questions about Crunu’s security

Can Crunu read my secrets?

No. The server, run by Crunu on app.crunu.com or by you on your own, stores only ciphertext and has no key that could decrypt it. It does see metadata: names, email addresses, the audit log and when each version was saved. Reaching your values would take changing the code on your device, such as a tampered web page, which is the main remaining risk on this page.

What happens if your server is hacked?

Whoever breaks in gets ciphertext, public keys, keyed hashes of tokens and metadata. They can’t decrypt your values, add themselves to an access list or change a version without your devices noticing. They can stop serving you or send a tampered web page. If app.crunu.com is breached, we’ll email affected account holders without undue delay.

What if I forget my password?

Nobody can reset it, including us, because we never receive your password or your Secret Key. Your printed Emergency Kit and a recovery code are the ways back in. If you lose all of them, your account can’t be opened, though owners and admins can still open the organization’s shared environments.

Does Crunu protect against quantum computers?

Partly. AES-256 and SHA-256 are expected to hold. X25519 and Ed25519 would fall to a large quantum computer, which doesn’t exist today. Crunu doesn’t use post-quantum algorithms today, so a database copy kept for years could one day expose the versions in it. Moving to post-quantum cryptography is on the Crunu roadmap.

Has Crunu been audited?

No. Crunu is in early access, has no SOC 2 or ISO 27001 certification, and no external security audit has been published. Its source code isn’t published either. What you can check today is under “Check it yourself” above.

Is running my own server safer than app.crunu.com?

It changes whom you trust, not the encryption. Your own server keeps the database and its backups with you and sends the web page from infrastructure you control. In return, backups, updates and the server’s own secret become your job. The server is available on request at support@crunu.com.

How do I report a vulnerability?

Email security@crunu.com with the steps to reproduce it, and leave real secrets out of the report. The same contact is in our security.txt file, and the Security model page lists the rules for testing.

Keep your team’s secrets on a server that can’t read them

Create your account on app.crunu.com. Your keys are made in your browser, and the server gets only ciphertext.

Free during early access. Read the security model