Wydano Node-to-Node CoPy (NNCP), zestaw narzędzi do bezpiecznego przesyłania plików, e-maili i poleceń wykonywanych w trybie store-and-forward. Obsługiwane są systemy operacyjne zgodne z POSIX. Narzędzia zostały napisane w języku Go i są dystrybuowane na licencji GPLv3.
Narzędzia te są zaprojektowane z myślą o budowie małych, rówieśniczych sieci typu friend-to-friend (kilka węzłów) z statycznym routowaniem do bezpiecznego przesyłania plików w trybie fire-and-forget, zapytań o pliki, e-maili oraz żądań wykonywania poleceń. Wszystkie przesyłane pakiety są szyfrowane (end-to-end) i wyraźnie uwierzytelniane za pomocą znanych publicznych kluczy znajomych. Szyfrowanie cebulowe (jak w Tor) stosowane jest dla wszystkich pośrednich pakietów. Każdy węzeł może działać zarówno jako klient, jak i serwera i stosować zarówno model push, jak i poll.
Różnicą między NNCP a rozwiązaniami UUCP i FTN (FidoNet Technology Network), oprócz wspomnianego szyfrowania i uwierzytelniania, jest wsparcie dla sieci floppy i komputerów fizycznie izolowanych (air-gapped) od niebezpiecznych sieci lokalnych i publicznych. Cechą NNCP jest także łatwa integracja (obok UUCP) z obecnymi serwerami pocztowymi serwerami, takimi jak Postfix i Exim.
Możliwe obszary zastosowania NNCP obejmują organizację wysyłania/odbierania poczty na urządzeniach bez stałego dostępu do Internetu, przesyłania plików w warunkach niestabilnego połączenia sieciowego, bezpieczne przesyłanie bardzo dużych woluminów danych na nośnikach fizycznych, tworzenie chronionych przed atakami MitM izolowanych sieci transmisji danych, obejście cenzury sieciowej i inwigilacji. Ponieważ klucz do deszyfrowania znajduje się tylko u odbiorcy, niezależnie od ścieżek dostawy pakietu w sieci lub przez nośniki fizyczne, trzecia strona nie może odczytać zawartości nawet po przechwyceniu przesyłki. Z kolei uwierzytelnianie za pomocą podpisu cyfrowego nie pozwala na sfałszowanie przesyłki pod pretekstem innego nadawcy.
Wśród nowości NNCP 8.8.0, w porównaniu do poprzedniej wersji (5.0.0):
- Zamiast hasha BLAKE2b do sprawdzania integralności plików zastosowano tzw. MTH: Merkle Tree-based Hashing wykorzystujący hash BLAKE3. Umożliwia to obliczanie integralności zaszyfrowanej części pakietu w trakcie pobierania, bez potrzeby późniejszego jej odczytu. Daje to również możliwość nieograniczonego równoległego sprawdzania integralności.
- Nowy format zaszyfrowanych pakietów jest całkowicie przyjazny dla transmisji strumieniowej, gdy rozmiar danych jest wcześniej nieznany. Sygnalizacja zakończenia transmisji, wraz z uwierzytelnionym rozmiarem, odbywa się bezpośrednio wewnątrz zaszyfrowanego strumienia. Wcześniej, aby poznać rozmiar przesyłanych danych, konieczne było ich zapisanie w pliku tymczasowym. W ten sposób opcja „-use-tmp” dla zespołu „nncp-exec” zniknęła z powodu całkowitej nieprzydatności.
- Funkcje BLAKE2b KDF i XOF zostały zastąpione BLAKE3 w celu zmniejszenia liczby wykorzystywanych prymitywów kryptograficznych i uproszczenia kodu.
- Pojawiła się możliwość wykrywania innych węzłów w lokalnej sieci przez rozgłaszanie multicastowe pod adresem „ff02::4e4e:4350”.
- Pojawiły się grupy multicastowe (analogiczne do echokonferencji FidoNet lub grup dyskusyjnych Usenet), umożliwiające wysyłanie danych w jednym pakiecie do wielu uczestników grupy, gdzie każdy również retransmituje pakiet do pozostałych subskrybentów. Odczytanie pakietu multicastowego wymaga znajomości pary kluczy (należy być wyraźnie uczestnikiem grupy), ale retransmisję może przeprowadzić dowolny węzeł.
- Wbudowano wsparcie dla jawnego potwierdzenia odbioru pakietu. Nadawca może nie usuwać pakietu po wysłaniu, czekając na specjalny pakiet ACK od odbiorcy.
- Zintegrowano wsparcie dla sieci overlay Yggdrasil: online demony mogą być w pełni samodzielnymi uczestnikami sieci, bez korzystania z zewnętrznych implementacji Yggdrasil i pełnej pracy z stosem IP na wirtualnym interfejsie sieciowym.
- Zamiast zorganizowanych ciągów (RFC 3339), dziennik wykorzystuje zapisy recfile, z którymi można używać narzędzi GNU Recutils.
- Opcjonalnie nagłówki zaszyfrowanych pakietów mogą być przechowywane w oddzielnych plikach w podkatalogu „hdr/”, co znacznie przyspiesza operacje uzyskiwania listy pakietów w systemach plików z dużym rozmiarem bloku, takich jak ZFS. Wcześniej uzyskanie nagłówka pakietu wymagało domyślnie odczytu z dysku całego bloku 128KiB.
- Opcjonalnie można użyć podsystemów jądra kqueue i inotify do sprawdzenia dostępności nowych plików, ograniczając liczbę wywołań systemowych.
- Narzędzia trzymają mniej otwartych plików, co rzadziej prowadzi do ich zamykania i ponownego otwierania. Przy dużej liczbie pakietów wcześniej można było napotkać ograniczenie maksymalnej liczby otwartych plików.
- Wiele poleceń zaczęło wyświetlać postęp i prędkość wykonywania operacji, takich jak pobieranie/ładowanie, kopiowanie i przetwarzanie (toss) pakietów.
- Polecenie «nncp-file» może przesyłać nie tylko pojedyncze pliki, ale także katalogi, tworząc w locie archiwum pax z ich zawartością.
- Narzędzia Online mogą opcjonalnie od razu wywoływać proces przetwarzania pakietów (tossing) po pomyślnym pobraniu pakietu, bez uruchamiania osobnego demona «nncp-toss».
- Online wywołanie innego uczestnika może opcjonalnie następować nie tylko po zdarzeniu aktywacji timera, ale także po fakcie pojawienia się wychodzącego pakietu w katalogu spool.
- Została zapewniona kompatybilność z systemami NetBSD i OpenBSD, oprócz wcześniej wspieranych FreeBSD i GNU/Linux.
- «nncp-daemon» jest w pełni zgodny z interfejsem UCSPI-TCP. W połączeniu z możliwościami rejestrowania w określonym deskryptorze pliku (na przykład ustawiając «NNCPLOG=FD:4»), jest całkowicie przyjazny dla narzędzi podobnych do daemontools.
- Budowa projektu w pełni przeszła na system redo.
Źródło: opennet.ru
