Sécurité

Ce que DYCAST voit, et surtout ce qu’il ne voit pas

Tout est chiffré dans votre navigateur avant l’envoi. Le serveur reçoit des octets indéchiffrables et ne détient jamais la clé.

Le chemin d’un fichier

1. Votre navigateur tire au hasard une clé de 256 bits propre au transfert.
2. Chaque fichier est découpé en morceaux de 4 Mio, chiffrés un à un en AES-256-GCM avec une clé dérivée pour ce seul fichier (HKDF-SHA-256). Le numéro de chaque morceau et un repère « dernier morceau » sont scellés dans le chiffrement : impossible de retirer, d’intervertir ou de tronquer un morceau sans que le déchiffrement échoue.
3. Les noms, types et tailles des fichiers ainsi que votre message forment un manifeste, chiffré lui aussi.
4. La clé du transfert est enfermée dans une enveloppe chiffrée, que seul le secret d’accès ouvre :
   • lien — 256 bits placés après le # de l’adresse. Cette partie d’une URL n’est jamais transmise au serveur par les navigateurs ;
   • mot de passe — étiré par Argon2id (64 Mio de mémoire, 3 passes), conçu pour rendre les essais massifs ruineux ;
   • demande de fichiers — échange de clé hybride X-Wing : ML-KEM-768 + X25519.
5. À la réception, votre destinataire déchiffre et vérifie l’intégrité de chaque morceau au fil du téléchargement, sans que le fichier en clair passe par nos serveurs.

Post-quantique, concrètement

Un ordinateur quantique menacerait surtout la cryptographie à clé publique (RSA, courbes elliptiques) : c’est elle que l’on remplace.

• Demandes de fichiers : la clé publique du demandeur est une clé X-Wing, qui combine ML-KEM-768 (standard NIST FIPS 203, résistant au quantique) et X25519 (éprouvé). Il faudrait casser les deux pour lire un dépôt. L’empreinte de cette clé est dans le lien de dépôt : un serveur malveillant ne pourrait pas la remplacer par la sienne.
• Envois par lien ou par mot de passe : aucune clé publique n’intervient. Tout repose sur des clés symétriques de 256 bits et sur SHA-256, que l’algorithme quantique de Grover ne fait que ramener à 128 bits de sécurité — hors de portée.
• Transport : la connexion HTTPS passe par Cloudflare, qui négocie l’échange de clés hybride X25519MLKEM768 avec les navigateurs récents.

Ce que le serveur connaît

• l’adresse e-mail vérifiée de l’expéditeur, celles des destinataires en mode e-mail (effacées à l’expiration) ;
• le nombre de fichiers et la taille chiffrée de chacun, les dates, le nombre de téléchargements ;
• une empreinte de « preuve d’accès » : le serveur ne remet les octets chiffrés qu’à qui la présente ; un accès par mot de passe est suspendu une heure après dix essais faux. Avoir l’adresse sans la clé ne permet même pas de récupérer le chiffré.

Il ne connaît ni la clé, ni les noms de fichiers, ni le contenu, ni votre message. Les adresses IP ne sont conservées que sous forme d’empreinte, pour les plafonds anti-abus.

Le site lui-même

• Aucun script, police ou image tiers : tout est servi depuis transfert.dycast.pro, sous une politique de sécurité de contenu stricte (Trusted Types, aucun script en ligne, aucun cadre externe).
• Bibliothèques cryptographiques auditées noble (post-quantum, curves, hashes) figées à une version et vérifiées par leur empreinte, et l’API WebCrypto du navigateur.
• HSTS, isolation d’origine (COOP/COEP), aucun référent transmis, cookie de session __Host- limité au site.
• Fichiers effacés automatiquement à l’expiration ou dès que vous les supprimez.

Ce que le chiffrement ne fait pas

Quiconque obtient le lien complet (et le mot de passe s’il y en a un) peut ouvrir le transfert : partagez-le avec soin, préférez la limite « 1 téléchargement » pour les envois sensibles, et transmettez un mot de passe par un autre canal que le lien. Un appareil compromis, chez l’expéditeur ou le destinataire, reste hors de portée de toute cryptographie.