Secure file delivery SECURE FILE DELIVERY

Encrypt sensitive files for a named recipient, with controlled access for legal, accounting, HR and compliance work.

01 / Encrypt and package files

Recipient public key · Base58

I checked the recipient's public-key fingerprint through a trusted channel Files to send · Up to 1 GiB per file

Add files from different folders, separately or in groups. The remove button only removes a list entry, not the original file. Rename files with duplicate names first.

Original authorization period · Hours, up to 7 days

Up to 3 claims. Access ends at the earlier of the original expiry or 24 hours after the first claim; later claims do not extend it. The third claim or expiry clears the server key share. A recipient who has claimed once can also destroy the remaining authorization.

02 / Deliver in three steps

Check delivery status

Delivery ID · You can paste a saved ID

Checking an ID does not claim a key share. Final status records remain available for 24 hours. Save the ID yourself; this page keeps no history.

The recipient sets up an identity, saves their passphrase and adds Google Authenticator. They share only their public key.
Check the public key, select the files and choose a new package location in the save dialog.
Send the .pafd package through an approved channel, such as work email or file storage. The recipient decrypts it on the receive page.

File contents and original names are encrypted in your browser, not uploaded. Compression, encryption and writing use chunks, so the whole file need not fit in memory.

Do not send passphrases, codes or revocation credentials with the package. Follow your organization's data classification, transfer and retention rules.

Problem, design and limits

Existing channels deliver the encrypted package. Public-key identity and a server-held key share control authorization.

Problem: how do you send a file without handing over everything needed to decrypt it?

Email and file storage deliver files but cannot, on their own, control who decrypts them or when authorization ends. Sending a passphrase alongside a file can expose both at once. Uploading the original file to a website also exposes its contents and name to that service.

File transfer and decryption authorization are separate. Verify the recipient's public key through a trusted channel, and keep passphrases, codes and revocation credentials out of the package delivery.

Design: local chunk encryption, .pafd delivery, then identity and TOTP authorization

The recipient saves their passphrase and sets up Google Authenticator, sharing only the public key. The sender checks its full fingerprint and creates a local .pafd package. Server authorization is created only after the package has been saved.

Argon2id, X25519, HKDF-SHA256 and AES-256-GCM handle identity derivation, key-share encapsulation and content encryption. Files use adaptive compression and encryption in 4 MiB chunks; the manifest and original names are also encrypted. The server stores key shares and delivery metadata, not packages.

Each file can be up to 1 GiB, with an original authorization period of up to 7 days and at most 3 claims. After the first successful claim, access ends at the earlier of the original expiry or 24 hours later. The third claim, expiry, revocation or blocking ends the remaining authorization.

Limits: claims are not file opens, and keeping an email does not preserve access

This relies on trustworthy page code, devices, public-key distribution and server key management. The SHA-256 transfer checksum detects damage; it does not authenticate the sender. AES-GCM authentication failure, cancellation or a write failure may occur after a claim. Claims are not refunded and are not retried automatically.

Keys already claimed and plaintext already saved cannot be recalled remotely. Revocation only stops future authorization. This tool is not an approval system, digital signature or compliance certification, and cannot stop a recipient copying files.

Use an approved email or storage channel to deliver packages. Keeping a copy does not extend authorization or restore destroyed key shares. Attachment limits and channel retention policies apply separately.

About this tool

Local file encryption and recipient-authorized transfer

What does this tool do?

Encrypt files and filenames locally, then share the encrypted package through your existing channels. Recipients use their passphrase and TOTP to obtain online authorization and restore files locally. Check fingerprints, query status or revoke unclaimed authorization.

How to use it

The recipient saves a passphrase and enrolls an authenticator, sharing only the public key. The sender checks its full fingerprint.
The sender encrypts and saves a file package locally, keeping revocation credentials separate.
Deliver the package through a trusted existing channel. The recipient claims authorization with their passphrase and TOTP and restores files locally.

Data handling and limits

Up to 1 GiB per file. Requires desktop Chrome/Edge with local folder access. The server retains necessary identity, delivery references, a key share and audit records, not file contents. Three claims do not limit how often saved files can be opened. Canceled or failed decryption does not refund a committed claim; revocation cannot recall saved material.

Related tools