Cryptographie

📅 Source et contexte : Article technique publié le 20 juillet 2026 sur le blog officiel de Mozilla (hacks.mozilla.org), en complément d’une mise à jour sur le projet Distilled. Il s’inscrit dans le cadre d’une réflexion sur la tension entre protection de la vie privée des utilisateurs et lutte contre les abus de bots sur le web ouvert. 🔍 Problème identifié : Les mécanismes anti-abus actuels (CAPTCHAs, fingerprinting passif, murs d’inscription) échouent doublement : les protections de vie privée des navigateurs démantèlent les signaux passifs utilisés par les systèmes anti-abus, tandis que les IA génératives résolvent les CAPTCHAs plus vite et plus fiablement que les humains. Les sites migrent vers des mécanismes plus invasifs (email, login fédéré, désactivation du VPN), aggravant le compromis vie privée / accès. ...

Selon Trail of Bits (blog), dans une analyse publiée en février 2026, deux bibliothèques populaires, aes-js (JavaScript) et pyaes (Python), exposent leurs utilisateurs à des failles cryptographiques en fournissant un IV par défaut en mode AES-CTR, ce qui a entraîné des vulnérabilités dans de nombreux projets en aval, dont strongMan (outil de gestion pour strongSwan), qui a été corrigé. Problème central: IV par défaut (0x00000000_00000000_00000000_00000001) en AES-CTR dans aes-js et pyaes, avec des exemples de documentation omettant l’IV. Cela favorise la réutilisation clé/IV, permettant la récupération de l’XOR des textes en clair et rendant le chiffrement très fragile (récupération de masques et secrets en chaîne). ...

Selon l’annonce du projet ReMemory (open source sur GitHub), un nouvel outil permet de chiffrer des fichiers puis de répartir la clé de déchiffrement entre des proches via Shamir’s Secret Sharing, avec récupération hors‑ligne dans le navigateur. 🔐 ReMemory chiffre un fichier, scinde la clé en plusieurs parts et permet de la recomposer lorsque le seuil défini est atteint (exemples donnés : 3‑sur‑5 pour un groupe d’amis, 2‑sur‑2 pour un couple). Différentes combinaisons de détenteurs peuvent ainsi restaurer la clé et déchiffrer le fichier. ...

Selon WIRED (Andy Greenberg), Nicholas Merrill — connu pour avoir combattu un National Security Letter du FBI — lance Phreeli, un opérateur mobile virtuel (MVNO) aux États-Unis qui promet un niveau d’anonymat inédit pour la téléphonie mobile. Phreeli vise l’anonymat plutôt que la simple confidentialité du contenu: l’inscription ne requiert qu’un code postal (exigence fiscale minimale), séparant l’identité de l’activité réseau. Contrairement aux messageries chiffrées (Signal, WhatsApp) centrées sur le contenu et parfois la métadonnée, Phreeli minimise les données client afin de ne rien pouvoir livrer aux autorités ou aux courtiers de données. ...

Source : openssh.com. Le projet OpenSSH détaille l’adoption des algorithmes d’échange de clés post‑quantiques pour SSH, le changement de défaut vers mlkem768x25519-sha256, et l’introduction en 10.1 d’un avertissement lorsque la connexion n’emploie pas de schéma post‑quantique. Depuis OpenSSH 9.0 (avril 2022), un échange de clés post‑quantique est proposé par défaut via sntrup761x25519-sha512. En OpenSSH 9.9, mlkem768x25519-sha256 a été ajouté et est devenu le schéma par défaut en 10.0 (avril 2025). En OpenSSH 10.1, un avertissement informe l’utilisateur si un KEX non post‑quantique est sélectionné, signalant un risque d’attaque « store now, decrypt later ». Cet avertissement est activé par défaut et peut être désactivé via l’option WarnWeakCrypto dans ssh_config(5). Contexte et menace : des ordinateurs quantiques suffisamment puissants pourraient casser certains schémas cryptographiques classiques. Même s’ils n’existent pas encore, les sessions SSH peuvent être collectées aujourd’hui et déchiffrées plus tard (attaque « store now, decrypt later »), d’où la nécessité d’algorithmes post‑quantiques pour l’accord de clés. ...

L’article analyse le ransomware Secp0, apparu début 2025, qui a initialement été mal compris comme un groupe d’extorsion de divulgation de vulnérabilités, mais qui fonctionne en réalité comme un ransomware traditionnel à double extorsion, chiffrant les données tout en menaçant de les divulguer publiquement. Secp0 a été identifié pour la première fois en février 2025 et a revendiqué sa première victime en mars 2025, une entreprise IT américaine, en compromettant des données et en chiffrant des serveurs. En mai 2025, Secp0 a retardé ses publications, citant une file d’attente de sociétés et testant une solution logicielle, probablement la plateforme d’extorsion World Leaks. ...