pock

sharing

applies to: one-off shares

Secure sharing

Pock sharing is end-to-end encrypted: the server stores ciphertext, never plaintext. The decryption key travels separately. Here's how the two-channel model works and what controls you have.

The two-channel model

Secure sharing faces a key distribution problem: if you use the same channel to send both the encrypted payload and the key, an observer who intercepts that channel gets both. Pock separates them deliberately.

  1. Channel 1 (server): Pock stores the ciphertext. The recipient fetches it using a short share ID. The server can see this retrieval.
  2. Channel 2 (you): The decryption key is included in the share link you send. It never touches the Pock server. You choose how to deliver it - Signal, email, Slack, in person.

An attacker who compromises the Pock server gets ciphertext but no key. An attacker who intercepts your message gets a key but no ciphertext. Both are required to reconstruct plaintext.

What you can share

Any file type: environment files, PEM certificates, SSH keys, binary archives, images, PDFs. Pock encrypts the raw bytes - it does not inspect content or impose type restrictions. The CLI handles stdin too, so you can pipe output directly into a share.

$ cat .env.production | pock share --stdin
✓ encrypted (XChaCha20-Poly1305)
  share id:  3kPq8vN2
  key:       pk_aQ7x9…Lr2
  link:      https://pock.sh/s/3kPq8vN2#pk_aQ7x9…Lr2
  expires:   24h

Cipher selection

Pock exposes three cipher options. The default is the post-quantum hybrid.

  • X-Wing + AES-256-GCM default

    Post-quantum hybrid KEM (X25519 + ML-KEM-768) encapsulates an AES-256-GCM data key. Secure against both classical and quantum adversaries. See post-quantum encryption.

  • AES-256-GCM

    Web Crypto API native. Quantum-resistant symmetric cipher. Universally hardware-accelerated.

  • XChaCha20-Poly1305

    Extended 24-byte nonce. Constant-time, no AES-NI dependency. Good choice for embedded or constrained environments.

All three are symmetric: the same key encrypts and decrypts. The post-quantum KEM applies to how the data key is encapsulated, not to the bulk cipher.

Controls and expiry

Shares can expire after a set time or burn after a number of reads.

Time limits

Every share has a TTL. The default is 24 hours. An automated hourly sweep hard-deletes expired ciphertext from storage - there is no soft-delete limbo. Choose a short window if the secret is time-sensitive.

Burn after read

With --burn, the share is deleted the instant it is first opened. The recipient gets one chance to decrypt and save the file. No re-reads. This is useful for one-time credentials or anything where you want strong delivery confirmation.

Recipient allow-lists

You can restrict which authenticated Pock accounts are permitted to open a share. An unauthenticated visitor or a signed-in user not on the list gets a 404 - they cannot even confirm the share exists. This is useful when sharing within a team where everyone has Pock accounts.

Receiving a share

$ pock receive 3kPq8vN2 pk_aQ7x9…Lr2 --out ./secrets
✓ fetched envelope · 1 file
✓ decrypted → ./secrets/.env.production

The recipient fetches the ciphertext, decrypts locally using the key from the link, and writes the file out. The key never leaves their machine. Pock's server is not involved in decryption.

Read more: zero-knowledge model, the CLI, or try a share now.