È stato rilasciato Node-to-Node CoPy (NNCP), un insieme di strumenti per la trasmissione sicura di file, email e comandi in modalità store-and-forward. È supportato il funzionamento su sistemi operativi compatibili con POSIX. Gli strumenti sono scritti in Go e distribuiti con licenza GPLv3.
Gli strumenti sono progettati per assistere nella creazione di piccole reti peer-to-peer friend-to-friend (dozzine 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 crittografati (end-to-end) e autentificati esplicitamente tramite chiavi pubbliche note di conoscenti. La crittografia a cipolla (come in Tor) viene applicata a tutti i pacchetti intermedi. Ogni nodo può fungere sia da client che server utilizzare sia il modello push che poll.
La differenza principale tra NNCP e le soluzioni UUCP e FTN (FidoNet Technology Network), oltre alla crittografia e all'autenticazione menzionate, è il supporto nativo per le reti floppinet e i computer fisicamente isolati (air-gapped) da reti locali e pubbliche non sicure. Un'altra caratteristica di NNCP è la facile integrazione (insieme a UUCP) con i sistemi di posta elettronica attuali, server, come Postfix e Exim.
Tra le possibili applicazioni di NNCP c'è l'organizzazione dell'invio/ricezione di posta su dispositivi senza connessione internet permanente, la trasmissione di file in condizioni di rete instabile, il trasferimento sicuro di grandi volumi di dati su supporti fisici, la creazione di reti di trasmissione dati isolate e protette dagli attacchi MitM, e il superamento della censura e della sorveglianza di rete. Poiché la chiave per la decrittazione è solo in possesso del destinatario, indipendentemente dai percorsi di consegna del pacchetto tramite rete o supporti fisici, una terza parte non può leggere il contenuto, anche se intercetta l'invio. D'altra parte, l'autenticazione tramite firma digitale non consente la creazione di un invio falso sotto le sembianze di un altro mittente.
Tra le novità di NNCP 8.8.0, rispetto all'aggiornamento precedente (versione 5.0.0):
- Invece dell'hash BLAKE2b per la verifica dell'integrità dei file, è stato implementato quello che si chiama MTH: Merkle Tree-based Hashing, che utilizza l'hash BLAKE3. Questo consente di calcolare l'integrità della parte crittografata del pacchetto direttamente durante il download, senza la necessità di leggerla in seguito. Inoltre, offre la possibilità di effettuare controlli di integrità illimitati in parallelo.
- Il nuovo formato dei pacchetti crittografati è completamente compatibile con lo streaming, quando la dimensione dei dati è sconosciuta in anticipo. La segnalazione del completamento del trasferimento, con una dimensione autenticata, avviene direttamente all'interno dello stream crittografato. In passato, per conoscere la dimensione dei dati trasferiti, era necessario salvarli in un file temporaneo. Così, l'opzione "-use-tmp" per il comando "nncp-exec" è stata rimossa per completa inutilità.
- Le funzioni BLAKE2b KDF e XOF sono state sostituite con BLAKE3 per ridurre il numero di primitivi crittografici utilizzati e semplificare il codice.
- È stata aggiunta la possibilità di rilevare altri nodi nella rete locale tramite broadcast multicast all'indirizzo "ff02::4e4e:4350".
- Sono state introdotte le multicast group (simili alle conferenze echo di FidoNet o ai gruppi di notizie di Usenet), che permettono di inviare un pacchetto di dati a molti membri del gruppo, dove ognuno di essi ritrasmette il pacchetto agli altri iscritti. La lettura di un pacchetto multicast richiede la conoscenza di una coppia di chiavi (è necessario essere esplicitamente membri del gruppo), ma la ritrasmissione può essere effettuata da qualsiasi nodo.
- È stata introdotta la supporto per la conferma esplicita della ricezione del pacchetto. Il mittente può decidere di non eliminare il pacchetto dopo l'invio, in attesa di ricevere un ACK speciale dal destinatario.
- È stato integrato il supporto per la rete overlay Yggdrasil: i demoni online possono fungere da partecipanti autonomi alla rete, senza bisogno di 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 registrazioni recfile, con cui si possono utilizzare le utility GNU Recutils.
- Facoltativamente, i titoli dei pacchetti crittografati possono essere memorizzati in file separati nella sottodirectory «hdr/», accelerando notevolmente 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 dall'unità di un 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 utilità mantengono meno file aperti, quindi le chiusure e le riaperture avvengono meno frequentemente. Con un gran numero di pacchetti, in precedenza si poteva raggiungere il limite massimo di file aperti.
- Molti comandi ora mostrano il progresso e la velocità delle operazioni, come il download/esportazione, la copia e l'elaborazione (toss) dei pacchetti.
- Il comando «nncp-file» può inviare non solo singoli file, ma anche directory, creando on-the-fly un archivio pax con il loro contenuto.
- Le utilità online possono opzionalmente avviare immediatamente il processo di elaborazione dei pacchetti (tossing) dopo un download riuscito, senza avviare un demone separato «nncp-toss».
- La chiamata online di un altro partecipante può opzionalmente avvenire non solo in seguito all'evento di attivazione del timer, ma anche con l'arrivo di un pacchetto in uscita nella directory spool.
- È garantito il funzionamento su sistemi operativi NetBSD e OpenBSD, oltre ai precedentemente supportati FreeBSD e GNU/Linux.
- Il «nncp-daemon» è completamente compatibile con l'interfaccia UCSPI-TCP. Insieme alla possibilità di registrare su un descrittore di file specificato (ad esempio impostando «NNCPLOG=FD:4»), è completamente amichevole per l'esecuzione con utilità simili a daemontools.
- La costruzione del progetto è completamente passata al sistema redo.
Fonte: opennet.ru
