Principe de fonctionnement
Le projet présenté sous forme de Show HN propose d’envelopper un fichier chiffré dans une page HTML capable de se déchiffrer localement, sans aucune connexion réseau. L’utilisateur charge la page sur un ordinateur isolé (« air‑gapped »), sélectionne le fichier chiffré et saisit la clé de déchiffrement. Le script JavaScript intégré effectue alors le processus de décryptage entièrement côté client, puis propose le téléchargement du résultat.
Cette approche repose sur l’idée que le navigateur, même en mode hors‑ligne, possède un moteur JavaScript suffisamment complet pour exécuter des primitives cryptographiques, ce qui élimine le besoin d’un outil externe dédié.
Architecture client‑side
Le cœur du système est un fichier HTML contenant du code JavaScript qui charge le binaire chiffré sous forme de ArrayBuffer. Le script utilise l’API Web Crypto (ou, à défaut, une bibliothèque polyfill) pour dériver une clé à partir du mot‑de‑passe fourni, puis applique un algorithme symétrique pour récupérer le contenu original. Le résultat est reconstituté dans la mémoire du navigateur et offert à l’utilisateur via un lien blob: généré dynamiquement.
Le processus évite toute écriture sur le disque tant que l’utilisateur ne déclenche pas le téléchargement, ce qui limite les traces résiduelles sur la machine isolée. Le modèle d’exécution reste strictement « client‑only », aucune requête HTTP n’est émise après le chargement initial de la page.
Enjeux de sécurité
Le principal avantage réside dans la réduction de la surface d’attaque : aucune dépendance serveur, aucune transmission de données sensibles. Cependant, la sécurité dépend entièrement de la robustesse du code JavaScript embarqué et de la mise en œuvre de l’API Web Crypto. Toute vulnérabilité dans le moteur du navigateur (exécution de code arbitraire, fuite de mémoire) pourrait compromettre la confidentialité du fichier.
De plus, la confiance repose sur l’intégrité du fichier HTML fourni. Dans un scénario air‑gapped, l’utilisateur doit s’assurer que le fichier n’a pas été altéré avant son importation, par exemple via une vérification de somme de contrôle hors ligne. L’absence de signature numérique ou de mécanisme de vérification intégré dans le projet augmente le risque de manipulation malveillante.
Limites et perspectives
Le projet ne fournit pas de métriques de performance, de tailles de fichiers supportées ou de détails sur les algorithmes exacts employés. Sans ces données, il est difficile d’évaluer la viabilité pour des volumes importants ou des environnements à ressources limitées. Le modèle repose également sur la disponibilité d’un navigateur moderne capable d’exécuter l’API Web Crypto ; les environnements plus anciens ou restreints pourraient ne pas être compatibles.
En l’état, la solution constitue une preuve de concept intéressante pour le transfert sécurisé de données vers des systèmes isolés. Des améliorations possibles incluent l’ajout d’une signature numérique du conteneur HTML, la prise en charge explicite de plusieurs algorithmes de chiffrement, et la publication de benchmarks quant à la charge CPU et à la consommation mémoire.
