Post is designed so the relay can deliver your data without needing to read it.
Post protects message and file contents on the sender's computer before they are uploaded. The recipient decrypts them locally after download.
Protection begins before the relay
Post does not depend on the relay server keeping plaintext message or file content secret. Instead, the client prepares and encrypts the transfer before it leaves the sender's computer.
When the recipient retrieves the transfer, the Post client uses the recipient's local identity material to recover the transfer key, decrypt the payload, and restore the original content.
The basic flow
- Prepare the message or file locally.
- Compress the content when compression is useful.
- Encrypt the payload on the sender's computer.
- Upload the encrypted transfer to the relay.
- The recipient downloads the encrypted transfer.
- Decrypt and restore the content on the recipient's computer.
Each Post uses its own transfer key
Post generates a new random symmetric transfer key for a transfer. That key protects the encrypted message or file payload and is not stored with the payload in plaintext.
The transfer key is then protected for the intended recipient using the sender's identity key material and the recipient's public identity key. The recipient uses the corresponding private identity key to recover the transfer key locally.
Public identity key
A Post user's public identity key can be registered with the Post service so other Post clients can prepare encrypted transfers for that recipient.
Private identity key
The private identity key remains part of the user's protected local identity data. It is required to recover transfer keys intended for that Post identity.
Encryption also detects tampering
Post uses authenticated encryption for transfer payloads. If protected ciphertext, its nonce, or authenticated transfer data is altered, decryption fails rather than silently producing modified content.
This is important because confidentiality alone is not enough. A secure transfer also needs a way to detect whether protected data changed between sender and recipient.
Zero knowledge does not mean zero metadata
The relay needs enough operational information to route, store, expire, account for, and deliver a transfer. That means Post should not be described as a system where the server “knows nothing.”
The relay is not intended to have
- Plaintext message contents
- Plaintext file contents
- Recipient private identity keys
- The plaintext transfer key needed to decrypt the payload
The relay may process
- Sender and recipient routing identifiers
- Transfer identifiers and status
- Encrypted payload size
- Creation and expiration timestamps
- Usage and account-limit information
- Connection and operational information needed to run the service
Private identity material stays protected locally
Post stores identity information in encrypted local storage rather than ordinary clear-text configuration. Private identity keys are not intended to be placed in a normal TOML configuration file or sent to the Post relay as part of routine operation.
Your Post account key and your Post identity private key are different things. The account key represents account and plan entitlement. The identity private key is part of the cryptographic identity used to receive encrypted Posts.
Expiration limits how long the relay copy remains available
The sender can select a relay retention period from 1 through 30 days, with 15 days as the current default. When a transfer expires, the relay copy is no longer intended to remain available for retrieval.
Expiration does not remotely erase a copy that the recipient has already downloaded. Once someone legitimately receives and saves a file or message, Post cannot prevent that recipient from retaining or redistributing it.
Post protects the transfer path, not every possible endpoint risk
Post is designed to reduce exposure from
- A relay service needing plaintext access to transferred content
- Stored relay data being directly readable as ordinary files or messages
- Modification of authenticated encrypted transfer data going undetected
- Keeping transfer content on the relay indefinitely when a shorter TTL is appropriate
Post cannot protect you from
- A compromised sender or recipient computer
- Malware that can read content before encryption or after decryption
- Sending to the wrong Post name
- A legitimate recipient intentionally copying or redistributing content
- Losing control of local credentials or private identity material
post find <name> command confirms that a Post name exists; it does not by itself prove that the name belongs to the person you intend to contact.
Current implementation details
The current development implementation uses AES-256-GCM authenticated encryption for Post payloads and X25519 shared-secret derivation as part of protecting a transfer key for the recipient. Cryptographically secure random values are generated by the operating system through Go's cryptographic random source.
These details will be verified against the released client before they are treated as final product guarantees. Post is still under active development, so the public security description must continue to match the shipping implementation rather than an earlier design document.
Security is not a paid upgrade
Free, Personal, Pro, and Business plans use the same Post encryption and zero-knowledge transfer model. Paid plans change capacity, file-size limits, annual transfer allowance, Post-name limits, and network class—not the basic cryptographic protection of the transferred content.
Never send secrets to support
Utah Software support may ask for items such as your Post client version, operating system, Post name, transfer ID, timestamps, or the exact error message you received.
Never send private keys, passwords, account keys, decrypted confidential information, or the plaintext contents of a sensitive transfer to support.