Le chiffrement d'Ouraya Cloud et son modèle de menace

En bref

• Vos fichiers, leurs noms et ceux de vos dossiers sont chiffrés sur votre appareil, dans votre navigateur ou dans nos applications, avant d'être envoyés.
• Votre compte a une clé tirée au hasard, la charge de compte (64 octets). Elle est rangée dans des enveloppes : l'une s'ouvre avec votre mot de passe, une autre avec vos douze mots de récupération, et une par appareil inscrit.
• Nos serveurs ne reçoivent ni votre mot de passe, ni vos douze mots, ni la charge de compte. Ils gardent les enveloppes fermées.
• Dans le navigateur, le chiffrement n'emploie que les fonctions intégrées (WebCrypto) : AES-256-GCM, HKDF-SHA-256, PBKDF2-SHA-512, Ed25519, X25519, SHA-256 et HMAC-SHA-256.
• Ce chiffrement a des limites, décrites en fin de document : le programme du coffre en ligne vient de nos serveurs à chaque visite, nos serveurs voient des métadonnées, et un mot de passe facile à deviner peut tomber si nos données sont volées.

Ce que couvre ce document

Ce document couvre le coffre, en ligne et dans nos applications, ses liens de partage, et l'outil d'envoi offert de transfert.ouraya.cloud.

Il ne couvre pas le paiement, confié à Stripe, ni nos courriels. Ce que traitent nos prestataires est décrit dans notre politique de confidentialité.

Les noms de clés et les étiquettes cités ici sont ceux du code. L'application emploie un noyau écrit en Rust, qui relit les mêmes vecteurs d'essai que le code du navigateur.

Les primitives et leurs paramètres

L'aléa vient de crypto.getRandomValues, le générateur du navigateur.

Aucune bibliothèque de chiffrement n'est ajoutée : le module qui chiffre, public/app/coffre.js, n'importe que la liste des mots de récupération et une table Unicode.

La hiérarchie des clés

mot de passe ─ PBKDF2-SHA-512 ─► CM ─┬─ HKDF ─► CV   enveloppe « mot de passe »
 (650 000 tours, sel de 16 o)        └─ HKDF ─► GA   graine Ed25519 de connexion
douze mots, 128 bits ─ PBKDF2-SHA-512 ─► CR          enveloppe « douze mots »
 (650 000 tours, selCode de 16 o)
KA, 32 o tirés sur l'appareil ─ HKDF ─► CVA          enveloppe de cet appareil

Chaque enveloppe contient la même charge de 64 o : CC (32 o) ‖ CO (32 o)

CC, clé de compte ─┬─ HKDF ─► K_arbre       chiffre l'index
                   ├─ HKDF ─► K_meta        ferme la copie de CF de l'index
                   ├─ HKDF ─► K_journal     chiffre le journal
                   ├─ HKDF ─► G_signature   graine Ed25519 du journal
                   └─ HKDF ─► ak            preuve de possession de CC
CO, clé d'objets ─► ferme la copie de CF de l'en-tête de chaque fichier
CF, 32 o tirés à chaque tentative d'envoi ─► chiffre les blocs du fichier

Deux clés de 32 octets sont tirées au hasard dans votre navigateur à l'ouverture du compte : la clé de compte CC et la clé d'objets CO. Elles forment la charge de compte, 64 octets, qui ne change pas quand vous changez de mot de passe.

CO ne change jamais : elle ferme la clé de chaque fichier dans son en-tête, et la changer obligerait à réécrire tous les fichiers.

Les sous-clés de CC sont dérivées par HKDF-SHA-256 sous un sel fixe propre à votre compte, ouraya/coffre/v1| suivi de l'identifiant du coffre. Seule ak suit le sel du mot de passe : changer de mot de passe ne touche ni l'index ni le journal.

Chaque fichier a sa propre clé CF, tirée au hasard à chaque tentative d'envoi. Elle est rangée deux fois : fermée par CO dans l'en-tête du fichier, et fermée par K_meta dans l'index.

Avec CO seule, un fichier se rouvre depuis le stockage même si l'index était perdu. C'est une protection contre nos propres erreurs, pas contre un attaquant.

Les enveloppes

Une enveloppe est la charge de compte (64 octets) chiffrée en AES-256-GCM sous la clé de sa serrure, avec un nonce de 12 octets tiré au hasard. Le chiffré fait 80 octets : 64 de charge et 16 d'étiquette.

