The release of Node-to-Node CoPy (NNCP), a set of utilities for secure file transfer, email and store-and-forward commands. Supports work on POSIX-compliant operating systems. The utilities are written in the Go language and distributed under the GPLv3 license.
The utilities are designed to help build small peer-to-peer friend-to-friend networks (dozens of nodes) with static routing for secure fire-and-forget file transfer, file requests, email, and command execution requests. All transmitted packets are encrypted (end-to-end) and explicitly authenticated against known public keys of friends. Onion (as in Tor) encryption is applied to all intermediate packets. Each node can act as both a client and a server and use both push and poll behaviors.
The difference between NNCP and UUCP and FTN (FidoNet Technology Network) solutions, in addition to the aforementioned encryption and authentication, is support out of the box for floppynet networks and computers that are physically isolated (air-gapped) from insecure local and public networks. NNCP also features easy integration (on a par with UUCP) with current mail servers such as Postfix and Exim.
Of the possible areas of application of NNCP, the organization of sending / receiving mail to devices without a permanent connection to the Internet, transferring files in conditions of an unstable network connection, securely transferring very large amounts of data on physical media, creating isolated data transfer networks protected from MitM attacks, bypassing network censorship and surveillance. Since the decryption key is only with the recipient, regardless of how the packet is delivered over the network or through physical media, a third party cannot read the contents, even by intercepting the send. In turn, digital signature authentication does not allow you to create a fictitious shipment under the guise of another sender.
Among the innovations of NNCP 8.8.0, compared to the previous news (version 5.0.0):
- Instead of the BLAKE2b hash, the so-called MTH: Merkle Tree-based Hashing is used to check the integrity of files, using the BLAKE3 hash. This allows you to calculate the integrity of the encrypted part of the package right during the download, without requiring it to be read later. It also allows unlimited parallelization of integrity checks.
- The new encrypted packet format is completely streaming friendly when the size of the data is not known in advance. Transmission completion signaling, with an authenticated size, goes right inside the encrypted stream. Previously, in order to find out the size of the transmitted data, it was necessary to save them to a temporary file. So the "nncp-exec" command has lost the "-use-tmp" option as it is completely unnecessary.
- The BLAKE2b KDF and XOF functions have been replaced by BLAKE3 to reduce the number of cryptographic primitives used and simplify the code.
- Now it is possible to detect other nodes in the local network via multicasting at the address "ff02::4e4e:4350".
- Multicast groups appeared (analogous to FidoNet echo conferences or Usenet newsgroups), allowing one packet to send data to many members of the group, where each also relays the packet to other signers. Reading a multicast packet requires knowledge of the key pair (you must explicitly be a member of the group), but relaying can be done by any node.
- Added support for explicit acknowledgment of packet receipt. The sender may choose not to delete the packet after it has been sent, waiting for a special ACK packet to be received from the receiver.
- Built-in support for the Yggdrasil overlay network: online daemons can act as full-fledged independent network participants, without using third-party Yggdrasil implementations and full-fledged work with the IP stack on a virtual network interface.
- Instead of structured strings (RFC 3339), the log uses recfile entries that can be used with the GNU Recutils utilities.
- Optionally, encrypted packet headers can be stored in separate files in the "hdr/" subdirectory, greatly speeding up packet listing operations on large block filesystems such as ZFS. Previously, retrieving a packet header required, by default, only a 128KiB block to be read from disk.
- Checking for new files can optionally use the kqueue and inotify kernel subsystems, making fewer system calls.
- Utilities keep fewer open files, they are less likely to be closed and reopened. With a large number of packages, it was previously possible to run into a limit on the maximum number of open files.
- Many commands began to show the progress and speed of operations, such as downloading / uploading, copying and processing (toss) packages.
- The "nncp-file" command can send not only single files, but also directories, creating a pax archive with their contents on the fly.
- Online utilities can optionally invoke the package processing (tossing) process immediately after a successful download of a package, without running a separate "nncp-toss" daemon.
- An online call to another participant can optionally occur not only when the timer fires, but also when an outgoing packet appears in the spool directory.
- Workability under NetBSD and OpenBSD operating systems is provided, in addition to the previously supported FreeBSD and GNU/Linux.
- "nncp-daemon" is fully compatible with the UCSPI-TCP interface. Coupled with the ability to log to a specified file descriptor (for example, setting "NNCPLOG=FD:4"), it is completely friendly to run under daemontools-like utilities.
- The assembly of the project is completely transferred to the redo system.
Source: opennet.ru