Wydanie NNCP 8.8.0, narzędzia do przesyłania plików/poleceń w trybie przechowywania i przekazywania

Wydanie Node-to-Node CoPy (NNCP), zestawu narzędzi do bezpiecznego przesyłania plików, wiadomości e-mail i poleceń do wykonania w trybie przechowywania i przesyłania. Obsługuje działanie w systemach operacyjnych zgodnych z POSIX. Narzędzia są napisane w Go i rozpowszechniane na licencji GPLv3.

Narzędzia te skupiają się na pomaganiu w budowaniu małych sieci peer-to-peer typu przyjaciel-znajomy (dziesiątki węzłów) z routingiem statycznym w celu bezpiecznego przesyłania plików typu „wystrzel i zapomnij”, żądań plików, wiadomości e-mail i żądań poleceń. Wszystkie przesyłane pakiety są szyfrowane (end-to-end) i jawnie uwierzytelniane przy użyciu znanych kluczy publicznych znajomych. Szyfrowanie Onion (podobnie jak w Toru) jest używane dla wszystkich pakietów pośrednich. Każdy węzeł może działać zarówno jako klient, jak i serwer i używać zarówno modeli zachowań push, jak i poll.

Różnica pomiędzy rozwiązaniami NNCP i UUCP oraz FTN (FidoNet Technology Network), oprócz wspomnianego wcześniej szyfrowania i uwierzytelniania, polega na gotowej obsłudze sieci floppinet i komputerów fizycznie odizolowanych (szczelinowych) od niepewnych sieci lokalnych i sieci publiczne. NNCP charakteryzuje się także łatwą integracją (na równi z UUCP) z obecnymi serwerami pocztowymi, takimi jak Postfix i Exim.

Możliwe obszary zastosowań NNCP obejmują organizację wysyłania/odbierania poczty na urządzenia nieposiadające stałego połączenia z Internetem, przesyłanie plików w warunkach niestabilnego połączenia sieciowego, bezpieczne przesyłanie bardzo dużych ilości danych na nośnikach fizycznych, tworzenie izolowanych sieci transmisji danych chronionych przed Ataki MitM z ominięciem cenzury i nadzoru sieci. Ponieważ klucz deszyfrujący znajduje się wyłącznie w rękach odbiorcy, niezależnie od tego, czy pakiet jest dostarczany przez sieć, czy za pośrednictwem nośnika fizycznego, osoba trzecia nie może odczytać zawartości, nawet jeśli pakiet zostanie przechwycony. Z kolei uwierzytelnianie podpisu cyfrowego nie pozwala na utworzenie fikcyjnej wiadomości pod przykrywką innego nadawcy.

Wśród innowacji NNCP 8.8.0 w porównaniu do poprzednich nowości (wersja 5.0.0):

  • Zamiast skrótu BLAKE2b do sprawdzania integralności plików używany jest tzw. MTH: Merkle Tree-based Hashing, który wykorzystuje hash BLAKE3. Pozwala to obliczyć integralność zaszyfrowanej części pakietu już podczas pobierania, bez konieczności jego odczytywania w przyszłości. Pozwala to również na nieograniczoną równoległość kontroli integralności.
  • Nowy format zaszyfrowanego pakietu jest całkowicie przyjazny dla przesyłania strumieniowego, gdy rozmiar danych nie jest z góry znany. Sygnalizacja zakończenia transferu o uwierzytelnionym rozmiarze trafia bezpośrednio do zaszyfrowanego strumienia. Wcześniej, aby dowiedzieć się o rozmiarze przesyłanych danych, konieczne było zapisanie ich w pliku tymczasowym. Zatem polecenie „nncp-exec” utraciło opcję „-use-tmp”, ponieważ jest ona całkowicie niepotrzebna.
  • Funkcje BLAKE2b KDF i XOF zostały zastąpione przez BLAKE3 w celu zmniejszenia liczby używanych prymitywów kryptograficznych i uproszczenia kodu.
  • Możliwe jest teraz wykrywanie innych węzłów w sieci lokalnej poprzez multiemisję na adres „ff02::4e4e:4350”.
  • Pojawiły się grupy multiemisji (analogicznie do konferencji echo FidoNet lub grup dyskusyjnych Usenet), umożliwiające przesyłanie danych jednym pakietem do wielu członków grupy, przy czym każdy z nich przekazuje również pakiet pozostałym sygnatariuszom. Odczyt pakietu multiemisji wymaga znajomości pary kluczy (musisz jawnie być członkiem grupy), ale przekazywanie może odbywać się przez dowolny węzeł.
  • Dostępna jest teraz obsługa wyraźnego potwierdzenia odbioru pakietu. Nadawca nie może usunąć pakietu po wysłaniu, czekając aż otrzyma od odbiorcy specjalny pakiet ACK.
  • Wbudowana obsługa sieci nakładkowej Yggdrasil: demony online mogą działać jako pełnoprawni niezależni uczestnicy sieci, bez korzystania z implementacji Yggdrasil innych firm i bez pełnej współpracy ze stosem IP w interfejsie sieci wirtualnej.
  • Zamiast ciągów strukturalnych (RFC 3339) dziennik wykorzystuje wpisy w pliku rec, których można używać z narzędziami GNU Recutils.
  • Opcjonalnie zaszyfrowane nagłówki pakietów można przechowywać w oddzielnych plikach w podkatalogu „hdr/”, co znacznie przyspiesza operacje pobierania listy pakietów w systemach plików o dużych rozmiarach bloków, takich jak ZFS. Poprzednio pobranie nagłówka pakietu wymagało domyślnie odczytania z dysku tylko bloku o wielkości 128 KB.
  • Sprawdzanie nowych plików może opcjonalnie korzystać z podsystemów jądra kqueue i inotify, wykonując mniej wywołań systemowych.
  • Narzędzia przechowują mniej otwartych plików oraz rzadziej je zamykają i otwierają ponownie. Przy dużej liczbie pakietów wcześniej można było napotkać ograniczenie maksymalnej liczby otwartych plików.
  • Wiele zespołów zaczęło pokazywać postęp i szybkość operacji takich jak pobieranie/wysyłanie, kopiowanie i przetwarzanie (przerzucanie) pakietów.
  • Komenda „nncp-file” może wysyłać nie tylko pojedyncze pliki, ale także katalogi, tworząc na bieżąco archiwum pax z ich zawartością.
  • Narzędzia internetowe mogą opcjonalnie natychmiast wywołać podrzucanie pakietów po pomyślnym pobraniu pakietu, bez uruchamiania osobnego demona „nncp-toss”.
  • Połączenie online z innym uczestnikiem może opcjonalnie nastąpić nie tylko po uruchomieniu licznika czasu, ale także wtedy, gdy w katalogu buforowym pojawi się pakiet wychodzący.
  • Zapewnia funkcjonalność pod NetBSD i OpenBSD OS, oprócz wcześniej obsługiwanych FreeBSD i GNU/Linux.
  • „nncp-daemon” jest w pełni kompatybilny z interfejsem UCSPI-TCP. W połączeniu z możliwością logowania do określonego deskryptora pliku (na przykład poprzez ustawienie „NNCPLOG=FD:4”), uruchamianie go w narzędziach podobnych do daemontools jest całkowicie przyjazne.
  • Montaż projektu został w całości przeniesiony do systemu Redo.

Źródło: opennet.ru

Dodaj komentarz