Rilascio di NNCP 8.8.0, utilità per il trasferimento di file/comandi in modalità store-and-forward

Il rilascio di Node-to-Node CoPy (NNCP), una serie di utilità per il trasferimento sicuro di file, e-mail e comandi store-and-forward. Supporta il lavoro su sistemi operativi conformi a POSIX. Le utilità sono scritte nel linguaggio Go e distribuite sotto la licenza GPLv3.

Le utilità sono progettate per aiutare a costruire piccole reti peer-to-peer amico-a-amico (dozzine di nodi) con routing statico per trasferimento file sicuro "fire-and-forget", richieste di file, e-mail e richieste di esecuzione di comandi. Tutti i pacchetti trasmessi sono crittografati (end-to-end) e autenticati esplicitamente rispetto alle chiavi pubbliche conosciute degli amici. La crittografia Onion (come in Tor) viene applicata a tutti i pacchetti intermedi. Ciascun nodo può agire sia come client che come server e utilizzare sia comportamenti push che poll.

La differenza tra le soluzioni NNCP e UUCP e FTN (FidoNet Technology Network), oltre alla crittografia e all'autenticazione sopra menzionate, è il supporto immediato per reti floppynet e computer fisicamente isolati (air gap) da reti locali e pubbliche non sicure . NNCP offre anche una facile integrazione (al pari di UUCP) con gli attuali server di posta come Postfix ed Exim.

Tra i possibili ambiti di applicazione di NNCP, l'organizzazione dell'invio/ricezione di posta su dispositivi senza connessione permanente a Internet, il trasferimento di file in condizioni di connessione di rete instabile, il trasferimento sicuro di grandi quantità di dati su supporti fisici, la creazione di dati isolati reti protette dagli attacchi MitM, aggirando la censura e la sorveglianza della rete. Poiché la chiave di decrittazione è solo presso il destinatario, indipendentemente da come il pacchetto viene consegnato sulla rete o tramite supporto fisico, una terza parte non può leggerne il contenuto, nemmeno intercettando l'invio. A sua volta, l'autenticazione con firma digitale non consente di creare una spedizione fittizia sotto le spoglie di un altro mittente.

Tra le novità di NNCP 8.8.0, rispetto alle novità precedenti (versione 5.0.0):

  • Al posto dell'hash BLAKE2b, per verificare l'integrità dei file viene utilizzato il cosiddetto MTH: Merkle Tree-based Hashing, utilizzando l'hash BLAKE3. Ciò consente di calcolare l'integrità della parte crittografata del pacchetto già durante il download, senza doverla leggere successivamente. Consente inoltre la parallelizzazione illimitata dei controlli di integrità.
  • Il nuovo formato di pacchetto crittografato è completamente compatibile con lo streaming quando la dimensione dei dati non è nota in anticipo. La segnalazione di completamento della trasmissione, con una 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. Quindi il comando "nncp-exec" ha perso l'opzione "-use-tmp" poiché è completamente inutile.
  • Le funzioni BLAKE2b KDF e XOF sono state sostituite da BLAKE3 per ridurre il numero di primitive crittografiche utilizzate e semplificare il codice.
  • Ora è possibile rilevare altri nodi nella rete locale tramite multicasting all'indirizzo "ff02::4e4e:4350".
  • Apparvero gruppi multicast (analoghi alle conferenze eco FidoNet o ai newsgroup Usenet), che consentivano a un pacchetto di inviare dati a molti membri del gruppo, dove ciascuno inoltra il pacchetto anche ad altri firmatari. La lettura di un pacchetto multicast richiede la conoscenza della coppia di chiavi (devi essere esplicitamente membro del gruppo), ma l'inoltro può essere effettuato da qualsiasi nodo.
  • Aggiunto supporto per il riconoscimento esplicito della ricezione del pacchetto. Il mittente può scegliere di non eliminare il pacchetto dopo che è stato inviato, in attesa che venga ricevuto uno speciale pacchetto ACK dal destinatario.
  • Supporto integrato per la rete overlay Yggdrasil: i demoni online possono agire come partecipanti di rete indipendenti a tutti gli effetti, senza utilizzare implementazioni Yggdrasil di terze parti e lavorare a pieno titolo con lo stack IP su un'interfaccia di rete virtuale.
  • Invece di stringhe strutturate (RFC 3339), il registro utilizza voci recfile che possono essere utilizzate con le utilità GNU Recutils.
  • Facoltativamente, le intestazioni dei pacchetti crittografati possono essere archiviate in file separati nella sottodirectory "hdr/", velocizzando notevolmente le operazioni di elenco dei pacchetti su filesystem a blocchi di grandi dimensioni come ZFS. In precedenza, il recupero dell'intestazione di un pacchetto richiedeva, per impostazione predefinita, solo un blocco da 128 KiB da leggere dal disco.
  • Il controllo della presenza di nuovi file può facoltativamente utilizzare kqueue e inotificare i sottosistemi del kernel, effettuando meno chiamate di sistema.
  • Le utilità mantengono meno file aperti, hanno meno probabilità di essere chiusi e riaperti. Con un numero elevato di pacchetti in precedenza era possibile incorrere in un limite al numero massimo di file aperti.
  • Molti comandi iniziarono a mostrare l'avanzamento e la velocità delle operazioni, come il download/caricamento, la copia e l'elaborazione (lancio) dei pacchetti.
  • Il comando "nncp-file" può inviare non solo singoli file, ma anche directory, creando al volo un archivio pax con il loro contenuto.
  • Le utilità in linea possono facoltativamente richiamare il processo di elaborazione (lancio) del pacchetto immediatamente dopo un download riuscito di un pacchetto, senza eseguire un demone "nncp-toss" separato.
  • Facoltativamente, una chiamata in linea a un altro partecipante può avvenire non solo quando si attiva il timer, ma anche quando un pacchetto in uscita appare nella directory di spool.
  • Viene fornita la funzionalità con i sistemi operativi NetBSD e OpenBSD, oltre a FreeBSD e GNU/Linux precedentemente supportati.
  • "nncp-daemon" è completamente compatibile con l'interfaccia UCSPI-TCP. Insieme alla possibilità di accedere a un descrittore di file specificato (ad esempio, impostando "NNCPLOG=FD:4"), è completamente semplice da eseguire con utilità simili a daemontools.
  • L'assemblaggio del progetto viene completamente trasferito al sistema redo.

Fonte: opennet.ru

Aggiungi un commento