Inboxes
An inbox is a directory in a user's Vault that someone outside tiCrypt can deliver files into. The sender needs no tiCrypt account, no credentials of their own, and no access to anything else in the deployment. They can put files in; they cannot read what is already there, and they cannot read back what they sent.
This solves a problem that ordinary tiCrypt use does not. A collaborator at another institution, an instrument that emits data files, or a partner sending a restricted dataset all need a way in, and none of them should be given an account inside the enclave to get it.
Why an inbox is safe to expose
Every file is encrypted on arrival, with the public key of the tiCrypt user who owns the inbox. From that moment the contents are readable only by that user, who holds the matching private key. The service that received the file cannot read it, and neither can an administrator with access to the storage underneath.
The two services that accept inbox traffic run outside the external firewall with a one-way path to the REST frontend. Neither can reach the internal network, the distributed file system, or a compute node. That containment, plus encryption on arrival, is what makes it acceptable to expose them to the internet. See Architecture for where they sit.
The two kinds
A user creates an inbox and then opens one or more access points on it. The access point decides how the sender delivers files.
| URL inbox | SFTP inbox | |
|---|---|---|
| The sender gets | A link | A link that issues SFTP credentials |
| They deliver with | A web browser | Any SFTP client |
| Served by | ticrypt-mailbox | ticrypt-sftp |
| Default port | 443, behind Nginx | 2022 |
| Suits | One-off transfers, senders who will not install software | Large transfers, directory trees, scripted or repeated delivery |
URL inbox. The recipient copies a link and sends it to the uploader through a separate channel, such as email. Opening the link gives the uploader a page showing who opened the inbox for them, the expiration date, the remaining capacity, and a message from the recipient. They select or drag files and upload. Nothing is installed.
SFTP inbox. Opening the link generates a one-time SFTP username and password for that sender, valid for a limited period. They use those credentials with any SFTP client to transfer files, which is what makes this the right choice for large volumes and for directory structures that a browser upload handles poorly.
Both kinds carry an expiration date and a capacity limit, and both deliver into the same directory in the recipient's Vault.
Which one to deploy
Deploying one does not require the other, and most institutions run both because the choice belongs to the person receiving the data rather than to the administrator.
- Run
ticrypt-mailboxif users need to accept files from senders who cannot be asked to configure an SFTP client. - Run
ticrypt-sftpif users receive large datasets, whole directory trees, or repeated automated deliveries.
ticrypt-sftp additionally serves administrator-provisioned SFTP accounts, which are separate from
inboxes and documented on its configuration page.
For the people using them
Creating an inbox, opening an access point, and sharing the link are user tasks, not administrator tasks. They are documented in Inboxes in the user guide.