Legal · Last updated 13 August 2026

Privacy

Cryptobench is a test bench for signed and encrypted payloads. It handles two things worth being careful about: cryptographic key material, and the artifacts you paste in to be read. This page is mostly about those.

The short version

  • Nothing you paste into the Inspector is stored. It is parsed in memory and the response is the answer.
  • No cookies are set for analytics, and no identifier of any kind is recorded. What is counted is how many times each page was read in an hour.
  • Private key material is encrypted at rest under a key that is not in the database.
  • There is no third-party analytics, advertising or tracking on this site. The Content-Security-Policy the site ships forbids loading scripts from anywhere else, so this is enforced rather than promised.

If you never sign in

You can use the Inspector, the bench, the glossary, the reference and the guides without an account. In that state:

The Inspector stores nothing. Post a token and it is decoded, checked and described in the response. There is no repository behind it and no row is written. Close the tab and there is no record that the token existed.

Page counts. Each page view increments an hourly counter. The row records the path, the host of the referring site - never the full referring URL, which can carry a query somebody else put there - the first language your browser offered, and the hour. It records no address, no cookie, no identifier, and no timestamp finer than the hour, so one person's reading cannot be reassembled from it. Ten thousand reads of a page in an hour is one row saying ten thousand.

Two things are kept in your browser, not on the server. Your language choice and your light/dark preference are stored locally. The theme is also written as a cookie scoped to the widest domain this site shares with its sign-in page, so the sign-in page can be drawn in the theme you chose rather than flashing the other one. Neither is sent to anyone, and neither identifies you.

If you sign in

Sign-in happens at the identity provider on the auth. subdomain, which this deployment runs itself. This site never sees your password.

Your account record holds the subject identifier the identity provider issues, a display name, an email address where the provider supplies one, a role, and the times the account was created and last seen.

Access tokens live in sessionStorage, not localStorage - they are gone when the tab closes, rather than persisting on disk for any script on the origin to read. For an application whose subject is key material, the smaller blast radius is worth the extra sign-in.

API tokens are stored as a digest. Only a SHA-256 of the token and its first few characters are kept. The token itself cannot be recovered from the database, which is why a lost one is replaced rather than looked up.

Key material

This is the part that deserves the most care, and the standing instruction is on every page: non-production use only. Never import a private key that protects anything real.

What the software does with what you do give it:

Private halves are encrypted at rest, under a key held outside the database. Each key set gets its own data key; that data key encrypts the private material; a master key held in the deployment's configuration wraps the data key, and only the wrapped form is stored. AES-256-GCM throughout. A copy of the database on its own therefore yields no usable private key material.

Public material is public on purpose. Each key set publishes a JWKS at a stable URL that needs no credential, because that URL is meant to be pasted into your own verifier. A key set's identifier is therefore a capability: anyone you give it to can read that key set's public half.

Deleting a key set deletes its material, immediately. The encrypted private halves and the wrapped data key go with the row when you remove it. There is no soft-delete and no grace period: once it is gone there is nothing left to recover it from.

Logs

The web server and the TLS terminator write ordinary access logs, and those contain IP addresses, in the way essentially every web server does. They exist to run and debug the service.

They are kept for at most fifteen days and then purged from the host. They are not shipped anywhere else, and no third party receives them.

What this site does not do

  • No advertising, no advertising identifiers, no cross-site tracking.
  • No third-party analytics. No Google Analytics, no tag manager, no pixels.
  • No sale or sharing of anything with anybody. There is no third party in the path: the analytics counter, the identity provider and the database are all parts of this deployment.
  • No profiling, and no automated decisions about you.

Other deployments

There are none. cryptobench.dev is the only deployment of this service, and the images that would let somebody run their own copy are not published.

That may change. If images are released so the software can be run on your own machine, this page will describe what that copy does - and the database, the logs and the configuration of any such copy would belong to whoever ran it, not to us.

How to ask

Write to support@cryptobench.dev with anything about this page or about data held for your account - including a request to see what is held, to correct it, or to have it removed.

This service is operated by CANDO IT Consult LTD., in Ontario, Canada. Ontario law governs it.

How long an account is kept. An account that has not been used for two years may be removed, and its key sets and projects go with it. Everything in the terms about exporting first applies: once the account is gone the material is not recoverable.

The law this follows. The operator is in Ontario, so personal information handled here is subject to Canada's Personal Information Protection and Electronic Documents Act (PIPEDA). PIPEDA is built on consent and on a set of principles - collect only what is needed for a stated purpose, say what the purpose is, keep it no longer than that purpose requires, and let people see and correct what is held about them. Writing to the address above is how you exercise the last of those.

Changes

Registered account holders are told by email when this page changes in a way that matters.

If you use the service without an account there is nobody to write to, so the date at the top of this page is the only notice you get - it is the date this text was last edited.

Reference

URL or embedded key?

Your app needs the public key to check a token. It can fetch it from a URL at runtime, or carry it as a file. Both are normal. The trade is always the same one: who controls rotation.

Fetch from the URLEmbed the key
RotationAutomatic on next fetchNeeds a redeploy
NetworkDepends on the URLNone
TrustWhatever the endpoint servesPinned to one key
SuitsA signer that rotates keysOffline, air-gapped, or pinned

Use the URL when the signer rotates its keys, which is what every identity provider does. That is why it became the norm, and it is usually a one-line config change.

Embed the key when you cannot make a network call while checking a token, or when you want your app pinned to one key so a compromised endpoint could not introduce another. Export the PEM from the Keysets tab.

One catch worth knowing: Spring Boot's public-key-location only loads RSA keys. An ES256 or EdDSA key needs a custom decoder, or the URL.