Les données associées (AAD) lient l'enveloppe à son compte et à ses paramètres : ouraya/enveloppe/v1, l'identifiant du coffre, le type, la version, le nom de la dérivation, son nombre de tours et son sel, et pour les douze mots le sel du code. Un serveur qui changerait le sel, baisserait le nombre de tours ou déplacerait une enveloppe vers un autre compte ferait échouer l'ouverture.

Le navigateur refuse aussi, avant toute dérivation, un nom de dérivation inconnu, moins de 650 000 tours, plus de 6 500 000 tours ou un sel de moins de 16 octets, quoi que réponde le serveur.

Pour remplacer une enveloppe, le serveur exige une preuve que l'on détient CC : ak, dont il ne garde que l'empreinte SHA-256.

Le mot de passe, et pourquoi pas Argon2id

Votre mot de passe est mis en forme Unicode NFKC, puis dérivé par PBKDF2-SHA-512 : 650 000 itérations, un sel de 16 octets tiré au hasard, 32 octets en sortie. Le résultat, CM, ne quitte pas votre navigateur.

À l'ouverture du compte, nous proposons un mot de passe de cinq mots tirés au hasard dans une liste de 2 048, soit environ 55 bits d'aléa. Un mot de passe choisi par vous doit compter au moins dix caractères.

Le document d'architecture du coffre retenait Argon2id réglé à 64 Mio, une dérivation qui exige de la mémoire. Nous ne l'employons pas : il aurait fallu l'ajouter au coffre en WebAssembly, et nous n'employons que les fonctions de chiffrement du navigateur.

Le coût de cet écart : PBKDF2 n'exige pas de mémoire, et un attaquant équipé de cartes graphiques en tire plus d'essais par seconde qu'avec Argon2id.

Ce coût ne pèse que si nos données sont volées. L'enveloppe du mot de passe n'est remise qu'après une connexion réussie, et chaque essai en ligne passe par nos limites : trente échecs par heure, par adresse et par réseau.

Chaque compte enregistre le nom de sa dérivation, pbkdf2-sha512-v1 : une autre dérivation pourrait s'ajouter sans toucher aux comptes existants.

Les douze mots

Les douze mots suivent BIP-39 : 128 bits tirés au hasard, plus 4 bits de contrôle (les 4 premiers bits de leur SHA-256), soit 132 bits, découpés en douze mots de 11 bits dans la liste française de 2 048 mots.

La clé CR est dérivée des 16 octets d'aléa, jamais du texte tapé : PBKDF2-SHA-512, 650 000 itérations, sous un sel de 16 octets distinct de celui du mot de passe. Une saisie sans accents ou en majuscules redonne donc la même clé.

Contre un code complet, ces itérations n'ajoutent rien : 128 bits sont hors de portée. Elles servent si une partie des mots a été vue : trois mots manquants laissent 2³³ possibilités, chacune 650 000 fois plus coûteuse à essayer.

Nous ne gardons pas les mots. Nous gardons l'enveloppe qu'ils ouvrent, et l'empreinte SHA-256 d'une preuve que HKDF tire de CR : elle montre, quand le coffre est refermé après une récupération, que les douze mots ont bien été tapés.

Pour rouvrir votre coffre avec vos douze mots, il faut aussi un code envoyé à l'adresse de votre compte : nous ne remettons l'enveloppe des douze mots qu'à qui le saisit. Après une récupération, de nouveaux douze mots sont tirés et les appareils inscrits sont retirés.

La connexion et la session

Pour vous connecter, votre navigateur ne nous envoie ni votre mot de passe, ni une valeur que l'on pourrait rejouer. Il dérive de votre mot de passe une clé Ed25519 et signe un défi : pour vérifier la signature, nous ne gardons que la clé publique.

Le défi fait 32 octets aléatoires et vit 120 secondes. Nos serveurs le marquent consommé avant de vérifier la signature : il ne sert qu'une fois.

Le message signé porte ouraya/auth/v1, l'origine https://ouraya.cloud, le défi et l'heure. Une horloge décalée de plus de 120 secondes est refusée.

Une adresse sans compte reçoit une réponse de même forme qu'une adresse qui en a un, avec un sel fictif mais stable : la page de connexion ne dit pas qui a un coffre.

