VESlocker

Hardware-grade PIN security — without the hardware.

A 4-digit PIN has only 10,000 combinations. Anywhere it guards data an attacker can copy — a browser, a file, a backup — they can brute-force it offline in milliseconds. VESlocker removes the offline attack entirely: the decryption key is split between the user's PIN and a secret held by a small key server, released only under a strict, exponentially-throttled budget. After a few dozen wrong guesses the entry is locked for good — a true lifetime cap on attempts, the way a TPM or a secure enclave behaves, in ~250 lines of vanilla JS and ~110 lines of PHP.

How it works

• The client derives challenge = SHA-256(seed ‖ PIN) and sends only an id and that challenge to the key server — never the seed, the PIN, or the data.
• The server looks up a per-id secret, enforces the throttle (the next attempt is refused for 2^attempts seconds, capped), and returns key = SHA-256(secret ‖ challenge).
• The client encrypts the data with AES-GCM(key). The ciphertext and the seed are kept locally; the key itself is never stored.
• Every request to an id increments its counter. After ~32 attempts the wait exceeds a century — the entry is effectively sealed.

Quickstart

<script src="https://veslocker.com/pub/VESlocker.js"></script>
<script>
  const vl = new VESlocker({
    apiUrl: "https://veslocker.com/api/VESlocker.php"
  });

  // Encrypt a secret behind a PIN and stash it under a name:
  await vl.store("launch-codes", "1234", "the actual launch codes");

  // Read it back with the PIN - throttled, and re-deposited under a
  // fresh id + seed on every success:
  const secret = await vl.fetch("launch-codes", "1234");
</script>

The client is Apache-2.0 — embed it with no copyleft obligations. Prefer to manage storage yourself? encrypt / decrypt are stateless and return / take a self-contained token.

Try it live

This demo talks to the public veslocker.com key server. Store a value behind a PIN, then fetch it back — and watch the throttle kick in after a few wrong PINs.

How it compares

VESlocker isn't a new cryptographic protocol — it's a deliberately minimal take on a known idea: harden a low-entropy PIN with the help of a key server, so it can't be brute-forced offline. Here's how it sits next to the rigorous prior art.

The server is unauthenticated by design — no accounts, no API keys. The only credential is the entry's id: 32 random bytes (256 bits). You can't throttle-attack, or even address, an entry whose id you don't hold. The id is a bearer capability, not an identity.

Read the table by its one standout cell: among the systems compared here, VESlocker is the only row that's a check in both “hard lifetime guess cap” and “no special hardware.” Signal's SVR gets the cap by putting the throttle inside a secure enclave; OPAQUE and Pythia run on commodity servers but have no built-in attempt limit. VESlocker gets both by enforcing the throttle in ordinary application code — the trade-off being the last column: it trusts the operator, where an enclave would not.

• vs. OPAQUE / PAKEs — built for authentication; online guessing stays possible unless you bolt on rate limiting. VESlocker makes the exponential, lifetime-capped throttle the headline, for the narrower job of unlocking local data.
• vs. Signal's Secure Value Recovery — the closest cousin, but it enforces the attempt limit inside an SGX enclave, so it holds even against a malicious operator — at the cost of that hardware. VESlocker enforces the throttle in ordinary code on any host, trading operator-resistance for radical simplicity.
• vs. Pythia / Password-Hardened Encryption — an oblivious, rotatable PRF service: cryptographically stronger, more machinery. VESlocker's challenge is a plain hash (the server never receives the seed), in exchange for being SHA-256 and a counter column with nothing to install.

Security model

VESlocker is a key oracle gated by throttling, not a vault. Reason about it honestly before you deploy:

• ✓ The server can't read your data. It never sees the seed, the PIN, the plaintext, or the ciphertext — only an id and a challenge hash.
• ✓ No offline brute force. Whoever copies the ciphertext still can't test PINs offline: the key also requires the server's secret, which they don't have.
• ✓ Hard lifetime cap on online guesses. Exponential per-id throttling limits attacker and user alike to roughly 32 attempts, ever.
• ⚠ Availability dependency. Decryption needs the key server reachable — by design; it is what makes the throttle unavoidable.
• ⚠ Two-secret compromise. An attacker holding both the server's secret store and the ciphertext can brute-force the PIN offline, bounded only by PIN entropy. Protect the key server's database accordingly.

Terms of use

• VESlocker is part of the VESvault suite. The client library is open source (Apache-2.0) — embed and deploy it freely. The key server is source-available (PolyForm Perimeter 1.0.1): use, modify, and self-host it for any purpose except offering a product that competes with VESlocker.
• VESvault Corp lets anyone use the veslocker.com API endpoint and public JS library, as shown above.
• VESvault Corp reserves the right to enforce fair usage and to apply limits or restrictions on any party accessing the veslocker.com host.