Subprocessors
| Subprocessor | Purpose | Location | Data processed |
|---|---|---|---|
| Hetzner Online GmbH | Infrastructure hosting, backups, networking | Nuremberg, Germany | Application data, database, file uploads, logs |
| Scaleway SAS | Key Management Service (envelope encryption) | Amsterdam, Netherlands | Encrypted key material and AAD |
| IONOS SE | Transactional email delivery | Germany | Email addresses, message content |
| Plausible Insights OÜ | Website analytics (no cookies, no IPs) | Tartu, Estonia | Non-personal usage data |
| Paddle.com Market Ltd | Payment processing, subscriptions, invoicing | London, United Kingdom | Billing address, payment method, transaction history |
Paddle acts as an independent data controller for payment processing and as a processor for subscription management on our behalf. App-side analytics are self-hosted on our own infrastructure and do not leave the Hetzner servers.
Optional authentication providers
These providers are not subprocessors. They act as independent data controllers when a customer chooses to sign in through them.
| Provider | Purpose | Location |
|---|---|---|
| Google (Google Ireland Ltd) | OAuth sign-in | Dublin, Ireland |
| GitHub (GitHub, Inc.) | OAuth sign-in | San Francisco, USA (EU-US DPF) |
| GitLab (GitLab B.V.) | OAuth sign-in | Utrecht, Netherlands |
Organizations on the Business plan may also configure a custom OpenID Connect provider. The IdP is chosen and controlled by the customer.
Transport security
All traffic between your browser and RecoveryCodes is served over TLS 1.3. For clients that support it (current Chrome, Firefox, and other browsers built on OpenSSL 3.5+), we negotiate the NIST-standardized post-quantum hybrid key exchange X25519MLKEM768, which combines ML-KEM-768 with X25519. This protects the confidentiality of your session against a “harvest-now, decrypt-later” adversary that records ciphertext today in the hope of decrypting it on a future quantum computer. Older clients continue to negotiate classical X25519 and connect normally.
You can verify the negotiated group yourself:
openssl s_client -connect recoverycodes.eu:443 \
-servername recoverycodes.eu \
-groups X25519MLKEM768:X25519 -tls1_3 -brief </dev/nullCertificate chain signatures, WebAuthn passkey signatures, and OIDC token signatures still use classical algorithms (ECDSA, RSA, EdDSA). These depend on the CA/Browser Forum, the FIDO Alliance, and the IETF respectively, and we will adopt post-quantum signature algorithms as those ecosystems standardize them.
Encryption at rest
Recovery codes are stored using envelope encryption. The plaintext payload of each record is encrypted with a freshly generated 256-bit data-encryption key (DEK) under AES-256-GCM. Each DEK is then wrapped by Scaleway KMS (AES-256-GCM) and stored alongside the ciphertext. The KMS wrapping key never leaves Scaleway; every unwrap operation is a discrete, logged API call.
AES-256 remains secure against the best known quantum attacks. Grover’s algorithm reduces its effective strength to roughly 128 bits, which is still well above the practical security threshold. No changes to the at-rest cryptography are required for post-quantum readiness.