Une connexion réussie ouvre une session : un jeton signé par nos serveurs en HMAC-SHA-256, valable quinze minutes et renouvelé pendant que vous vous servez du coffre. Ce jeton ne permet de rien déchiffrer.

Les clés vivent dans la mémoire de l'onglet, jamais dans un stockage du navigateur. Recharger la page les efface, et trente minutes sans activité ferment la session, sauf pendant un envoi.

Après trente échecs de connexion en une heure, depuis une même adresse électronique et un même réseau, les essais sont refusés ; au dixième échec, un courriel vous prévient.

Le format d'un fichier

Un fichier est découpé en blocs de 1 Mio (2²⁰ octets). Chaque bloc est chiffré en AES-256-GCM sous la clé du fichier CF, et grossit de 16 octets d'étiquette : 1 048 592 octets.

Le nonce d'un bloc est un préfixe de 8 octets, tiré avec CF, suivi du numéro du bloc sur 4 octets. Deux contenus différents ne sont jamais chiffrés sous la même clé et le même numéro : le code tient un registre des blocs de chaque tentative, et un fichier modifié repart sous une clé neuve.

Les données associées de chaque bloc portent l'en-tête du fichier, le numéro du bloc et un drapeau qui marque le dernier. Un bloc déplacé, un en-tête changé ou un fichier tronqué font échouer le déchiffrement.

L'en-tête fait 1 024 octets. Ses 256 premiers sont en clair mais authentifiés : version, taille des blocs, identifiant du fichier, préfixe de nonce, nombre de blocs, taille en clair, CF fermée par CO, engagement de clé. Les 768 suivants portent les métadonnées chiffrées : nom, type, dates et empreinte du contenu, complétées à taille fixe.

Ce remplissage à taille fixe cache la longueur du nom. La taille chiffrée d'un fichier, elle, donne sa taille réelle à seize octets par mébioctet près.

L'engagement de clé, HMAC-SHA-256 de ouraya/engagement/v1 sous CF, empêche qu'un même fichier chiffré s'ouvre en deux contenus sous deux clés différentes.

À la lecture, l'étiquette de l'en-tête est vérifiée avant toute allocation de mémoire, et l'identifiant du fichier doit être celui que l'on a demandé : un serveur qui servirait un autre fichier du même compte est refusé.

Une vignette d'image, quand il y en a une, est chiffrée sous la même clé, en 131 072 octets au plus. Elle n'est pas complétée à taille fixe.

L'index et le journal

La liste de vos dossiers et de vos fichiers est rangée chez nous en blocs chiffrés, un par dossier, sous des identifiants de 128 bits tirés au hasard. Ces identifiants paraissent dans les adresses du coffre et ne disent rien du contenu.

Chaque écriture d'un dossier tire un sel de 16 octets, d'où HKDF-SHA-256 tire une clé neuve sous K_arbre. La taille du bloc n'est pas masquée : elle suit le nombre d'éléments du dossier, 256 Kio au plus.

Chaque modification inscrit une entrée dans un journal : chiffrée sous K_journal, chaînée à la précédente par SHA-256, et signée en Ed25519 par une clé dérivée de CC. Pendant une session, le navigateur refuse un journal dont la tête recule.

Le navigateur ne garde rien d'une session à l'autre : à l'ouverture d'une session, il adopte la dernière tête signée que nos serveurs lui servent. Un serveur pourrait alors vous montrer un état plus ancien de vos dossiers, signé lui aussi par votre clé.

L'application pour ordinateur garde la dernière tête vérifiée dans le magasin de clés de son système, le Trousseau de macOS sur un Mac, et refuse un journal qui recule d'un lancement à l'autre.

Ce journal dit à nos serveurs quels dossiers chaque modification touche, et à quelle heure. Ses entrées sont gardées 180 jours au moins.

Les appareils

Une application s'inscrit comme appareil. Elle tire sa propre clé de 32 octets, KA, qui ne quitte pas l'appareil. Nos serveurs reçoivent sa clé publique Ed25519 et une enveloppe de la charge de compte, fermée sous une clé dérivée de KA.

Sur un Mac, KA est rangée dans le Trousseau de macOS. Ni votre mot de passe, ni la charge de compte, ni l'enveloppe n'y sont écrits.

Un compte porte dix appareils au plus. Retirer un appareil efface son enveloppe de nos serveurs : sa clé n'ouvre plus rien.

