Secure-link architecture

In secure-link mode, EasyBin uses a split-token design so the service does not receive the decryption secret. 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. In secure-link mode, the 256-bit encryption key is derived using HKDF-SHA-512 from the decryption half of the token, with the bin identifier as salt and a versioned application identifier as context info.

Authenticated Additional Data (AAD) binds secure-link ciphertext to the specific bin identifier and expiry timestamp. Any attempt to tamper with those values or the ciphertext causes 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. The live transfer record is removed immediately and any associated object-storage ciphertext is queued for deletion. A short retry window can retain encrypted response data for a failed network retry. Content also expires automatically through 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 failed attempts from one IP address within a 2-minute window trigger a 15-minute block for that IP on that PIN. 5 total failed attempts from any source within a 2-minute window trigger a 10-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.

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. Secure-link mode protects stored ciphertext from a server-side storage leak that does not include the URL fragment token. Quick PIN mode does not provide this protection because the PIN is intentionally its retrieval and decryption secret. Device compromise, unsafe link sharing, screenshots, and clipboard access on the recipient's device are outside server-side control.

How does EasyBin encrypt files?

All content is encrypted in your browser using AES-256-GCM before it reaches our servers. In secure-link mode, the encryption key is derived from a 64-byte token using HKDF-SHA-512, with the decryption half kept in your URL fragment.

Does the server see my decryption key?

No. In secure-link mode the decryption secret stays in your browser's URL fragment and never leaves your device. The server only stores a SHA-256 hash of the verification half for read authentication.

Is content deleted after retrieval?

Yes. Content is consumed on first successful retrieval — the paste record is deleted immediately and any R2 ciphertext is queued for deletion. Content also expires automatically through Durable Object alarms with a 15-minute cron safety net.

What is the difference between Quick PIN and Secure link?

Quick PIN mode uses a 4-12 digit PIN as both retrieval and decryption secret — convenient but the live PIN can retrieve before expiry. Secure link mode keeps the decryption secret in the URL fragment, protecting stored ciphertext from server-side leaks.

How long is content available?

Quick PIN and secure links expire 10 minutes to 7 days based on your selection. After retrieval the content is immediately destroyed. Terminal operational metadata is purged within 24 hours.

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.