Sortie de NNCP 8.8.0, utilitaire pour le transfert de fichiers/commandes en mode store-and-forward

La sortie de Node-to-Node CoPy (NNCP), un ensemble d'outils pour le transfert sécurisé de fichiers, d'e-mails et de commandes à exécuter en mode store-and-forward, a eu lieu. Une compatibilité avec les systèmes d'exploitation compatibles POSIX est assurée. Les outils sont écrits en Go et sont distribués sous licence GPLv3.

Les outils sont conçus pour aider à la création de petits réseaux pairs-à-pairs (une douzaine de nœuds) avec routage statique pour le transfert sécurisé de fichiers en mode fire-and-forget, de demandes de fichiers, d'e-mails et de requêtes d'exécution de commandes. Tous les paquets transférés sont chiffrés (end-to-end) et explicitement authentifiés à l'aide de clés publiques connues. Un chiffrement en oignon (comme dans Tor) est appliqué à tous les paquets intermédiaires. Chaque nœud peut agir à la fois comme client et de serveurs utiliser à la fois un modèle de comportement push et poll.

La principale différence entre NNCP et les solutions UUCP et FTN (FidoNet Technology Network), en plus des mentions précédentes concernant le chiffrement et l'authentification, est la prise en charge directe des réseaux de flotteurs et des ordinateurs physiquement isolés (air-gapped) des réseaux locaux et publics non sécurisés. Une autre caractéristique de NNCP est son intégration facile (comme UUCP) avec les services de messagerie existants serveurs très chargés, tels que Postfix et Exim.

Parmi les domaines d'application possibles de NNCP, on note l'organisation de l'envoi/réception d'e-mails sur des appareils sans connexion Internet permanente, le transfert de fichiers dans des conditions de connexion instable, le transfert sécurisé de très grandes quantités de données sur des supports physiques, la création de réseaux de transfert de données isolés protégés contre les attaques MitM, le contournement de la censure et de la surveillance réseau. Comme la clé de déchiffrement ne se trouve qu'auprès du destinataire, indépendamment des chemins de livraison des paquets à travers le réseau ou via des supports physiques, un tiers ne peut pas lire le contenu, même s'il intercepte l'envoi. De plus, l'authentification par signature numérique empêche la création d'un envoi frauduleux sous l'identité d'un autre expéditeur.

Parmi les nouveautés de NNCP 8.8.0, par rapport à la version précédente (5.0.0) :

• Au lieu du hachage BLAKE2b pour vérifier l'intégrité des fichiers, un MTH est utilisé : Hachage basé sur un arbre de Merkle, qui utilise le hachage BLAKE3. Cela permet de vérifier l'intégrité de la partie chiffrée du paquet pendant le téléchargement, sans nécessiter sa lecture par la suite. Cela permet également une vérification d'intégrité en parallèle illimitée.
• Le nouveau format des paquets chiffrés est entièrement convivial pour le streaming, lorsque la taille des données n'est pas connue à l'avance. La signalisation de la fin de la transmission, avec une taille authentifiée, se fait directement dans le flux chiffré. Auparavant, pour connaître la taille des données transmises, il fallait les sauvegarder dans un fichier temporaire. Ainsi, l'option « -use-tmp » de l'équipe « nncp-exec » a été supprimée en raison de son inutilité.
• Les fonctions BLAKE2b KDF et XOF ont été remplacées par BLAKE3 pour réduire le nombre de primitives cryptographiques utilisées et simplifier le code.
• Il est maintenant possible de détecter d'autres nœuds sur le réseau local via une diffusion multicast à l'adresse « ff02::4e4e:4350 ».
• Des groupes de diffusion multicast (l'équivalent des conférences Echo de FidoNet ou des groupes de discussion Usenet) permettent d'envoyer des données à de nombreux membres d'un groupe dans un seul paquet, chaque participant retransmettant également le paquet aux autres abonnés. La lecture d'un paquet multicast nécessite de connaître une paire de clés (il faut être un membre actif du groupe), mais la retransmission peut être effectuée par n'importe quel nœud.
• La prise en charge de la confirmation explicite de la réception du paquet a été intégrée. L'expéditeur peut ne pas supprimer le paquet après l'envoi, en attendant un ACK spécial du destinataire.
• Prise en charge intégrée du réseau overlay Yggdrasil : des démons en ligne peuvent agir comme des participants autonomes au réseau, sans avoir besoin d'implémentations tierces de Yggdrasil et sans nécessiter le fonctionnement complet avec la pile IP sur une interface réseau virtuelle.
• Au lieu de chaînes structurées (RFC 3339), le journal utilise des enregistrements recfile, avec lesquels on peut utiliser des utilitaires GNU Recutils.
• Optionnellement, les en-têtes des paquets chiffrés peuvent être stockés dans des fichiers séparés dans le sous-répertoire « hdr/ », accélérant considérablement les opérations de récupération de la liste des paquets sur des systèmes de fichiers avec une grande taille de bloc, tels que ZFS. Auparavant, la récupération de l'en-tête d'un paquet nécessitait par défaut la lecture de tout un bloc de 128KiB depuis le disque.
• La vérification de la présence de nouveaux fichiers peut éventuellement utiliser les sous-systèmes du noyau kqueue et inotify, réduisant ainsi le nombre d'appels système.
• Les utilitaires maintiennent moins de fichiers ouverts, ce qui entraîne moins de fermetures et de réouvertures. Avec un grand nombre de paquets, il était auparavant possible d'atteindre la limite du nombre maximum de fichiers ouverts.
• De nombreuses commandes commencent désormais à montrer le progrès et la vitesse d'exécution d'opérations telles que le téléchargement/chargement, la copie et le traitement (toss) des paquets.
• La commande « nncp-file » peut envoyer non seulement des fichiers uniques, mais aussi des répertoires, en créant à la volée une archive pax avec leur contenu.
• Les utilitaires en ligne peuvent éventuellement appeler immédiatement le processus de traitement des paquets (tossing) après le téléchargement réussi d'un paquet, sans démarrer un démon séparé « nncp-toss ».
• L'appel en ligne d'un autre participant peut éventuellement se produire non seulement sur l'événement de déclenchement d'un minuteur, mais aussi lors de l'apparition d'un paquet sortant dans le répertoire spool.
• La compatibilité est assurée sous les systèmes d'exploitation NetBSD et OpenBSD, en plus des précédemment supportés FreeBSD et GNU/Linux.
• Le « nncp-daemon » est entièrement compatible avec l'interface UCSPI-TCP. Associé à la possibilité de journaliser dans un descripteur de fichier spécifié (par exemple, en définissant « NNCPLOG=FD:4 »), il est entièrement convivial pour un lancement avec des utilitaires similaires à daemontools.
• La compilation du projet a été complètement transférée au système redo.

Source : opennet.ru