Le programme de l'application ne vient pas de nos serveurs à chaque ouverture : il est installé. Ses mises à jour automatiques ne s'installent que si elles portent la signature de notre clé de publication, épinglée dans l'application, et la signature Developer ID de notre équipe, notarisée par Apple.

La clé privée qui signe ces mises à jour n'est pas sur nos serveurs.

Sur un Mac à processeur Intel, l'application est en version bêta. C'est le même code, construit pour x86_64, signé par notre équipe et notarisé par Apple, avec sa propre image et ses propres mises à jour. Elle a été essayée sous Rosetta, sur un Mac à puce Apple, et pas encore sur un vrai Mac Intel.

Sous Linux, l'application est en version bêta. KA est rangée dans le service de secrets de la session, par le protocole Secret Service (GNOME Keyring, KWallet), sans repli vers un fichier. Un autre programme de la session peut l'y lire sans demande. Elle y passe par la conversation chiffrée du protocole : Diffie-Hellman sur 1 024 bits, HKDF-SHA-256, AES-128-CBC. Notre copie corrigée de dbus-secret-service 4.1.0 en tire le secret et les vecteurs d'initialisation du générateur du système, là où la bibliothèque d'origine employait fastrand, et refuse une clé publique hors de [2, p-2]. Ces tailles sont imposées par le protocole : la conversation reste sur le bus local de votre compte, ne porte aucun fichier et ne protège pas d'un programme de ce compte, qui peut demander la clé au service.

Ni l'AppImage, ni le .deb, ni le .rpm ne portent de signature de code. Les mises à jour de l'AppImage ne s'installent que si elles portent la signature de notre clé de publication. À partir de la 0.6.8, le .deb et le .rpm aussi, après le mot de passe d'un administrateur. Sous Linux, TLS s'appuie sur les autorités racines du système, sans contrôle de révocation. L'AppImage embarque les bibliothèques dont WebKitGTK a besoin, dont GnuTLS et libgcrypt : notre chiffrement ne les appelle pas.

Sur Android, l'application est en version bêta. Elle emploie le même noyau en Rust ; le seul chiffrement écrit à part est le scellement de KA : ses 32 octets, scellés en AES-256-GCM par une clé non exportable du magasin de clés d'Android, dans une puce à part si le téléphone en a une, sinon dans une zone isolée du processeur. Un téléphone sans cette protection matérielle n'est pas refusé, et l'écran le dit. Elle a été essayée sur un émulateur, jamais sur un vrai téléphone.

Sur Android, TLS s'appuie sur les autorités racines du système, sans contrôle de révocation, hors réponse agrafée par le serveur. À partir de la 0.1.5, elle se met à jour depuis ses réglages : Android demande de confirmer chaque installation.

Sous Windows, l'application est en version bêta. KA est rangée dans le Gestionnaire d'identifiants, en persistance locale, sans repli vers un fichier. Un autre programme de la session peut l'y lire sans demande, et un programme du même compte peut ouvrir l'inspecteur de la fenêtre au lancement suivant. Elle a été essayée sous Windows Server 2025, pas encore sous Windows 10 ni Windows 11.

L'installeur ne porte pas de signature de code. Ses mises à jour ne s'installent que si elles portent la signature de notre clé de publication : c'est le seul contrôle. Le processus qui lit le texte d'un PDF et réduit une image est cloisonné : ni vos fichiers, ni le réseau, ni les autres programmes. Cette cloison laisse lisibles les dossiers du système et ne filtre pas les appels au noyau. Sous Windows, TLS s'appuie sur CryptoAPI, le service du système.

Sur iPhone, l'application est en version bêta. Elle emploie le même noyau en Rust, par un pont vers Swift ; le seul chiffrement écrit à part est le scellement de KA : ses 32 octets, scellés par une clé P-256 créée dans le Secure Enclave, non exportable, par le schéma ECIES d'Apple : ECDH P-256 avec cofacteur, dérivation X9.63 sur SHA-256 et AES-GCM, dont la clé fait 128 bits pour une clé elliptique de cette taille. Le résultat est rangé dans le trousseau, ouvert après le premier déverrouillage, jamais synchronisé. Elle a été essayée dans le simulateur d'Apple, qui n'a pas de Secure Enclave et où KA est rangée sans scellement ; la construction pour l'iPhone n'a pas ce repli. Ce scellement n'a donc jamais été exécuté.

