La sortie de Node-to-Node CoPy (NNCP), un ensemble d'utilitaires permettant de transférer en toute sécurité des fichiers, des e-mails et des commandes pour une exécution en mode store-and-forward. Prend en charge le fonctionnement sur les systèmes d'exploitation compatibles POSIX. Les utilitaires sont écrits en Go et distribués sous licence GPLv3.
Les utilitaires visent à aider à créer de petits réseaux peer-to-peer entre amis (des dizaines de nœuds) avec un routage statique pour des transferts de fichiers sécurisés, des demandes de fichiers, des e-mails et des demandes de commandes sécurisées. Tous les paquets transmis sont cryptés (de bout en bout) et sont explicitement authentifiés à l'aide de clés publiques connues d'amis. Le cryptage Onion (comme dans Tor) est utilisé pour tous les paquets intermédiaires. Chaque nœud peut agir à la fois en tant que client et serveur et utiliser à la fois des modèles de comportement push et poll.
La différence entre les solutions NNCP, UUCP et FTN (FidoNet Technology Network), en plus du cryptage et de l'authentification susmentionnés, réside dans la prise en charge prête à l'emploi des réseaux de disquettes et des ordinateurs physiquement isolés (air-gappés) des réseaux locaux et non sécurisés. réseaux publics. NNCP propose également une intégration facile (à égalité avec UUCP) avec les serveurs de messagerie actuels tels que Postfix et Exim.
Les domaines d'application possibles du NNCP incluent l'organisation de l'envoi/réception de courrier vers des appareils sans connexion permanente à Internet, le transfert de fichiers dans des conditions de connexion réseau 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 transmission de données isolés et protégés de Attaques MitM, contournant la censure et la surveillance des réseaux. Étant donné que la clé de déchiffrement est uniquement entre les mains du destinataire, que le paquet soit livré sur le réseau ou via un support physique, un tiers ne peut pas lire le contenu, même si le paquet est intercepté. À son tour, l'authentification par signature numérique ne permet pas de créer un message fictif sous le couvert d'un autre expéditeur.
Parmi les innovations de NNCP 8.8.0, par rapport à la précédente nouveauté (version 5.0.0) :
- Au lieu du hachage BLAKE2b, ce que l'on appelle MTH : Merkle Tree-based Hashing, qui utilise le hachage BLAKE3, est utilisé pour vérifier l'intégrité des fichiers. Cela vous permet de calculer l'intégrité de la partie cryptée du paquet dès le téléchargement, sans nécessiter sa lecture ultérieure. Cela permet également une parallélisation illimitée des contrôles d’intégrité.
- Le nouveau format de paquet crypté est totalement compatible avec le streaming lorsque la taille des données est inconnue à l'avance. La signalisation de la fin du transfert, avec une taille authentifiée, va directement à l'intérieur du flux crypté. Auparavant, pour connaître la taille des données transférées, il fallait les enregistrer dans un fichier temporaire. Ainsi, la commande « nncp-exec » a perdu l'option « -use-tmp » car elle est totalement inutile.
- 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 désormais possible de détecter d'autres nœuds sur le réseau local grâce au multicasting à l'adresse « ff02::4e4e:4350 ».
- Des groupes de multidiffusion sont apparus (analogues aux conférences d'écho FidoNet ou aux groupes de discussion Usenet), permettant à un paquet d'envoyer des données à plusieurs membres du groupe, où chacun relaie également le paquet au reste des signataires. La lecture d'un paquet multicast nécessite la connaissance de la paire de clés (vous devez explicitement être membre du groupe), mais le relais peut être effectué par n'importe quel nœud.
- Il existe désormais un support pour la confirmation explicite de la réception des paquets. L'expéditeur ne peut pas supprimer le paquet après l'envoi, en attendant de recevoir un paquet ACK spécial du destinataire.
- Prise en charge intégrée du réseau superposé Yggdrasil : les démons en ligne peuvent agir en tant que participants réseau indépendants à part entière, sans utiliser d'implémentations tierces d'Yggdrasil et sans travailler pleinement avec la pile IP sur une interface réseau virtuelle.
- Au lieu de chaînes structurées (RFC 3339), le journal utilise des entrées de fichier rec, qui peuvent être utilisées avec les utilitaires GNU Recutils.
- En option, les en-têtes de 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 de paquets sur les systèmes de fichiers avec des blocs de grande taille, tels que ZFS. Auparavant, la récupération de l'en-tête du paquet nécessitait par défaut de lire uniquement un bloc de 128 Ko à partir du disque.
- La recherche de nouveaux fichiers peut éventuellement utiliser les sous-systèmes kqueue et inotify du noyau, effectuant ainsi moins d'appels système.
- Les utilitaires conservent moins de fichiers ouverts et les ferment et les rouvrent moins souvent. Avec un grand nombre de packages, il était auparavant possible de se heurter à une limitation du nombre maximum de fichiers ouverts.
- De nombreuses équipes ont commencé à montrer la progression et la rapidité des opérations telles que le téléchargement/téléchargement, la copie et le traitement (lancement) des packages.
- La commande « nncp-file » peut envoyer non seulement des fichiers uniques, mais également des répertoires, créant ainsi une archive pax avec leur contenu à la volée.
- Les utilitaires en ligne peuvent éventuellement invoquer immédiatement le lancement de paquets une fois qu'un package a été téléchargé avec succès, sans exécuter de démon "nncp-toss" distinct.
- Un appel en ligne vers un autre participant peut éventuellement se produire non seulement lorsqu'un temporisateur est déclenché, mais également lorsqu'un paquet sortant apparaît dans le répertoire spool.
- Garantit l'opérabilité sous NetBSD et OpenBSD OS, en plus de FreeBSD et GNU/Linux précédemment pris en charge.
- "nncp-daemon" est entièrement compatible avec l'interface UCSPI-TCP. Couplé à la possibilité de se connecter à un descripteur de fichier spécifié (par exemple en définissant "NNCPLOG=FD:4"), il est tout à fait convivial de l'exécuter sous des utilitaires de type daemontools.
- L'assemblage du projet a été entièrement transféré vers le système de restauration.
Source: opennet.ru