Encryption protocol
GlobaLeaks implements an encryption protocol specifically designed for anonymous whistleblowing applications.
The protocol has been developed and validated in collaboration with the Open Technology Fund and represents a trade-off between security and usability. It is designed to be user-friendly for whistleblowers while providing reasonable protection against attackers attempting to breach the backend and perform brute-force decryption.
Encryption is applied to each submission, protecting answers to questionnaires, comments, attachments, and associated metadata. The encryption keys are assigned per user and per report, ensuring that only whistleblowers and their intended recipients can access the reports. This means that if users forget their passwords, they will lose access to the data in their accounts.
To enable users to recover their accounts in case they forget their passwords, the system includes a Key Recovery mechanism and provides each user with an Account Recovery Key. This measure ensures that users with their own Account Recovery Key can always restore access to their account and the data it contains.
To prevent data loss in case users lose both their password and their account recovery key, the system can be configured to use a Key Escrow mechanism. This delegates the responsibility of supporting users in recovering access to their accounts to administrators. This capability enhances the project’s resilience against data loss due to users’ death or conflicts of interest within the recipient team. However, it also means that administrators with access to escrow keys could potentially access other users’ accounts and data. Project owners should carefully decide whether to enable this feature based on the project’s threat model and document their decision in the project’s privacy policies.
Encryption’s workflow
Users choose a secure personal password during their first login using an account activation link.
The system creates a personal asymmetric keypair for each user and stores the private key symmetrically encrypted with a secret derived from the user’s password.
Each user’s private key is protected by the Key Recovery mechanism and, if enabled, by the Key Escrow mechanism.
The whistleblower files a report.
The system assigns a unique 16-digit receipt number to the whistleblower.
The system generates an asymmetric keypair for the whistleblower and stores the private key symmetrically encrypted with a secret derived from the whistleblower’s receipt number.
The system generates an asymmetric keypair for encrypting the report, attachments, comments, and associated metadata, and stores a copy of the private key encrypted for each involved user using their own public key.
The system encrypts the report, attachments, comments, and metadata with the public key generated for the report.
The system grants each involved user access to their reports and facilitates communication by automatically locking and unlocking the involved keys when a report is accessed or new communication is made.
Encryption’s details
Algorithms
Type |
Implementation |
|---|---|
Asymmetric encryption |
Libsodium SealedBoxes, which combines Curve25519, XSalsa20, and Poly1305 algorithms. |
Symmetric encryption |
Libsodium SecretBoxes, which combines XSalsa20 and Poly1305. |
Users’ credentials
The system uses two types of credentials depending on the user role:
Credentials type |
User role |
|---|---|
Passwords |
Used for authenticating users identified by a username |
Receipts |
16-digit random secrets used for authenticating anonymous whistleblowers |
Assumptions:
The system enforces strong password complexity.
The system enforces expiration of receipts according to a strict data retention policy that limits the number of concurrent active receipts.
Users’ keys
Type |
Generation |
Storage |
|---|---|---|
ECC Curve25519 keypair |
Generated by the backend during first user login for authenticated users and upon submission for whistleblowers |
Keys are stored on the backend encrypted using symmetric encryption. The symmetric key used for encrypting users’ keys is derived from the users’ credentials using the KDF function Argon2ID. The parameters for Argon2ID used for KDF are stronger than those used for user authentication, with the hash stored. The parameters are selected to require 128MB of memory per login and 1 second of computation. |
Data encryption’s keys
Type |
Generation |
Storage |
|---|---|---|
256-bit keys |
Generated by the backend for each report |
Keys are stored on the backend filesystem encrypted using asymmetric encryption with Users’ and Whistleblower’s keys, respectively. |
Key generation
Users’ encryption keys are automatically generated during the first login and secured using the user passphrase. This straightforward but effective key generation policy requires users to complete their first login before being able to receive reports.
Key recovery
The system implements a key recovery mechanism using a recovery key and symmetric encryption.
When a user key is generated, the private key is symmetrically encrypted with a randomly generated recovery key.
For usability reasons, this recovery key is also securely encrypted and stored on the backend, allowing logged-in users who possess their password to retrieve and print their own account recovery key.
Key escrow
The system offers an optional key escrow mechanism to mitigate data loss in the event of users losing their passwords.
Key escrow can be enabled during the initial application setup or in the advanced settings of the software.
We recommend enabling this option to protect whistleblowers’ submissions in cases where recipients lose their passwords. However, if you want to set up a system where only recipients can access submissions, we advise against using this feature.
When enabled, the system generates and assigns an escrow key to the administrator who activated the feature. This key is then used to encrypt every system key, with a copy preserved that any administrator with the escrow key can unlock.
Administrators with access to the escrow key can assist internal users with password recovery and issue password resets. They can also grant this privilege to other administrators or disable the feature entirely.