Se ha lanzado Node-to-Node CoPy (NNCP), un conjunto de utilidades para la transferencia segura de archivos, correos electrónicos y comandos para su ejecución en modo store-and-forward. Se admite su funcionamiento en sistemas operativos compatibles con POSIX. Las utilidades están escritas en Go y se distribuyen bajo la licencia GPLv3.
Las utilidades están diseñadas para ayudar en la construcción de pequeñas redes peer-to-peer friend-to-friend (docenas de nodos) con enrutamiento estático para la transferencia segura de archivos en modo fire-and-forget, solicitudes de archivos, correos electrónicos y solicitudes de ejecución de comandos. Todos los paquetes transmitidos están cifrados (end-to-end) y se autentican explícitamente mediante claves públicas conocidas de amigos. Se aplica cifrado onion (como en Tor) para todos los paquetes intermedios. Cada nodo puede actuar tanto como cliente como servidores y usar tanto el modelo de push como el de poll.
La diferencia de NNCP frente a soluciones como UUCP y FTN (FidoNet Technology Network), además del cifrado y autenticación mencionados anteriormente, es el soporte inmediato para redes floppy y computadoras físicamente aisladas (air-gapped) de redes locales y públicas inseguras. Una característica de NNCP es la fácil integración (junto con UUCP) con los actuales servidores de correo servidores, como Postfix y Exim.
Entre las posibles áreas de aplicación de NNCP se destacan la organización de envío/recepción de correos en dispositivos sin conexión permanente a Internet, la transferencia de archivos en condiciones de conexión de red inestables, la transferencia segura de grandes volúmenes de datos en soportes físicos, la creación de redes de transmisión de datos aisladas protegidas contra ataques MitM, el eludir la censura y la vigilancia en la red. Dado que la clave para la descifrado se encuentra únicamente en el receptor, independientemente de las rutas de entrega del paquete a través de la red o mediante soportes físicos, un tercero no puede leer el contenido, incluso si intercepta el envío. Por su parte, la autenticación mediante firma digital evita la formación de envíos falsos haciéndose pasar por otro remitente.
Entre las novedades de NNCP 8.8.0, en comparación con la versión anterior (5.0.0):
- En lugar del hash BLAKE2b para verificar la integridad de los archivos, se utiliza lo que se denomina MTH: Merkle Tree-based Hashing, que emplea el hash BLAKE3. Esto permite calcular la integridad de la parte cifrada del paquete durante la descarga, sin necesidad de leerla posteriormente. También ofrece la posibilidad de paralelizar indefinidamente la verificación de integridad.
- El nuevo formato de paquetes cifrados es completamente amigable con la transmisión en streaming, cuando el tamaño de los datos es desconocido de antemano. La señalización de finalización de la transmisión, con un tamaño autenticado, se realiza dentro del flujo cifrado. Anteriormente, para conocer el tamaño de los datos transmitidos, era necesario guardarlos en un archivo temporal. Así, el comando 'nncp-exec' eliminó la opción '-use-tmp' por completo.
- Las funciones BLAKE2b KDF y XOF han sido reemplazadas por BLAKE3 para reducir la cantidad de primitivas criptográficas utilizadas y simplificar el código.
- Se ha añadido la posibilidad de detectar otros nodos en la red local a través de un multicast en la dirección 'ff02::4e4e:4350'.
- Se han introducido grupos multicast (similar a las conferencias de eco de FidoNet o a los grupos de noticias de Usenet), que permiten enviar datos a múltiples participantes del grupo con un solo paquete, donde cada uno también retransmite el paquete a los demás suscriptores. La lectura de un paquete multicast requiere conocer la pareja de claves (es necesario ser un participante explícito del grupo), pero cualquier nodo puede realizar la retransmisión.
- Se ha integrado el soporte para confirmación explícita de la recepción de paquetes. El remitente puede optar por no eliminar el paquete después de enviarlo, esperando una ACK especial del receptor.
- Se ha incorporado el soporte para la red overlay Yggdrasil: demonios en línea pueden actuar como participantes completos de la red, sin recurrir a implementaciones externas de Yggdrasil y operando completamente con la pila IP en una interfaz de red virtual.
- En lugar de cadenas estructuradas (RFC 3339), el registro utiliza entradas de recfile, que pueden utilizar utilidades de GNU Recutils.
- Opcionalmente, los encabezados de los paquetes cifrados pueden almacenarse en archivos separados en el subdirectorio 'hdr/', acelerando significativamente las operaciones de obtención de la lista de paquetes en sistemas de archivos con un gran tamaño de bloque, como ZFS. Anteriormente, obtener el encabezado de un paquete requería por defecto la lectura de un bloque completo de 128KiB del disco.
- La verificación de la existencia de nuevos archivos puede opcionalmente usar subsistemas del núcleo kqueue e inotify, realizando menos llamadas al sistema.
- Las utilidades mantienen menos archivos abiertos, se cierran y reabren con menos frecuencia. Con una gran cantidad de paquetes, anteriormente se podía alcanzar la restricción del número máximo de archivos abiertos.
- Muchos comandos ahora muestran el progreso y la velocidad de ejecución de operaciones como descarga/transferencia, copia y procesamiento (toss) de paquetes.
- El comando «nncp-file» puede enviar no solo archivos individuales, sino también directorios, creando sobre la marcha un archivo pax con su contenido.
- Las utilidades en línea pueden opcionalmente iniciar el proceso de procesamiento de paquetes (tossing) inmediatamente después de la descarga exitosa del paquete, sin iniciar un demonio separado «nncp-toss».
- La llamada en línea a otro participante puede opcionalmente ocurrir no solo por el evento de activación del temporizador, sino también con la aparición de un paquete saliente en el directorio spool.
- Se asegura la compatibilidad con sistemas operativos NetBSD y OpenBSD, además de los anteriormente soportados FreeBSD y GNU/Linux.
- El «nncp-daemon» es completamente compatible con la interfaz UCSPI-TCP. Junto con la posibilidad de registrar en el descriptor de archivo especificado (por ejemplo, configurando «NNCPLOG=FD:4»), es completamente amigable para ejecutarse con utilidades similares a daemontools.
- La compilación del proyecto ha sido completamente trasladada al sistema redo.
Fuente: opennet.ru