Sur iPhone, l'extension de l'app Fichiers, facultative, est un second appareil, avec sa propre KA, scellée de la même façon et rangée dans un groupe de clés que l'application et l'extension partagent ; la KA de l'iPhone n'y est pas. Un fichier ouvert depuis Fichiers est remis à iOS, qui en garde une copie en clair. Une vidéo se lit par blocs, chacun authentifié à son rang, sans vérifier l'empreinte du fichier entier. Si l'abonné le demande, les noms de ses dossiers et de ses fichiers sont remis à la recherche de l'iPhone, qui les garde en clair.

Sur iPhone, TLS passe par rustls, la chaîne étant évaluée par Security.framework, le service du système. L'application est signée par notre équipe, puis par Apple à la diffusion, et ses mises à jour passent par TestFlight : elle n'a pas de mécanisme à elle.

Les liens de partage

Un lien de partage du coffre a la forme https://cloud.ouraya.org/d/<identifiant>#<secret>. Le secret, 32 octets tirés au hasard, est dans le fragment, après « # », qui ne part dans aucune requête vers nos serveurs.

Du secret, le navigateur tire l'identifiant du lien, une preuve d'accès et, par HKDF, la clé du lien LK. Nous gardons l'empreinte SHA-256 de la preuve, jamais la preuve, et un bloc fermé sous LK qui contient la clé du fichier, son nom et son type.

Un lien peut porter un mot de passe : une seconde couche AES-256-GCM, sous une clé tirée de ce mot de passe par PBKDF2-SHA-512 à 650 000 itérations.

Pour les liens que créent le coffre en ligne, l'application pour Mac depuis sa version 0.6.3 et nos autres applications pour ordinateur, le sel de ce mot de passe est tiré du secret du lien : qui lit nos données sans le lien ne peut pas y essayer de mots de passe. Les liens plus anciens, et ceux créés par l'application pour Mac avant sa version 0.6.3, prennent pour sel l'identifiant du lien, que nous connaissons : qui lirait nos données pourrait y essayer des mots de passe hors ligne.

Un lien vers un dossier ou une sélection suit le même principe : la liste des fichiers, leurs noms et leurs clés sont chiffrés sous une clé rangée dans le bloc que ferme LK. Sans le secret du lien, elle ne s'obtient pas.

Le journal d'activité d'un lien est chiffré pour vous seul : chaque événement est fermé par une clé X25519 éphémère vers une clé publique de votre compte.

Désactiver un lien arrête les téléchargements par ce lien. Les copies déjà faites restent chez ceux qui les ont.

Nous n'envoyons jamais un lien de partage du coffre par courriel : son secret passerait par nos serveurs et par notre messagerie.

L'outil d'envoi

Chaque envoi a sa clé K, 32 octets tirés dans votre navigateur, qui voyage dans le fragment du lien. Le navigateur en tire l'identifiant de l'envoi, une preuve d'accès dont nous ne gardons que l'empreinte, et la clé du manifeste.

Le manifeste porte la liste des fichiers, leurs noms et votre message. Il est chiffré en AES-256-GCM et complété jusqu'au multiple de 4 096 octets suivant.

Les fichiers sont chiffrés dans le même format que ceux du coffre, sous une clé d'objets tirée pour l'envoi et rangée dans le manifeste.

Un mot de passe ajoute une couche : PBKDF2-SHA-512 à 650 000 itérations, puis HKDF sur le résultat mêlé à K. Sans le lien, nos données ne permettent pas d'essayer un seul mot de passe.

Si vous nous demandez d'envoyer le lien par courriel, il passe, clé comprise, par nos serveurs et par notre messagerie, et l'avis de non-remise qui nous revient quand une adresse le refuse peut en contenir une copie. Copier le lien vous-même évite ce passage.

Un envoi compte 100 Go et 500 fichiers au plus. Nous gardons un an, pour les seules demandes des autorités, un journal d'identification de l'expéditeur : nom et adresse indiqués, adresse IP complète, date.

La clé de réouverture, pas en service

La clé de réouverture est une option conçue mais pas en service : aucun compte n'en porte, et la table des clés publiques que le navigateur accepterait est vide.

Telle qu'elle est écrite, elle fermerait une enveloppe de plus vers une clé publique X25519 épinglée dans le navigateur. La clé privée se calculerait par HKDF-SHA-256 à partir de deux moitiés : l'une serait un secret de nos serveurs, l'autre une feuille de papier gardée hors ligne.

