Optional E2E encryption: paste/file content encrypted client-side in the browser before upload; server stores only ciphertext; retrieval decrypts client-side with the password-derived key (e.g. WebCrypto AES-GCM, key derived via PBKDF2/Argon2 from the paste password). Server never sees plaintext or the password. Research client-side crypto flow, key derivation, and how it interacts with password lock, raw endpoints, and API access. No implementation yet.
DECISIONS (2026-09-09, user confirmed):
E2E is web-UI only. API support for encrypted pastes is out of scope; the API docs will state that clearly.
All limitations are accepted: no server-side highlight/search/preview on encrypted pastes, password unrecoverable, raw serves ciphertext (or a client-decrypted download).
A short end-user document + in-UI notice will explain the quirks (what breaks, password loss is permanent, cookie-less viewers, raw behavior).
Implementation: new encrypted flag, WebCrypto AES-GCM + PBKDF2 client-side, ciphertext in content field (or blob table when files land). Encrypt flow on create, decrypt-on-view in paste.html.
STATUS: design complete. Implementation deferred until file/image attachments (#38) are built, then implemented together (shared crypto module).
Optional E2E encryption: paste/file content encrypted client-side in the browser before upload; server stores only ciphertext; retrieval decrypts client-side with the password-derived key (e.g. WebCrypto AES-GCM, key derived via PBKDF2/Argon2 from the paste password). Server never sees plaintext or the password. Research client-side crypto flow, key derivation, and how it interacts with password lock, raw endpoints, and API access. No implementation yet.
DECISIONS (2026-09-09, user confirmed):
- E2E is web-UI only. API support for encrypted pastes is out of scope; the API docs will state that clearly.
- All limitations are accepted: no server-side highlight/search/preview on encrypted pastes, password unrecoverable, raw serves ciphertext (or a client-decrypted download).
- A short end-user document + in-UI notice will explain the quirks (what breaks, password loss is permanent, cookie-less viewers, raw behavior).
- Implementation: new `encrypted` flag, WebCrypto AES-GCM + PBKDF2 client-side, ciphertext in content field (or blob table when files land). Encrypt flow on create, decrypt-on-view in paste.html.
STATUS: design complete. Implementation deferred until file/image attachments (#38) are built, then implemented together (shared crypto module).
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Optional E2E encryption: paste/file content encrypted client-side in the browser before upload; server stores only ciphertext; retrieval decrypts client-side with the password-derived key (e.g. WebCrypto AES-GCM, key derived via PBKDF2/Argon2 from the paste password). Server never sees plaintext or the password. Research client-side crypto flow, key derivation, and how it interacts with password lock, raw endpoints, and API access. No implementation yet.
DECISIONS (2026-09-09, user confirmed):
encryptedflag, WebCrypto AES-GCM + PBKDF2 client-side, ciphertext in content field (or blob table when files land). Encrypt flow on create, decrypt-on-view in paste.html.STATUS: design complete. Implementation deferred until file/image attachments (#38) are built, then implemented together (shared crypto module).
Design phase complete: #75 merged (docs/design/). Implementation remains open.
Deferred for now per owner decision - not in the v0.4.0 cycle. Revisit after the file attachment flow has been in production for a while.