transparence

Ce qu'IronTransfer ne peut pas voir

On préfère vous dire exactement comment ça marche plutôt que de faire des promesses marketing.

Chiffrement de bout en bout

Chaque transfert est chiffré dans votre navigateur avec une clé AES-256-GCM générée localement. Le serveur reçoit uniquement le ciphertext et n'a aucun moyen de le déchiffrer.

Où vit la clé

  • Sans mot de passe : la clé est placée dans le #fragment de l'URL. Les fragments ne sont jamais envoyés au serveur par les navigateurs.
  • Avec mot de passe : la clé est wrappée par PBKDF2-SHA256 (600 000 itérations) et le mot de passe ne quitte pas le client.
  • Transfert nominatif : la clé est wrappée par la clé publique RSA-4096 du destinataire. Seul lui peut la déwrapper avec sa clé privée stockée chiffrée.

Métadonnées visibles côté serveur

On essaie de minimiser, mais voici ce qu'on stocke en clair :

  • Le slug (identifiant court) et la date d'expiration
  • La taille des fichiers chiffrés (pas leur contenu)
  • Le nombre de fichiers et le compteur de téléchargements
  • L'expéditeur (compte authentifié) et la date d'envoi

On ne stocke pas les noms de fichiers, les types MIME, les contenus, l'adresse IP des téléchargeurs, ni l'identité du destinataire (sauf transfert nominatif).

Aperçus sécurisés

Les images, PDF, vidéos, audios et fichiers texte se prévisualisent dans votre navigateur après déchiffrement local. Aucune version en clair ne transite par notre infra.

Modèle de menace — ce qu'on ne couvre pas

  • Compromission du navigateur du destinataire (malware, extension malveillante).
  • Partage du lien complet (avec fragment) sur un canal non sûr.
  • Mot de passe faible : la dérivation PBKDF2 ralentit le brute- force mais ne le rend pas impossible.

Empreinte de clé (SAS)

Quand vous partagez un lien, IronTransfer dérive une empreinte courte (6 mots) du matériel cryptographique. Communiquez-la hors- bande (SMS, appel, en face) au destinataire pour qu'il vérifie que ce qu'il reçoit correspond bien à ce que vous avez envoyé.

Détails techniques vérifiables

Faits extraits directement du module crypto isolé du projet. Si une mention ici diffère du comportement réel, c'est un bug — signalez-le via /.well-known/security.txt.

Primitives

Chiffrement contenuAES-256-GCM · IV 96 bits aléatoire · tag 128 bits
Dérivation mot de passePBKDF2-HMAC-SHA256 · 600 000 itérations · sel 16 octets
Clés de compteRSA-OAEP 4096 bits · SHA-256 · e = 65537
Wrapping clé (nominatif)RSA-OAEP avec clé publique destinataire
Source d'aléacrypto.getRandomValues (CSPRNG navigateur)
Empreinte SASSHA-256 → 6 mots (wordlist 63 entrées)
ImplémentationWebCrypto natif (aucune lib JS custom, aucun polyfill)

Transport de la clé

Sans mot de passe#k=<base64> dans le fragment URL
Avec mot de passe#s=<salt>&i=600000 → KEK dérivée localement
Nominatifclé wrappée RSA-OAEP, déwrap par clé privée du destinataire

Ce que le serveur stocke littéralement

transfers.slugidentifiant court public
transfers.expires_atdate d'expiration
ciphertext_sizetaille des blobs chiffrés
sender_idUUID du compte expéditeur
download_countcompteur d'accès

Jamais stockés : mot de passe, clé symétrique, clé privée en clair, nom de fichier, type MIME, contenu, adresse IP (ni en clair ni hashée).

Audit externe

Pas encore réalisé. Le code crypto est isolé dans un seul module court et auditable. On préfère l'annoncer plutôt que laisser entendre le contraire. Un audit indépendant est sur la roadmap.

Contact sécurité : /.well-known/security.txt

← Retour à l'accueil