Crypto Toolkit

Crypto Toolkit is a client-side workshop for four common crypto workflows: keyed HMAC digests, PBKDF2 password hashing, ULID generation, and TOTP codes. Switch modes from the tab strip, supply message/secret inputs as required, and copy results into docs or staging configs.

What you get

• HMAC-SHA256 hex digests for webhook and API signing experiments
• PBKDF2 password hashes with salt and high iteration counts (default 210k)
• ULID generation for sortable, opaque identifiers
• TOTP codes from Base32 secrets (RFC 6238-style 30s / 6-digit defaults)

Use this toolkit when

• You are debugging a webhook signature locally with a known test secret
• You need a PBKDF2 sample to compare against backend parameters
• You want ULIDs without standing up a service
• You are validating TOTP enrollment before shipping MFA UX

Prefer other tools when

• You only need unkeyed MD5/SHA digests → Hash Generator
• You only need to inspect JWT claims → JWT Decoder
• You need FIPS-certified or HSM-backed operations → dedicated infra

Each mode solves a different problem. Mixing them (e.g. hashing passwords with HMAC-only) creates false security.

HMAC — keyed integrity

Use HMAC when sender and receiver share a secret and must detect tampering. Provide message + secret; output is a hex digest (SHA-256). Good for webhook signatures and internal service auth experiments.

PBKDF2 — password hashing

Use PBKDF2 to derive a slow password hash with a unique salt and high iterations. Store salt with the hash. Prefer Argon2/bcrypt if policy requires them — Web Crypto exposes PBKDF2 natively here.

ULID — sortable unique ids

ULIDs combine a timestamp with randomness for lexicographically sortable ids. Use them for resource ids where UUID v4 ordering is awkward. They are identifiers, not secrets.

TOTP — time-based one-time passwords

TOTP derives rotating codes from a shared Base32 secret and the current time step. Use for MFA enrollment tests. Clock skew between device and server is the usual failure mode.

Run a mode end-to-end in the workspace above.

1. Select HMAC, Password Hash, ULID, or TOTP from the mode tabs.
2. For HMAC: paste message and shared secret, then generate the digest.
3. For PBKDF2: enter the password (and follow on-screen salt/iteration defaults unless matching a backend).
4. For ULID: set how many ids you need and generate.
5. For TOTP: paste a Base32 secret and read the current code; wait for the next period if testing rollover.
6. Copy outputs into staging docs — replace production secrets with placeholders before sharing.
7. Clear secrets from the form when finished on shared machines.

Problem: a webhook receiver rejects your signature. You need to confirm the canonical string and HMAC hex independently of framework middleware.

How this tool helps

1. Paste the exact signed payload bytes-as-text your sender uses (raw body, not re-serialized JSON).
2. Enter the staging webhook secret.
3. Generate HMAC-SHA256 and compare to the header your receiver expects (hex vs Base64 — match encoding).
4. If digests match here but fail in prod, inspect body mutation (proxies, charset) next.

Outcome: an isolated HMAC oracle for signature debugging without deploying new code.

Problem: backend and a script disagree on PBKDF2 output during a migration from plain SHA-256 password storage.

How this tool helps

1. Align hash algorithm (SHA-256), iteration count, salt, and output encoding with the server.
2. Hash a known test password here and compare to the server’s test vector.
3. Only then migrate real users — never debug with production passwords in the browser.

Outcome: parameter parity before cutting over the login verifier.

Problem: you need opaque, time-sortable ids for order rows without exposing auto-increment sequences.

How this tool helps

1. Generate a batch of ULIDs in ULID mode.
2. Confirm lexicographic order roughly tracks creation time for your UX needs.
3. Adopt ULID in the service layer; do not treat ids as authentication secrets.

Outcome: ready sample ids for fixtures and API sketches.

Problem: MFA enrollment QR codes work in one authenticator app but verification fails intermittently.

How this tool helps

1. Paste the same Base32 secret used in enrollment.
2. Compare the toolkit’s current code to the authenticator app at the same moment.
3. If they diverge, fix clock sync or period/digit parameters before blaming the QR payload.

Outcome: a local TOTP reference clock for enrollment debugging.

Secrets pasted into browser tools can leak via screenshots, shared machines, or synced clipboard history.

Why it happens

HMAC secrets, PBKDF2 passwords, and TOTP seeds are high-value. Local processing reduces network risk but not shoulder-surfing or disk persistence risk.

Diagnose

Ask whether the value is a production master key, live webhook secret, or only a staging fixture.

Fixes

1. Use staging secrets and placeholders in docs; inject real secrets only in secret managers.
2. Clear the form and clipboard after demos.
3. Rotate any production secret that was pasted into chat, tickets, or shared browsers.
4. Prefer environment-scoped keys so a leaked staging secret cannot mint production signatures.

TOTP codes disagree when clocks or parameters diverge.

Why it happens

RFC 6238 codes depend on Unix time steps. Skew beyond the allowed window, wrong period (30 vs 60), or wrong digit length causes false rejects.

Diagnose

Compare this toolkit’s code to the authenticator at the same second. If they match but the server fails, the server clock or window is wrong.

Fixes

1. NTP-sync servers and document an acceptable skew window (e.g. ±1 step).
2. Confirm Base32 alphabet (no spaces/padding mistakes) and 6-digit / 30s defaults unless you intentionally changed them.
3. Re-enroll after regenerating a secret — do not keep dual secrets without a migration plan.

Weak PBKDF2 parameters look like “hashing” but remain crackable.

Why it happens

Low iteration counts or reused salts defeat the purpose of a KDF. Fast hashes (SHA-256 alone) are worse.

Diagnose

Check iterations (aim high — this tool defaults around 210k), unique per-password salt, and SHA-256 (or stronger) PRF.

Fixes

1. Match OWASP / platform guidance for iteration counts and re-tune as hardware improves.
2. Store salt + hash + algorithm version for future upgrades.
3. If policy mandates Argon2 or bcrypt, use those libraries instead of PBKDF2.

Mode matrix for the Crypto Toolkit workspace.

• Local Web Crypto is convenient, not FIPS-certified HSM security.
• Never embed production master keys in client-side demos or committed fixtures.
• HMAC proves integrity with a shared secret — protect the secret like a password.
• ULIDs are identifiers; TOTP secrets are credentials — treat them differently.

• Document algorithm, encoding (hex vs Base64), and canonical body rules next to HMAC integrations.
• Version PBKDF2 parameters so you can raise iterations later.
• Generate TOTP secrets with CSPRNG; show them once during enrollment.
• Use Hash Generator for unkeyed checksums; use this toolkit for keyed and KDF workflows.

HMAC, PBKDF2, ULID, and TOTP run entirely in your browser via Web Crypto and local generators. Secrets and passwords are not uploaded for processing.

• Clear sensitive fields after use on shared devices.
• Optional localStorage for non-secret input stays on your origin only — avoid persisting live secrets.