Activée, elle permettrait à Ouraya de rouvrir votre compte, donc de lire vos fichiers, et une décision de justice pourrait nous y contraindre. L'article 6 des conditions générales en fixe les règles.

Le modèle de menace

Pour chaque adversaire, ce qu'il obtient, et ce qu'il n'obtient pas.

Nos serveurs, pris par un attaquant

• Qui lit nos données obtient votre adresse électronique, vos enveloppes, leurs sels, la clé publique de connexion, l'index et le journal chiffrés, et les métadonnées listées plus bas.
• Il peut essayer des mots de passe sur ses propres machines. Chaque essai coûte 650 000 itérations de PBKDF2-SHA-512, mais un mot de passe facile à deviner finirait par tomber. Vos douze mots, 128 bits tirés au hasard, sont hors de portée.
• Il n'obtient ni le contenu de vos fichiers, ni leurs noms, tant qu'il n'a pas ouvert une enveloppe.
• Qui modifie le programme de nos serveurs peut servir au coffre en ligne un programme altéré, qui lirait votre mot de passe à la saisie et vos clés en mémoire. C'est la limite de tout chiffrement exécuté dans une page web.
• Il peut aussi refuser le service, effacer, ou mentir sur ce qu'il sert. Le navigateur repère un fichier servi à la place d'un autre, un fichier tronqué, une enveloppe altérée et un journal remis en arrière pendant une session ; il ne peut pas empêcher un effacement.
• L'application pour Mac n'exécute pas un programme servi par nos serveurs : les prendre ne suffit pas à lui faire installer une version altérée.

Cloudflare, notre prestataire américain de réseau et de stockage

• Cloudflare exécute notre programme serveur, sert nos pages, et garde votre compte, l'index et le journal chiffrés de vos dossiers. Vos fichiers y passent, chiffrés, sans y rester. Ce prestataire est désigné dans notre politique de confidentialité.
• Les connexions chiffrées vers nos adresses se terminent chez Cloudflare, qui voit donc vos adresses IP et les données de votre compte, comme votre adresse électronique, votre formule et votre facturation ; pour l'outil d'envoi, le nom et l'adresse de l'expéditeur et les adresses des destinataires.
• Vos fichiers et leurs noms ne parviennent à Cloudflare que chiffrés. Seule exception, la clé d'un envoi dont vous nous laissez envoyer le lien par courriel y passe aussi.
• Les fichiers déposés avec la première version de l'outil d'envoi, remplacée fin septembre 2026, n'étaient pas chiffrés, ni leurs noms. Cloudflare les garde jusqu'à leur effacement, trente jours après leur dépôt.
• Cloudflare a donc, techniquement, le pouvoir décrit pour nos serveurs, programme servi compris, sans avoir vos clés.

Notre hébergeur suisse

• Il garde les blocs chiffrés de vos fichiers, sur au moins trois supports dans deux centres de données, selon lui. Il voit leur taille, leurs dates, et des noms d'objets faits de l'identifiant de votre coffre et de celui du fichier ; le début de l'identifiant du coffre date son ouverture.
• Vos fichiers lui parviennent par nos serveurs : il ne voit pas votre adresse IP. Il n'a aucune clé.
• Il pourrait perdre ou altérer un bloc. Une altération se voit au déchiffrement ; une perte ne se répare pas, car nous ne gardons pas de seconde copie ailleurs.

Une personne de chez nous

• Une personne qui détient nos accès d'hébergement a le pouvoir d'une prise de nos serveurs : lire les métadonnées, modifier le programme servi, effacer.
• Ce que nous gardons ne permet de lire ni vos fichiers ni leurs noms : nous n'avons pas les clés.
• Nous détenons aussi les clés qui signent nos applications et leurs mises à jour. Une personne de chez nous qui en emploierait une à mauvais escient pourrait publier une version qui lise vos clés.

Une réquisition

• Nous ne pouvons remettre que ce que nous détenons : les données de votre compte décrites dans notre politique de confidentialité, et vos fichiers sous leur forme chiffrée.
• La clé de réouverture n'est pas en service : nous ne détenons rien qui ouvre un coffre.
• Si une personne nous transmet un lien de partage complet, nous pouvons ouvrir les fichiers de ce lien, et seulement ceux-là. Un lien de l'outil d'envoi que vous nous avez fait envoyer par courriel est passé par notre messagerie, clé comprise.
• Le chiffrement ne protège pas d'un programme modifié par nous-mêmes. Si nous y étions contraints, une version altérée du coffre en ligne, ou une mise à jour de l'application signée par notre clé, pourrait lire vos clés.

