È stato rilasciato Node-to-Node CoPy (NNCP), un insieme di utility per la trasmissione sicura di file, email e comandi da eseguire in modalità store-and-forward. È supportato il funzionamento su sistemi operativi compatibili con POSIX. Le utility sono scritte in linguaggio Go e distribuite sotto licenza GPLv3.
Le utility sono progettate per aiutare nella creazione di piccole reti peer-to-peer friend-to-friend (una dozzina di nodi) con instradamento statico per la trasmissione sicura di file in modalità fire-and-forget, richieste di file, email e richieste per l'esecuzione di comandi. Tutti i pacchetti trasmessi sono cifrati (end-to-end) e autenticati esplicitamente tramite chiavi pubbliche note. La cifratura onion (come in Tor) viene applicata a tutti i pacchetti intermedi. Ogni nodo può agire sia come client che server e utilizzare sia il modello push che il modello poll.
La differenza tra NNCP e le soluzioni UUCP e FTN (FidoNet Technology Network), oltre alla cifratura e all'autenticazione sopra menzionate, è il supporto immediato per reti floppynet e computer fisicamente isolati (air-gapped) da reti locali e pubbliche non sicure. Un'altra caratteristica di NNCP è la facile integrazione (allo stesso modo di UUCP) con i correnti server di posta server, come Postfix ed Exim.
Tra le possibili aree di applicazione di NNCP si segnalano l'organizzazione dell'invio/ricezione di email su dispositivi senza connessione permanente a Internet, la trasmissione di file in condizioni di connessione instabile, la trasmissione sicura di grandi volumi di dati su supporti fisici, la creazione di reti di trasmissione dati isolate protette da attacchi MitM, l'aggiramento della censura di rete e della sorveglianza. Poiché la chiave per la decrittazione è solo in possesso del destinatario, indipendentemente dai percorsi di consegna del pacchetto sulla rete o tramite supporti fisici, una terza parte non può leggere il contenuto, anche se intercetta la spedizione. A sua volta, l'autenticazione tramite firma digitale non consente di formare una spedizione falsa spacciandola per un altro mittente.
Tra le novità di NNCP 8.8.0, rispetto alla versione precedente (5.0.0):
- Invece dell'hash BLAKE2b per il controllo dell'integrità dei file, è stato utilizzato quello che viene chiamato MTH: Merkle Tree-based Hashing, che utilizza l'hash BLAKE3. Questo consente di calcolare l'integrità della parte crittografata del pacchetto durante il download, senza necessità di leggerla successivamente. Inoltre, ciò permette un'infinità di parallelizzazione del controllo dell'integrità.
- Il nuovo formato dei pacchetti crittografati è completamente compatibile con lo streaming, quando la dimensione dei dati non è nota in anticipo. La segnalazione del completamento della trasmissione, con la dimensione autenticata, avviene direttamente all'interno del flusso crittografato. In precedenza, per conoscere la dimensione dei dati trasmessi, era necessario salvarli in un file temporaneo. Così, l'opzione «-use-tmp» è stata rimossa dal team «nncp-exec» per totale inutilità.
- Le funzioni BLAKE2b KDF e XOF sono state sostituite con BLAKE3 per ridurre il numero di primitivi crittografici utilizzati e semplificare il codice.
- È ora possibile rilevare altri nodi nella rete locale attraverso l'invio multicast all'indirizzo «ff02::4e4e:4350».
- Sono emersi gruppi multicast (analoghi alle echoconference di FidoNet o ai gruppi di notizie Usenet), che consentono di inviare dati a più partecipanti del gruppo con un solo pacchetto, dove ognuno ritrasmette il pacchetto agli altri iscritti. La lettura di un pacchetto multicast richiede la conoscenza di una coppia di chiavi (deve essere esplicitamente un membro del gruppo), ma la ritrasmissione può essere effettuata da qualsiasi nodo.
- È stata integrata la supporto per la conferma esplicita della ricezione del pacchetto. Il mittente può decidere di non eliminare il pacchetto dopo l'invio, aspettando di ricevere un particolare pacchetto ACK dal destinatario.
- È stata implementata la supporto per la rete overlay Yggdrasil: i demoni online possono agire come partecipanti autonomi della rete, senza ricorrere a implementazioni esterne di Yggdrasil e gestendo completamente lo stack IP su un'interfaccia di rete virtuale.
- Invece di stringhe strutturate (RFC 3339), il registro utilizza le registrazioni recfile, con cui è possibile utilizzare gli strumenti GNU Recutils.
- Facoltativamente, le intestazioni dei pacchetti crittografati possono essere archiviate in file separati sotto la sottodirectory «hdr/», accelerando significativamente le operazioni di recupero dell'elenco dei pacchetti su file system con grandi dimensioni di blocco, come ZFS. In precedenza, il recupero dell'intestazione del pacchetto richiedeva per impostazione predefinita la lettura sull'unità dell'intero blocco di 128KiB.
- Il controllo della presenza di nuovi file può opzionalmente utilizzare i sottosistemi del kernel kqueue e inotify, riducendo il numero di chiamate di sistema.
- Le utility mantengono un numero minore di file aperti, riducendo la frequenza di chiusura e riapertura. Con un gran numero di pacchetti, in passato si poteva arrivare a un limite sul numero massimo di file aperti.
- Molti comandi hanno cominciato a mostrare il progresso e la velocità di esecuzione delle operazioni, come il download/upload, la copia e il trattamento (toss) dei pacchetti.
- Il comando «nncp-file» può inviare non solo file singoli, ma anche directory, creando al volo un archivio pax con il loro contenuto.
- Le utility online possono opzionalmente invocare immediatamente il processo di elaborazione dei pacchetti (tossing) dopo un download riuscito, senza avviare un demone separato «nncp-toss».
- La chiamata online a un altro partecipante può opzionalmente avvenire non solo in seguito all'attivazione di un timer, ma anche alla comparsa di un pacchetto in uscita nella directory di spool.
- È garantito il funzionamento su sistemi operativi NetBSD e OpenBSD, oltre ai già supportati FreeBSD e GNU/Linux.
- Il «nncp-daemon» è completamente compatibile con l'interfaccia UCSPI-TCP. Inoltre, con la possibilità di registrare su un descrittore di file specificato (ad esempio impostando «NNCPLOG=FD:4»), è completamente compatibile con utility simili a daemontools.
- La costruzione del progetto è stata completamente trasferita al sistema redo.
Fonte: opennet.ru
