The release of Node-to-Node CoPy (NNCP) has taken place; it is a set of utilities for secure file transfer, email, and command execution in store-and-forward mode. It operates on POSIX-compliant operating systems. The utilities are written in Go and distributed under the GPLv3 license.
The utilities are designed to assist in building small peer-to-peer friend-to-friend networks (a dozen nodes) with static routing for secure file transfers in fire-and-forget mode, file requests, email, and command execution requests. All transmitted packets are encrypted (end-to-end) and explicitly authenticated using known public keys of acquaintances. Onion (as in Tor) encryption is applied to all intermediate packets. Each node can act both as a client and server utilize both push and poll behavior models.
The main distinction of NNCP from UUCP and FTN (FidoNet Technology Network), aside from the aforementioned encryption and authentication, is its out-of-the-box support for Floppynet networks and computers that are physically isolated (air-gapped) from unsecured local and public networks. Another feature of NNCP is its easy integration (on par with UUCP) with current email serverssystems, such as Postfix and Exim.
Potential applications of NNCP include organizing the sending/receiving of email on devices without a persistent internet connection, file transfers under unstable network conditions, secure transmission of very large data volumes on physical media, creating data transmission networks that are resistant to MitM attacks, and bypassing network censorship and surveillance. Since the decryption key is only with the recipient, regardless of the delivery paths for the packet over the network or through physical media, a third party cannot read the contents, even if they intercept the shipment. In turn, authentication via digital signature prevents the creation of a fraudulent shipment disguised as another sender.
Among the innovations in NNCP 8.8.0, compared to the previous release (version 5.0.0):
- Instead of the BLAKE2b hash for file integrity verification, a so-called MTH: Merkle Tree-based Hashing, which uses the BLAKE3 hash, has been implemented. This allows for the calculation of the integrity of the encrypted part of the package during the download, without requiring its reading later. It also enables unlimited parallel integrity verification.
- The new format for encrypted packages is fully stream-friendly, especially when the size of the data is not known in advance. The signal indicating the completion of transmission, along with the authenticated size, is sent directly within the encrypted stream. Previously, to ascertain the size of the transmitted data, it had to be saved to a temporary file. Thus, the 'nncp-exec' team has removed the '-use-tmp' option due to its complete obsolescence.
- The BLAKE2b KDF and XOF functions have been replaced with BLAKE3 to reduce the number of cryptographic primitives used and simplify the code.
- There is now the capability to discover other nodes on the local network via multicast broadcasting at the address 'ff02::4e4e:4350'.
- Multicast groups have been introduced (similar to FidoNet echo conferences or Usenet news groups), allowing one package to be sent to multiple group members, where each also retransmits the package to other subscribers. Reading a multicast package requires knowledge of a key pair (one must be an explicit group member), but any node can perform the retransmission.
- Support for explicit acknowledgment of packet receipt has been built in. The sender can retain the packet after sending, awaiting a special ACK packet from the recipient.
- Support for the Yggdrasil overlay network has been integrated: online demons can operate as full-fledged independent participants in the network, without relying on third-party Yggdrasil implementations and fully interacting with the IP stack on a virtual network interface.
- Instead of structured strings (RFC 3339), the log uses recfile records, which can utilize GNU Recutils utilities.
- Optionally, the headers of encrypted packages can be stored in separate files within the 'hdr/' subdirectory, significantly speeding up the operations of listing packages on file systems with large block sizes, such as ZFS. Previously, obtaining a package header required reading the entire 128KiB block from the disk by default.
- The check for new files can optionally use the core subsystems kqueue and inotify, resulting in fewer system calls.
- Utilities maintain fewer open files, reducing the frequency of their closure and reopening. With a large number of packets, one might previously encounter a limitation on the maximum number of open files.
- Many commands have begun to show progress and speed in performing operations such as downloading/uploading, copying, and processing (tossing) packets.
- The ānncp-fileā command can send not just individual files but also directories, creating a pax archive with their contents on the fly.
- Online utilities can optionally immediately invoke the packet processing (tossing) process after successfully downloading a packet, without launching a separate ānncp-tossā daemon.
- An online call to another participant can optionally occur not only based on a timer event but also upon the appearance of an outgoing packet in the spool directory.
- Functionality is ensured under NetBSD and OpenBSD operating systems, in addition to the previously supported FreeBSD and GNU/Linux.
- The ānncp-daemonā is fully compliant with the UCSPI-TCP interface. Combined with the ability to log to a specified file descriptor (for example, setting āNNCPLOG=FD:4ā), it is fully compatible with utilities similar to daemontools.
- The project build has been completely migrated to the redo system.
Source: opennet.ru
