The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

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

15.11.2019 20:33

Состоялся релиз 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 5.0.0, по-сравнению с предыдущей новостью (версия 3.3), можно отметить:

  • Лицензия проекта с GPLv3+ изменена на GPLv3-only, из-за недоверия к Фонду СПО после ухода Ричарда Столлмана из него;
  • Используется полноценное AEAD шифрование ChaCha20-Poly135 128 KiB блоками. Это позволяет сразу же на лету аутентифицировать данные в зашифрованных пакетах, вместо выхода с ошибкой в конце чтения всего шифротекста;
  • Формат конфигурационного файла сменился с YAML на Hjson. Библиотека последнего существенно проще и меньше по размерам, при аналогичном удобстве работы человека с конфигурацией;
  • zlib алгоритм сжатия заменён на Zstandard: значительное повышение скорости сжатия при существенно более высокой эффективности;
  • nncp-call получил опцию просмотра имеющихся пакетов (-list) на удалённой стороне, без их скачивания. А также возможность выборочного скачивания пакетов (-pkts);
  • nncp-daemon получил опцию -inetd, позволяя ему запускаться под inetd или, например, через SSH;
  • Online соединения можно делать не только напрямую по TCP, но и вызывая внешние команды и общаясь через stdin/stdout. Например: nncp-call gw.stargrave.org "|ssh gw.stargrave.org nncp-daemon -inetd";
  • Дружелюбность команд к umask (используя расширенные права доступа типа 666/777) и возможность глобального выставления umask через конфигурационный файл, упрощая использование общей spool-директории среди нескольких пользователей;
  • Полное использование системы Go модулей.


  1. Главная ссылка к новости (https://lists.cypherpunks.ru/p...)
  2. OpenNews: Релиз NNCP 3.3, утилит для store-and-forward передачи файлов/почты/команд
  3. OpenNews: Релиз NNCP 0.7, утилит для безопасной передачи файлов/почты в режиме store-and-forward
  4. OpenNews: Первый релиз утилит NNCP для передачи файлов/почты в режиме store-and-forward
Автор новости: stargrave
Тип: Программы
Ключевые слова: nncp
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (51) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, JL2001 (ok), 22:34, 15/11/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    интересно как они её применяют, флопинет на уровне тора - это интересно
    а чем вызвано такое ограничение на небольшое количество нод?

    зы: есть ресурсы, где обсуждают распределёнку от распределённых фс типо Lustre, btrfs send/recive до всяких i2p, ipfs и nncp? хочется посмотреть на реальные юзкейсы и проблемы

     
     
  • 2.7, stargrave2 (?), 11:53, 16/11/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Tor-а тут нет. Ограничения технического на количество нод как такового нет, но вся маршрутизация между ними статическая и полностью задаётся людьми. Если маршруты меняются, то на всех, касающихся этого, нодах нужно поправить конфиги. Точно так же как в UUCP. Поэтому на практике управлять сетью более чем дюжины нод становится уже просто геморройно.
     
     
  • 3.14, и.о.К.О. (?), 15:05, 16/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >Ограничения технического на количество нод как такового нет, но вся маршрутизация между ними статическая и полностью задаётся людьми. Если маршруты меняются, то на всех, касающихся этого, нодах нужно поправить конфиги. Точно так же как в

    Точно так же как в FTN.

     
     
  • 4.15, stargrave2 (?), 15:30, 16/11/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    В FTN во время отправки пакета не нужно знать.задавать полностью весь маршрут следования. Нижестоящий отправляет вышестоящему, а дальше процесс уже не контролирует. Поинт отправил боссу и забыл. В NNCP нужно знать полностью весь маршрут (для луковичного шифрования) и, более того, промежуточные ноды должны знать предыдущего и следующего hop-а явно.
     
     
  • 5.18, и.о.К.О. (?), 23:49, 16/11/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Не обязательно, потому что в FTN каждый связан с каждым как минимум в ZMH Но ... текст свёрнут, показать
     
     
  • 6.19, stargrave2 (?), 01:08, 17/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Возможности разные Можно так, можно эдак В NNCP только один способ, в отличии ... текст свёрнут, показать
     
     
  • 7.23, JL2001 (ok), 01:37, 17/11/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >> Луковичного достаточно двух слоёв - один нижний шифрует ключем для конечого получателя,
    >> второй верхний до следующего узла в цепочке.
    > В этом случае подразумевается что решение о том куда маршрутизировать дальше принимают
    > транзитные участники. Это в NNCP избегается. Отправитель диктует как и что
    > должно через кого пройти.

    а для каких целей в NNCP отправитель выбирает полностью маршрут?

    извиняюсь если это где-то близко явно написано

     
     
  • 8.24, stargrave2 (?), 02:05, 17/11/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Для простоты - Или писать систему маршрутизации со всеми вытекающими проблем... текст свёрнут, показать
     
  • 7.28, и.о.К.О. (?), 11:33, 17/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Если это так то это недостаток Но из описания я не вижу явно такого фатального ... текст свёрнут, показать
     
     
  • 8.29, stargrave2 (?), 11:53, 17/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Это следует из того, что никакой системы маршрутизации нет Как в UUCP Всё зада... текст свёрнут, показать
     
     
  • 9.35, и.о.К.О. (?), 18:50, 17/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    В FTN по умолчанию вся почта идет директом, а маршрутизацию нужно принудительно ... текст свёрнут, показать
     
     
  • 10.40, stargrave2 (?), 20:56, 17/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    NNCP как-раз именно для такой вселенной, если вы ещё не поняли Где-то умерли, а... текст свёрнут, показать
     
  • 10.43, stargrave2 (?), 21:14, 17/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Замечу что всё это очевидно Очевидно какие минусы это всё несёт Никогда не зад... текст свёрнут, показать
     
     
  • 11.46, и.о.К.О. (?), 21:35, 17/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Ну хватит уже современное IP даже вместе с TCP это про низкую цену доставки ... текст свёрнут, показать
     
     
  • 12.48, stargrave2 (?), 21:43, 17/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Не спорю что цена крайне важна в большинстве случаев Однако есть много задач гд... текст свёрнут, показать
     
     
  • 13.51, и.о.К.О. (?), 22:25, 17/11/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Именно по цене одному маршруту назначается высокая цена мусорный трафик уходит... текст свёрнут, показать
     
     
  • 14.53, stargrave2 (?), 22:40, 17/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Вот это то как-раз и демагогия В идеале, в итоге, да Но какое-то время могут и... текст свёрнут, показать
     
  • 9.36, и.о.К.О. (?), 19:09, 17/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    На дворе 2021 год Осень Идет себе такой bob по лесу, сентябрьские зорькой по г... текст свёрнут, показать
     
     
  • 10.37, stargrave2 (?), 19:20, 17/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Очень печально что для вас это так всё смешно Впрочем вы же youtube как тран... текст свёрнут, показать
     
  • 6.20, stargrave2 (?), 01:13, 17/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Что должно заставить меня тратить время, силы, устанавливать,
    > изучать и использовать новую гемморойнойю фигню, если она сложнее, труднее, трудоемче
    > и потенциально враждебна (ведь доверия нет)? И не забывай, что еще
    > требуется и второго чела _заставить_).

    Для начала нужно вообще прочитать о чём проект, какие задачи пытается решать, а потом уже прикидывать надо оно тебе или нет. Если она сложнее, труднее, трудоёмче -- безусловно тогда нафиг использовать.  У преобладающего большинства людей нет задач которые бы помог решить NNCP. http://www.nncpgo.org/Sravnenie.html

    Но твоё предложение о email+PGP уже намекает на разряд сложных. До написания NNCP я много лет использовал UUCP+SSH+PGP (ну и SMTP который UUCP как транспорт использует) и кучу костылей. Задачи можно решить и без NNCP, вопрос удобства и трудозатрат.

     
     
  • 7.44, и.о.К.О. (?), 21:18, 17/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >   У преобладающего
    > большинства людей нет задач которые бы помог решить NNCP.

    Так это продукт для Избранных, да Нео?

    > http://www.nncpgo.org/Sravnenie.html

    Это смешная и некорректная табличка, демонстрирующая плохое (не полное) знание тех технологий с которыми сравнивается NNCP.  И это (незнание) подтверждается много где по тексту.

    Вопрос - если автор(ы) NNCP допускает такие элементарные ошибки в простом тексте, какие ошибки допущены в сложной программе? (в дополнение к уже выявленным "особенностям архитектуры").

    Надеюсь, теперь у автора есть feedback от пользователя, почему этот пользователь НЕ пользуется авторской утилитой и даже пробовать не хочет.

    Ведь автор на этот форум пришел именно за feedback?

     
     
  • 8.45, stargrave2 (?), 21:33, 17/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Возможно и за feedback-ом, в том числе Но не думаете же вы что я смогу учитыват... текст свёрнут, показать
     
  • 6.21, JL2001 (ok), 01:17, 17/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Луковичного достаточно двух слоёв - один нижний шифрует ключем для конечого получателя, второй верхний до следующего узла в цепочке. этот узел снимет верхний слой, завернет в новый слой до следующего узла. ни для отправителя ни для получателя слои (и ключи) транзитных узлов в середине цепочки не нужны. Ты им либо (в целом) доверяешь, либо нет

    но так будет всему маршруту известна целевая нода
    и против этого обычно ж делают несколько промежуточных хопов снимающих очередной слой и не знающих сколько хопов было до и будет после (и линия нод от хопаN до хопаN+1 знает только про них)
    (не знаю как это соотносится с NNCP)


    > второй верхний до следующего узла в цепочке

    а зачем мы вообще шифруем этот слой? что там секретного то?

     
     
  • 7.30, и.о.К.О. (?), 12:25, 17/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >> Луковичного достаточно двух слоёв - один нижний шифрует ключем для конечого получателя, второй верхний до следующего узла в цепочке. этот узел снимет верхний слой, завернет в новый слой до следующего узла. ни для отправителя ни для получателя слои (и ключи) транзитных узлов в середине цепочки не нужны. Ты им либо (в целом) доверяешь, либо нет
    > но так будет всему маршруту известна целевая нода

    И что?  Если ты не доверяешь транзитным узлам, не используй их. Отправляй директом.

    > и против этого обычно ж делают несколько промежуточных хопов снимающих очередной слой
    > и не знающих сколько хопов было до и будет после (и
    > линия нод от хопаN до хопаN+1 знает только про них)
    > (не знаю как это соотносится с NNCP)

    Тем не менее и такой клубок легко размотать, схавтив за кончик, ниточки. Учитывая стоимость аренды вычислительных ресурсов амазоновых облаков, это будет быстро и не дорого.
    А в данной схеме на каждом узле будет торчать по пучку, потянув за которые размотается много интересных клубочков.

    >> второй верхний до следующего узла в цепочке
    > а зачем мы вообще шифруем этот слой? что там секретного то?

    Там секретное всё, если ты, как обычно это делают авторы NNCP, отправляешь сообщения через открытый публичный wifi шанхайского опиумного притона с сисадмином школьником.

     
     
  • 8.34, JL2001 (ok), 15:57, 17/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    в нашем мире блокировок, дпи, натов, древнего железа и обнаглевших настроек дроп... текст свёрнут, показать
     
     
  • 9.38, и.о.К.О. (?), 19:46, 17/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    В IPv6 нет натов, свежее железо UPnP открывает порты ДПИ, слава богу, блокирует... текст свёрнут, показать
     
     
  • 10.41, stargrave2 (?), 21:03, 17/11/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Однако, JL2001 абсолютно прав в том, что на практике в 99 случаев на практике у... текст свёрнут, показать
     
     
  • 11.50, и.о.К.О. (?), 22:12, 17/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Да что вы говорите Конечно, для простого пользователя это несколько затруднител... текст свёрнут, показать
     
     
  • 12.52, stargrave2 (?), 22:38, 17/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    То есть, за людей принимает решение броузер а точнее компания его разрабатывающ... текст свёрнут, показать
     
  • 10.54, JL2001 (ok), 02:56, 18/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    серьёзно вы делаете мне смешно, полно натов работающих с ipv6, а главное блочащ... текст свёрнут, показать
     
  • 6.22, stargrave2 (?), 01:33, 17/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > ибо, вполне реальна ситуация в которой с одного из транзитных узлов до
    > другого узла 100 метров пакет можно отправить напрямую как дешевым "медленным"
    > маршрутом floppy net/голубиной почтой, так и через третий узел спутниковым интернетом
    > по $16USD за килобайт. уж точно не ему решать, случайному отправителю/домохозяйке/мелкому
    > драгдилеру решать.

    В NNCP как-раз считает ровно наоборот: уж точно отправителю решать какие ноды всё же могут увидеть проходящие сообщения, а какие нет. Хотя гарантий, чисто технически, никто безусловно дать не сможет. Но вот например broadcast-ить пакеты через спутник, где возможен анализ трафика (метаданных (время, факты, размеры)), не все могут захотеть. Или наоборот человек может захотеть не прямым маршрутом до кого-нибудь что-нибудь послать, а через тридевять земель промежуточных. Задачи эффективности передачи данных и экономики не ставится.

     
     
  • 7.31, и.о.К.О. (?), 12:58, 17/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >> ибо, вполне реальна ситуация в которой с одного из транзитных узлов до
    >> другого узла 100 метров пакет можно отправить напрямую как дешевым "медленным"
    >> маршрутом floppy net/голубиной почтой, так и через третий узел спутниковым интернетом
    >> по $16USD за килобайт. уж точно не ему решать, случайному отправителю/домохозяйке/мелкому
    >> драгдилеру решать.
    > В NNCP как-раз считает ровно наоборот: уж точно отправителю решать какие ноды
    > всё же могут увидеть проходящие сообщения, а какие нет.

    Это все хорошо, пока у тебя все ноды в виртуалбоксе на мамкином компе. в реальном мире всё совсем наоборот.

    Начиная с того, что при достаточно большом числе нод, у отправителя все время будет уходить на выбор маршрутов (и не останется на собственно продуктивную деятельность), заканчивая тем что "Anything that can go wrong will go wrong", тщательно выбранные транзитные ноды будут недоступны.

    > Но вот например broadcast-ить
    > пакеты через спутник, где возможен анализ трафика (метаданных (время, факты, размеры)),

    По умолчанию, метаданные снимаются _НА_ _КАЖДОМ_ хопе ip сети (и _в_ _особенности_ на тех хопах, которых не видно в tracerout),  а на спутниках для этого просто нет ресурсов и с точки зрения безопасности спутник ничем не отличается от 150 метрового патчкорда.

    > не все могут захотеть. Или наоборот человек может захотеть не прямым
    > маршрутом до кого-нибудь что-нибудь послать, а через тридевять земель промежуточных.

    Если не стоит задачи передавать скрытые собщения быстро и в дуплексе, идеальный вариант передавать скрытые сообщения - стеганография в видео на ютубе. Хотя и это (быстро, в дуплексе) решается стеганографическими врезками в тупые онлайн трансляциями видеоблогеров.

    > Задачи эффективности передачи данных и экономики не ставится.

    И совершенно напрасно.

     
     
  • 8.32, stargrave2 (?), 14:29, 17/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Именно поэтому в новости с самого начала и сказано что оно ориентировано на небо... текст свёрнут, показать
     
     
  • 9.39, и.о.К.О. (?), 20:33, 17/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Потому, что архитектор сделал плохой, ограниченный дизайн Поток данных с патчко... текст свёрнут, показать
     
     
  • 10.42, stargrave2 (?), 21:07, 17/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Потому что софт пишется не для абстрактных задач в вакууме, а для конкретных воз... текст свёрнут, показать
     
     
  • 11.47, и.о.К.О. (?), 21:43, 17/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Это JL2001 Видимо он прочитал ваши сценарии использования, где вы предлагает... текст свёрнут, показать
     
     
  • 12.49, stargrave2 (?), 21:47, 17/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Ой, даже не знаю где там такое написано или из чего можно было бы сделать такой ... текст свёрнут, показать
     

  • 1.2, Аноним (-), 01:12, 16/11/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    флоппинет... я думал, это шуточный термин...
     
     
  • 2.25, Аноним (25), 05:11, 17/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Военные так не думают.
     

  • 1.3, Anonymou (?), 04:52, 16/11/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    В условиях "золотого щита", кажется вполне разумным решением
     
  • 1.4, Аноним (4), 07:16, 16/11/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    чем оно лучше onion share?
     
     
  • 2.8, stargrave2 (?), 11:56, 16/11/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    В первую очередь, NNCP заточен под offline использование (изначально возможности online коммуникаций даже не было в нём). Во-вторую, NNCP никоим образом не пытается обеспечивать анонимность людей. В-третьих, NNCP это F2F сеть, где участники обязаны знать другу друга. Собственно, между ними толком то нет ничего общего в принципе.
     
     
  • 3.16, Аноним (16), 17:47, 16/11/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >В-третьих, NNCP это F2F сеть, где участники обязаны знать другу друга.

    Так и запишем: "организованной группой лиц по предварительному сговору".

     

  • 1.5, Ю.Т. (?), 09:20, 16/11/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Наверное, некая альтернатива интернету (контентной части его) не помешает.
     
  • 1.6, Аноним (6), 10:00, 16/11/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    > Лицензия проекта с GPLv3+ изменена на GPLv3-only, из-за недоверия к Фонду СПО после ухода Ричарда Столлмана из него;

    Интересный сигнальчик.
    Всё остальное в этой новости вторично.

     
     
  • 2.9, stargrave2 (?), 11:56, 16/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Сигнальчик к чему?
     
     
  • 3.10, JL2001 (ok), 12:43, 16/11/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Сигнальчик к чему?

    к брожению умов
    люди доверяют человеку, но не деверяют организации, которую он возглавлял

     
     
  • 4.11, stargrave2 (?), 12:59, 16/11/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Нет доверия к лицемерам его окружавших.
     
  • 3.12, Аноним (6), 13:10, 16/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    К нехорошему. Организации не доверяют, это аукнется в будущем. Спектр плохого может быть широк от гплв4 передает безусловно все права фсф, до права предоставляются всем и на всё. Не знаю сделали они это в поддержку РМС или проинтуичили. В будущем возможна дефрагментация идеологии по разным течениям. А это ничего хорошего нам не принесет.
     
     
  • 4.13, Аноним (13), 13:28, 16/11/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >В будущем возможна дефрагментация идеологии по разным течениям.

    Как раз таки, к фрагментации идеологии, к сожалению.

     
     
  • 5.17, Аноним (6), 20:24, 16/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Извиняюсь, по запарке написал. Ты совершенно прав.
     
  • 2.55, Owlet (?), 00:19, 19/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Ничего интересного. Людей, которые будут оправдывать своих кумиров до последнего, пруд пруди, в IT  и вне его.
     

  • 1.26, Онаним (?), 08:36, 17/11/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Какое-то эпическое ненужно эпохи мамонтов. Особенно с учётом 100% верификации "повязанности" между собой участников сети.
     
  • 1.27, Аноним (-), 09:42, 17/11/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >Так как ключ для дешифровки находится только у получателя, независимо от путей доставки пакета по сети или через физические носители, третье лицо не может прочитать содержимое, даже перехватив отправление

    они изобрели pgp?

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Слёрм
    Inferno Solutions
    Hosting by Ihor
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2019 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру