Security

Zero-knowledge architecture

EasyBin uses a split-token design so the server can never decrypt your content, even if fully compromised. When you share content, your browser generates a 64-byte random token and splits it in half:

The first 32 bytes are the verification half. A SHA-256 hash of this half is sent to the server to authenticate retrieval requests. The server never sees the raw verification bytes.

The second 32 bytes are the decryption half. This half never leaves your browser. It is used to derive the encryption key via HKDF. The server never receives it in any form.

Both halves are combined into the share link's URL fragment (after the #), which browsers do not send to servers. The recipient's browser splits the token again to verify and decrypt locally.

Encryption

Content is encrypted with AES-256-GCM, a widely trusted authenticated encryption algorithm. The 256-bit encryption key is derived using HKDF-SHA-512 from the decryption half of the token, with the PIN as salt and a versioned application identifier as context info.

Authenticated Additional Data (AAD) binds the ciphertext to the specific PIN and expiry timestamp. Any attempt to tamper with the PIN, expiry, or ciphertext will cause decryption to fail.

Encrypted metadata

In v2, all content metadata — content type, file name, and file size — is encrypted inside the ciphertext. The server stores only the encrypted blob, the IV, and the algorithm identifier. No cleartext metadata about your content is ever stored on or visible to the server.

Token strength

Each token is 64 random bytes (512 bits), generated using the browser's cryptographically secure random number generator. The 32-byte decryption half provides 256 bits of key material. Under Grover's algorithm, a quantum computer would reduce this to 128-bit equivalent security, which remains well beyond feasible attack thresholds.

One-time retrieval

Content is consumed on first successful retrieval. Once the decrypted payload is returned to the recipient, the stored record is deleted immediately and any associated object storage is queued for removal. Content also expires automatically on a schedule, enforced by Durable Object alarms with a cron safety net.

Rate limiting

Failed retrieval attempts are rate-limited at two levels to protect against brute-force attacks on the short human PIN:

Per-PIN limits: 3 attempts per IP address within a 10-minute window trigger a 30-minute block for that IP. 8 total failed attempts from any source within a 10-minute window trigger a 30-minute block for the entire PIN.

Global IP limits: 8 failed attempts from the same IP address across all PINs within a 15-minute window trigger a 45-minute block for that IP across the entire service.

All failure responses include random timing jitter to prevent timing-based side-channel analysis.

Minimal external dependencies

All fonts are self-hosted. EasyBin uses a first-party signed challenge with a short client-side proof of work to slow abuse without sending your browser to a third-party verification service. No analytics or tracking scripts are loaded by default.

Quick PIN versus secure link

EasyBin now supports two security models. Quick PIN is the fast path for moving content between your own devices: the live 4-digit PIN is enough to retrieve the encrypted payload once before expiry.

Secure link is the stronger path: the decryption secret stays in the URL fragment, the server never receives the full secret, and the content cannot be decrypted from server-side storage alone.

What this does not protect against

If someone has your full share link, they can retrieve and decrypt the content. EasyBin protects against server-side breaches because a compromised server cannot decrypt stored content without the URL fragment token. However, device compromise, unsafe link sharing, screenshots, and clipboard access on the recipient's device are outside server-side control.

Report security concerns

Send reports to security@easybin.xyz with an impact summary, reproduction steps, and affected endpoints. Do not include payload data in reports. We aim to respond within 72 hours.