Quelqu'un qui prend votre appareil ou votre messagerie

• Un onglet où votre coffre est ouvert tient vos clés en mémoire : un appareil laissé déverrouillé, coffre ouvert, donne accès à vos fichiers.
• Votre messagerie seule ne suffit pas à rouvrir votre coffre : il faut aussi vos douze mots.
• Retirer un appareil depuis votre coffre efface son enveloppe. Un fichier déjà enregistré sur cet appareil y reste, et la charge de compte ne change pas : qui l'a déjà tirée de cet appareil la garde.

Ce qui fuit

Nos serveurs ont besoin de sept informations pour fonctionner. La page Sécurité les décrit ; les voici avec leur détail technique.

• Le nombre d'objets, la taille chiffrée de chacun et leur volume total.
• Les dates de dépôt et de lecture, et la partie d'un fichier que vous lisez.
• Une partie de la structure de vos dossiers, sans leurs noms : le journal note quels dossiers chaque modification touche, et à quelle heure.
• Votre adresse électronique, qui sert à vous identifier et à vous écrire.
• Votre adresse IP : complète dans les journaux techniques, sept jours au plus, et tronquée dans l'historique de vos sessions (le réseau /24 en IPv4, /48 en IPv6).
• Votre formule et son état de paiement.
• Les enveloppes de votre charge de compte, leurs sels, la clé publique qui vérifie votre connexion et l'empreinte de la preuve tirée de vos douze mots.

S'y ajoutent des signaux plus fins :

• La taille du bloc d'index de chaque dossier, qui suit son nombre d'éléments, et celle des vignettes.
• Pour un lien de partage : son identifiant, le fichier visé, le nombre de fichiers et le volume d'un lien de dossier, l'adresse IP et l'heure de chaque ouverture.
• Pour les appareils : leur nombre, leur système, les dates d'inscription, de passage et de retrait, le réseau /24 et le pays de chaque session.
• Pendant un envoi, trois empreintes à clé (HMAC-SHA-256) de passages du fichier, illisibles sans votre clé de compte, qui servent à reprendre un envoi coupé.

Les limites

• Le programme du coffre en ligne vient de nos serveurs à chaque visite. Vous lui faites confiance, comme à tout chiffrement dans un navigateur.
• PBKDF2 plutôt qu'Argon2id : un mot de passe faible résiste moins bien si nos données sont volées. Le mot de passe proposé à l'ouverture, cinq mots tirés au hasard, compte environ 55 bits.
• Après un changement de mot de passe, l'ancien ouvre encore votre coffre pendant vingt-quatre heures : nos serveurs servent encore l'ancienne enveloppe, qui ouvre la même charge de compte.
• La charge de compte ne change jamais. Changer de mot de passe, rouvrir avec vos douze mots ou retirer un appareil n'ôte pas l'accès à qui l'a déjà obtenue : avec vos fichiers chiffrés, elle suffit à les lire.
• Le coffre en ligne ne repère un journal remis en arrière que pendant une session. À l'ouverture d'une session, il adopte la tête signée que nos serveurs lui servent, même plus ancienne que celle de votre dernière visite.
• Perdre votre mot de passe et vos douze mots, sans appareil inscrit qui ouvre encore votre coffre, rend vos fichiers illisibles pour de bon. Rouvrir avec les douze mots demande aussi l'accès à votre messagerie.
• Le chiffrement ne masque ni la taille de vos fichiers, ni leur nombre, ni le rythme de vos modifications.
• Un lien partagé a voyagé : le désactiver n'efface pas les copies déjà faites.
• Un fichier ouvert ou enregistré sur votre appareil y est en clair : sa protection est alors celle de votre appareil.
• Vos fichiers sont stockés chez un seul hébergeur, qui annonce les garder sur au moins trois supports. Cela couvre une panne de matériel, pas une suppression par erreur, ni la fin de notre compte chez lui. Gardez une copie de vos fichiers importants ailleurs.

Les versions

Chaque paragraphe de ce document est rattaché, dans nos sources, au passage du code ou du document qui le vérifie ; un essai automatique refuse un paragraphe sans source.

Une phrase inexacte, une faille : écrivez-nous, comme l'indique la page Sécurité.