How secure is TEPHIA SECURE?
How your files are encrypted, what is stored on our servers – and what an attacker who took them over completely would get. No marketing speak, just transparency.
Encrypted in the browser
Your files are encrypted before they leave your computer and decrypted only at the recipient's end.
The key never reaches the server
Every transfer has its own random 32-character password. Our server never sees it.
Metadata for the proof
All we can read are details such as file names, addresses, dates and times. The proof of delivery needs them.
How encryption works
- PasswordYour browser creates a random password: 32 characters, about 190 bits.
- KeyArgon2id derives the key from it, which makes every guess expensive.
- EncryptAES-256-GCM encrypts the file and detects any later change.
- UploadOnly then does the file leave, via TLS 1.2 or 1.3. The password stays with you.
The password is not part of the link. You pass it on by a second route, for example in a separate email or by phone. Anyone who intercepts only the link cannot open the file.
Upload box
Anyone who uploads documents for you encrypts them in their browser in the same way. The server only knows a check value of the password, which cannot decrypt anything.
Exception: so that you can find the password again, we email it to you when the upload box is created. It passes through the server once and is not stored.
Outlook add-in
The add-in encrypts directly in Outlook. The password goes through your own email system, not through our server; the files themselves do not go through your email system.
Two ways: TEPHIA SECURE sends each recipient their own link and the password is in your email; or the link is in your email and the password follows in a second one. Anyone who has the link and the password can download the files – as with any delivery by email. With the second way, downloads can be restricted to the recipients' addresses; a code sent to their mailbox is then needed as well.
Technical details
- Key derivation: Argon2id with 64 MB of memory, 4 passes and 2 threads, followed by HKDF-SHA256
- Encryption: AES-256-GCM, with its own random salt (32 bytes) and IV (12 bytes) per transfer
- Encryption in blocks: the file is encrypted and uploaded in blocks of 8 MiB, each block with its own nonce (IV XOR block number); block number and a last-block flag as additional authenticated data (AAD) prevent blocks from being swapped, dropped or cut off. This makes files of up to 2 GB possible
- Without WebAssembly (blocked by a company policy, for example): PBKDF2-SHA512 with one million iterations
- Several files or folders are packed into a ZIP in the browser before encryption
- Transport: TLS 1.2 or 1.3 with forward secrecy, HSTS for two years, strict Content Security Policy
- Sign-in passwords: scrypt with an individual salt; a second factor is mandatory
What is on our server
Encrypted only, or not at all
- Contents of your files: encrypted only
- Password and key of a transfer: never
- Password of an upload box: only a check value
- Sign-in passwords: as a hash only
- Sign-in with Microsoft: nothing, that stays with Microsoft
- Payment details: nothing, they are held by Stripe
Readable, for the proof
- File names and sizes, for a ZIP also the names inside
- Label and message
- Sender with name, address and organisation
- Recipient addresses, if we send the link or downloads are restricted
- Dates and times, IP address and approximate location on download
- File checksums (SHA-256), computed in your browser
We send link emails to your recipients and notifications such as “Your file has been downloaded” via Microsoft 365 and Hornetsecurity (forwarding, virus and spam filtering). They contain no file names, only the label you choose yourself or the number of files; the password of a transfer is never in any of our emails. The proof of delivery PDF, which does contain the file names, is only attached if you switch this on in your account.
What if someone takes over the server?
We assume the worst case: an attacker has full control of the server, the database and the file storage.
What they would get
- Encrypted files currently on the server – unreadable without the password
- Metadata: who sent what to whom, when, file names and addresses. A name like "Divorce_Miller.pdf" gives something away.
What they would not get
- Contents of past transfers and upload boxes: the passwords were never on the server, and 190 bits cannot be brute-forced
- Deleted files: they are not in any backup either
- Microsoft passwords and payment details
How we guard against it
- Short retention: files are deleted after download. What is no longer there cannot be stolen.
- Code from one source: the web app loads its code only from our own server, and a strict Content Security Policy prevents injected code.
- Locked-down access: maintenance only with a key and only from fixed networks; organisations are additionally separated in the database.
- Notification in an emergency: if we detect a break-in, we inform the organisations affected without undue delay (Art. 33 GDPR).
How long would it take to crack an intercepted file?
Even with one billion graphics cards, an attacker would need about 4 × 1037 years on average.
Suppose someone intercepts an encrypted file – in transit or from the server. Without the password, all they can do is try one password after another. On average, this is how long it would take them:
For comparison: the universe is about 1.4 × 1010 years old. Even one billion graphics cards would need about 1027 times as long.
Why it takes so long
- Long random passwords: every transfer gets its own 32-character password, created in your browser. That is about 2.3 × 1057 possibilities (190 bits).
- Every guess is expensive: before a password can be checked, it has to go through Argon2id, with 64 MB of memory and four passes. This deliberately slows down graphics cards and specialised hardware.
- The key itself (AES-256), with 2256 possibilities, would be even harder to guess than the password.
And quantum computers?
As things stand, a quantum computer can at most halve the number of bits when trying every possibility. 190 bits would mathematically become 95, and every guess would still have to go through Argon2id. That, too, is far beyond any foreseeable computing power.
The figures are estimated generously in the attacker's favour and rounded to one significant figure. They are based on the average, i.e. half of all possibilities.
Realistic attacks therefore target the password, not the encryption: anyone who gets hold of the link and the password together has nothing to crack. That is why the two always travel by separate routes – see What you can do yourself.
Where the data is kept and for how long
What you can do yourself
- Send the password and the link separately, never in the same message.
- Sign in with Microsoft and switch password sign-in off, or use a security key or passkey.
- Choose neutral file names if the name itself is confidential.
- Restrict downloads to the recipients' addresses: then the link and password alone are not enough.
Limits we state openly
- Metadata such as file names, addresses, dates and times is readable for us; the proof of delivery needs it.
- An upload box password passes once through our server, Microsoft 365 and Hornetsecurity when the upload box is created.
- Microsoft and Hornetsecurity see what our emails contain: sender, label, your message, the link, dates and times – no file names and never the password of a transfer.
- The send check of the Outlook add-in is delivered by Cloudflare, so that sending email does not depend on our server being reachable. Cloudflare sees the IP address and browser identifier, no content.
- The checksum of each file is readable for us. It reveals no content, but shows whether a file someone already knows was transferred.
- As with any encryption in the browser, protecting new transfers depends on the code of the web app being delivered unmodified – which is why we protect the server itself with particular care.
Found a vulnerability? Please report it confidentially to the address in our security.txt.