Реліз NNCP 8.8.0, утиліт для передачі файлів/команд у режимі store-and-forward

Відбувся реліз Node-to-Node CoPy (NNCP), набору утиліт для безпечної передачі файлів, електронної пошти та команд для виконання як store-and-forward. Підтримується робота на POSIX-сумісних операційних системах. Утиліти написані мовою Go та розповсюджуються під ліцензією GPLv3.

Утиліти орієнтовані на допомогу у побудові невеликих однорангових friend-to-friend мереж (дюжини вузлів) зі статичною маршрутизацією для безпечної передачі файлів у режимі fire-and-forget, запитів на файли, електронної пошти та запитів на виконання команд. Усі пакети, що передаються, зашифровані (end-to-end) і явно аутентифікуються за відомими публічними ключами знайомих. Лукове (як Tor) шифрування застосовується всім проміжних пакетів. Кожен вузол може виступати як у ролі клієнта, так і сервера і використовувати push і poll модель поведінки.

Відмінністю NNCP від ​​рішень UUCP та FTN (FidoNet Technology Network), крім вищезазначеного шифрування та аутентифікації, є підтримка з коробки мереж флоппінет та комп'ютерів, фізично ізольованих (air-gapped) від небезпечних локальних та публічних мереж. Особливістю NNCP є легка інтеграція (нарівні з UUCP) з поточними поштовими серверами, такими як Postfix і Exim.

З можливих областей застосування NNCP відзначається організація відправки/прийому пошти на пристрої без постійного підключення до інтернету, передачі файлів в умовах нестабільного мережного з'єднання, безпечної передачі дуже великих обсягів даних на фізичних носіях, створення захищених від MitM-атак ізольованих мереж передачі даних, обходу мережевий цензури та стеження. Так як ключ для дешифрування знаходиться тільки в одержувача, незалежно від шляхів доставки пакета через мережу або через фізичні носії, третя особа не може прочитати вміст, навіть перехопивши відправлення. Аутентифікація за цифровим підписом не дозволяє сформувати фіктивне відправлення під виглядом іншого відправника.

Серед нововведень NNCP 8.8.0 порівняно з попередньою новиною (версія 5.0.0):

  • Замість хеша BLAKE2b для перевірки цілісності файлів задіяний так званий MTH: Merkle Tree-based Hashing, що використовує хеш BLAKE3. Це дозволяє обчислювати цілісність зашифрованої частини пакета під час докачування, не вимагаючи її читання надалі. Також це дає можливість необмеженого розпаралелювання перевірки цілісності.
  • Новий формат зашифрованих пакетів повністю доброзичливий до потокової передачі, коли заздалегідь невідомий розмір даних. Сигналізація про завершення передачі з автентифікованим розміром йде прямо всередині зашифрованого потоку. Перш, щоб дізнатися розмір даних, що передаються, потрібно їх збереження в тимчасовий файл. Так у команди "nncp-exec" зникла опція "-use-tmp" через повну непотрібність.
  • Функції BLAKE2b KDF і XOF замінені на BLAKE3 для скорочення кількості криптографічних примітивів і спрощення коду.
  • З'явилася можливість виявлення інших нод в локальній мережі через розсилку мультимовлення за адресою «ff02::4e4e:4350».
  • З'явилися мультимовні групи (аналог ехоконференцій FidoNet або груп Usenet новин), що дозволяють одним пакетом відправити дані безлічі учасників групи, де кожен також ретранслює пакет іншим підписанцям. Читання мультимовного пакета вимагає знання ключової пари (потрібно бути учасником групи), але ретрансляція може здійснюватися будь-якою нодою.
  • З'явилася підтримка явного підтвердження одержання пакета. Відправник може не видаляти пакет після відправки, чекаючи на отримання особливого ACK-пакета від одержувача.
  • Вбудована підтримка overlay-мережі Yggdrasil: демони можуть виступати повноцінними самостійними учасниками мережі, без використання сторонніх реалізацій Yggdrasil та повноцінної роботи з IP стеком на віртуальному мережному інтерфейсі.
  • Замість структурованих рядків (RFC 3339) журнал використовує recfile-записи, з якими можна використовувати утиліти GNU Recutils.
  • Опційно заголовки зашифрованих пакетів можуть зберігатися в окремих файлах піддиректорії hdr/, істотно прискорюючи операції отримання списку пакетів на файлових системах з великим розміром блоку, таких як ZFS. Раніше отримання заголовка пакета вимагало за промовчанням читання з диска всього 128KiB блоку.
  • Перевірка наявності нових файлів може опціонально використовувати підсистеми ядра kqueue та inotify, роблячи менше системних викликів.
  • Утиліти тримають менше відкритих файлів, рідше відбувається їх закриття та перевідкриття. При великій кількості пакетів раніше можна було впертись в обмеження на максимальну кількість відкритих файлів.
  • Багато команд почали показувати прогрес і швидкість виконання операцій, таких як скачування/вивантаження, копіювання та обробка (toss) пакетів.
  • Команда «nncp-file» може відправляти як одиничні файли, а й директорії, на льоту створюючи pax-архів зі своїми вмістом.
  • Online утиліти можуть опціонально відразу ж викликати процес обробки пакетів (tossing) після успішного скачування пакета, без запуску окремого демона «nncp-toss».
  • Online виклик іншого учасника може опціонально відбуватися не лише за подією спрацьовування таймера, а й за фактом появи вихідного пакета в spool-директорії.
  • Забезпечена працездатність під NetBSD та OpenBSD ОС, крім раніше підтримуваних FreeBSD та GNU/Linux.
  • "nncp-daemon" повністю сумісний з інтерфейсом UCSPI-TCP. Разом з можливістю журналування у вказаний файловий дескриптор (наприклад виставляючи «NNCPLOG = FD: 4»), він цілком доброзичливий для запуску під схожими на daemontools утилітами.
  • Складання проекту повністю переведено на систему redo.

Джерело: opennet.ru

Додати коментар або відгук