Ad Nihilum 0.4.3

La version 0.4.3 d'Ad Nihilum a été lancée — un service minimaliste pour l'échange de messages chiffrés sur le principe « lu — brûlé », principalement destiné au self-hosting.

Le serveur agit simplement comme un stockage aveugle. Le chiffrement et le déchiffrement se font exclusivement côté client, dans le navigateur (via AES-GCM).

Caractéristiques

  • chiffrement et déchiffrement local, serveur ne voit jamais la clé;
  • support d'une couche de chiffrement supplémentaire par mot de passe, dont (1) le serveur ne peut pas avoir connaissance, (2) ne peut pas être déduit à partir du lien transmis;
  • le projet contient environ 2200 lignes de code serveur en C et 600 lignes de code client en JS, ce qui facilite l'audit;
  • Ad Nihilum dépend uniquement de libmicrohttpd. Une version modifiée de QRCode.js est fournie pour générer des codes QR;
  • un guide pour configurer rapidement le service local sans IP externe est inclus;
  • Ad Nihilum fonctionne également sur Android, un script correspondant est inclus pour la compilation dans Termux;
  • serveur à thread unique et synchrone.

Changements

Refonte à grande échelle

  • Les pages d'envoi et de réception de messages ont été séparées, le code client correspondant.
  • Le design a été considérablement modifié et ajusté en fonction des demandes de la communauté.
  • Clients « simples » et locaux :
    • un client avec un design simplifié a été ajouté. https://adnihilum.net/simple;
    • les pages clients peuvent être enregistrées localement et utilisées depuis file://.

Politiques des navigateurs

  • CSP intégré pour lutter contre les XSS;
  • le serveur envoie HSTS.

Autres modifications

  • le projet a été renommé d'Epha-ots;
  • le domaine adnihilum.net a été acquis;
  • TLS est fourni par Let’s Encrypt, à garder à l'esprit (pas d'argent);
  • le travail avec les fichiers a été simplifié;
  • passage aux pointeurs fat;
  • des bugs mineurs ont été corrigés;
  • auto-jsminify et compilation des fichiers clients lors de la compilation via CMake.

Aperçu du protocole

Générer trois valeurs aléatoires : clé K, vecteur d'initialisation N et sel S. K — 256 bits, N — 96 bits, S — 128 bits.

Afficher ID de K et S à l'aide de HKDF basé sur SHA-256.

Former une chaîne de données authentifiées supplémentaires aad — c'est simplement une chaîne de forme : id=ID

Si l'utilisateur a défini un mot de passe :

  • afficher Pk depuis le mot de passe et S à l'aide de PBKDF2, SHA-256, 800000 itérations;
  • la même sel est utilisé pour tout;
  • chiffrer les données à l'aide de AES-GCM, en utilisant la clé Pk, IV/nonce N et transmettre aad.

Ajouter une étiquette de deux octets aux données déjà chiffrées, si un mot de passe était utilisé, ou aux données source, si aucun mot de passe n'a été utilisé.

Le premier octet a de l'importance : il indique si les données ont été chiffrées avec un mot de passe :

  • 0x73 — données chiffrées avec un mot de passe ;
  • 0x13 — données non chiffrées avec un mot de passe.

Le deuxième octet est une valeur constante 0x37.

Chiffrer à nouveau le résultat avec AES-GCM, en utilisant le même iv = N et le même aad. Cela donne le texte chiffré final ct.

Concaténer les octets en une chaîne : blob = N .. S .. ct

Envoyer blob au serveur avec ID. Le serveur renvoie blob via cela ID et ne peut pas le remplacer : le client vérifie d'abord ID à l'aide de N et K encore avant le déchiffrement, puis à travers aad.

Le client stocke K. K n'est jamais envoyé au serveur. Pk n'est pas non plus envoyé ; tout ce qui est lié au mot de passe est purgé de la mémoire.

Le client forme un lien : origin/#ID/K

Ici ID et K — chaînes au format base64url.

Lorsque le destinataire ouvre le lien :

  • le navigateur ignore tout ce qui commence par # ; cela s'appelle location.hash ;
  • l'application client est chargée depuis le serveur ;
  • à mon avis, c'est la principale vulnérabilité : nous revenons en fait au fait que « TLS est troué » ;
  • toutefois, rien n'empêche de garder le client hors ligne ;
  • idéalement, il devrait y avoir un client autonome distinct.

Le JavaScript client vérifie location.hash, et si cela contient ID et K, il charge les données depuis le serveur.

Ensuite, il les vérifie, les déchiffre et, si nécessaire, demande le mot de passe et déchiffre à nouveau.

Licence

Le projet est distribué sous GPLv3.

Source : linux.org.ru

Acheter un hébergement fiable pour les sites avec protection DDoS, serveurs VPS VDS 🔥 Acheter un hébergement fiable pour les sites avec protection DDoS, serveurs VPS VDS | ProHoster