image


Сегодня я хотел бы рассказать о результатах моих семилетних исследований в области передачи голоса через сеть Tor. Общепринятым является мнение, что голосовая связь через Tor почти невозможна:

  • существующие транспортные протоколы для телефонии работают поверх UDP, а Tor обеспечивает лишь TCP соединения;
  • Tor маршрутизирует пакеты через множество узлов, шифруя данные, что является причиной значительной латентности и делает дуплексную телефонную связь невозможной или крайне некомфортной.

Но так ли это на самом деле?

В далеком 2012 году я впервые задумался о принципиальной возможности реализации анонимной телефонной связи с использованием анонимизаторов Tor и i2p. Реакция сообщества была однозначно отрицательной, включая самого Филла Циммермана, автора знаменитого PGPFone, на базе которого работал первый Торфон. Но я был упрям, проверял новые идеи, тестировал и улучшал найденные трюки, в основном направленные на снижение латентности до приемлемого уровня. В данном направлении также работали и другие исследователи, и их публикации давали мне новые идеи и почву для дальнейшей работы. Положительными моментами было значительное ускорение глобальной сети Интернет и сети Tor в частности, а также постепенное отвыкание пользователей от PSTN в пользу GSM связи с присущей ей значительной латентностью. Наконец, подходящая концепция была выработана, и настал черед реализации задуманного.
В 2013 году Roger Dingledine в личной переписке жестко раскритиковал проект за отсутствие кроссплатформенности (на тот момент в качестве базы использовался PGPFone на Windows-платформе) и за не-модулярную архитектуру. На фоне этой критики была заложена почва для современной реализации Торфона с учетом множества проб и ошибок, а также современных тенденций в криптографии.

Сегодня Торфон состоит из четырех программных модулей, взаимодействующих друг с другом с помощью 36-байтных пакетов со строго фиксированными полями. Это транспортный модуль, обеспечивающий работу с сокетами, модуль криптографии и звука, модуль хранилища (производит операции с приватным ключом и содержит зашифрованную адресную книгу) и модуль пользовательского интерфейса. Они могут быть запущены на одной аппаратной платформе (в одном или в различных потоках) или на нескольких изолированных платформах, использующих в качестве интерфейса стандартный последовательный протокол (аппаратный UART, USB CSD или Bluetooth SPP). Данная архитектура позволяет разработчику определять компромисс между защищенностью и удобством реализации. Доступны варианты от автономного Windows-приложения до аппаратной реализации в виде одноплатника с Linux для Tor и транспортного модуля в связке с изолированным Cortex M4 микроконтроллером, на котором выполняется шифрование, полная обработка и проигрывание аудио, хранение приватного ключа и контактов, реализован графический интерфейс пользователя.

Исходный код модулей написан на C и является полностью кроссплатформенным, за исключением низкоуровневой работы с аудио, вынесенной в отдельные файлы, специфичные для Windows (Wave), Linux (Alsa), Android (OpenSL) и bare metal (ADC/DAC+DMA для микроконтроллера).
При выборе аудиокодека и очереди учитывались особенности сети Tor: периодические частые спонтанные задержки, некоторое снижение латентности для пакетов в определенном диапазоне длины, возможность в процессе звонка создавать дублирующие цепочки с различными путями маршрутизации и т.п. В промежуточный проект OnionPhone были включены 17 самых распространенных низкобитрейтных аудиокодеков. После тщательного тестирования был выбран наиболее подходящий вариант: AMR с минимальным для него битрейтом 4750 bps и с быстродействующим VAD. Таким образом, с учетом естественных пауз между словами и дуплексной природы общения, итоговый средний битрейт в каждом направлении составляет около 2000-3000 bps., что дает возможность использовать GPRS даже в условиях плохого GSM — покрытия и массивных потерь GSM пакетов.

В качестве подавителя шума применен эффективный алгоритм NPP7, разработанный для борьбы с интенсивными аудиопомехами и входящий в составе кодека MELPe – действующего стандарта военной связи STANAG-4591. Алгоритм эхоподавления был выбран из проекта WebRTC как наиболее эффективный из доступных открытых решений.

Общий функционал Торфона разрабатывался с учетом возможных вариантов использования и существующих моделей угроз, уже применявшихся против популярных мессенджеров.

Основные режимы работы:

  1. Анонимные голосовые звонки на скрытый сервис Tor (по onion-адресу). Эти звонки максимально защищены, но ощущается некоторая задержка, что может вызывать определенный дискомфорт у непривыкших пользователей.
  2. Переключение на прямое UDP соединение (с проходом NAT) после установки Tor-соединения. Сессионные ключи шифрования, согласованные внутри Tor, обеспечивают надежную конфиденциальность, но анонимность теряется (пользователи раскрывают свой IP адрес друг другу).
  3. Прямые звонки по указанному IP-адресу (или доменному имени) и номеру TCP порта. Для приема таких звонков требуется наличие «белого» (маршрутизируемого) IP адреса на устройстве (многие сотовые операторы предлагают это в качестве платной услуги) или «проброс» использующегося TCP-порта на локальном роутере (например, в домашней WiFi сети). Прямые звонки могут осуществляться в изолированной локальной сети (например, локальной WiFi сети, созданной с помощью мощной точкой доступа, установленной в центре зоны обслуживания). В этом случае Торфон не требует взаимодействия с интернет: у проекта нет своего сервера, являющегося точкой потенциального отказа, атак и сбора метаданных. Таки образом, Торфон может успешно работать даже при полной изоляции сегмента сети или всего Рунет на государственном уровне.

Сегодня достаточно часто поднимается вопрос доверия к Tor как в плане сохранения анонимности, так и в плане конфиденциальности передаваемых данных. Известный мессенджер TorChat не использовал своего шифрования и аутентификации, полностью полагаясь на сервисы, предоставляемые Tor. Лично я доверяю Tor, во всяком случае, в плане обеспечения конфиденциальности и совершенной обратной секретности. Но, к сожалению, такая позиция омрачена открытием глобальных уязвимостей SPECTRE / MELTDOWN, а также массой уязвимостей нулевого дня для всех известных операционных систем, практически используемых в качестве рабочих инструментов в арсенале любой спецслужбы. Поэтому я не смог пойти по пути TorChat и добавил в Торфон собственный слой шифрования и аутентификации, использующий самые современные протоколы и доказуемо стойкие криптографические примитивы.

В основе концепции лежит возможность осуществлять звонки между незнакомыми абонентами, а затем автоматически обмениваться своими публичными ключами для взаимной аутентификации в последующих сеансах связи. Данный подход обеспечивает определенную отрицаемость в вопросе наличия компрометирующего ключа в списке ваших контактов: любой абонент, зная ваш онион-адрес, может осуществить анонимный звонок и тут же переслать вам любой контакт из своей записной книги. Этот контакт будет автоматически добавлен в вашу адресную книгу. Впрочем, эту возможность можно отключить в настройках, но кто знает, была ли она у вас включена раньше?

Особое внимание уделено защите идентификаторов абонентов. Так, вызывающий абонент знает, кому он звонит, и должен ему сообщить свой ID (ключ). Но только ему и никому другому! Мало того, если соединение будет перехвачено, в том числе активным атакующим, а позже все приватные ключи участников будут раскрыты, не существует возможности установить (или выбрать из списка известных) идентификаторы участников в каждой пробе или перехваченной сессии в прошлом. Другими словами, обеспечивается защита ID вызывающего и вызываемого абонентов с совершенной обратной секретностью (PFS). Это удалось достичь, модифицировав протокол Triple-DH (тройной Диффи-Хеллман, применяемый в том числе и в Signal) добавлением параллельно выполняемого протокола SPEKE, обеспечивающего нулевое разглашение в отношении явных (explicit) аутентификаторов, которыми обмениваются стороны на этапе начального обмена ключами.

Используемый в Торфоне протокол имеет свойство отрицаемости (Deniability), когда после завершенного сеанса связи злонамеренная сторона не может убедить судью в том, что действительно контакт имел место. Также обеспечивается отрицаемость наперед (Forward Deniability), когда злонамеренная сторона заранее договаривается с судьей о том, что будет проводить сеанс, и после завершения сеанса пытается доказать, что он имел место. Полная отрицаемость (Full Deniability, когда злонамеренная сторона контактирует с судьей во время сеанса связи), конкурирует с таким важным свойством, как KCI — устойчивость (невозможность представиться другим перед абонентом, приватный ключ которого известен). Исходя из практических реалий, предпочтение было в пользу KCI -устойчивости, как более практичного свойства, особенно в условиях неправовых отношений.

Из дополнительных возможностей аутентифицировать друг друга при первом контакте (для гарантии достоверности обмена ключей) реализовано два протокола:

  • сравнение короткого отпечатка общего секрета (SAS, аналогично как в протоколе ZRTP). Для блокирования атаки подбора короткого отпечатка в процессе MitM используется коммитмент в процедуре Диффи-Хеллмана. Кроме того, отпечаток общего секрета автоматически включается в имя контакта, принятого в данной сессии. Таким образом, при обмене контактами в течение одной сессии начало имени нового контакта у обоих участников должно быть одинаковым, что можно проверить позже, например, при личной встрече. И, кстати, полученный контакт нужно обязательно переименовать для того, чтобы разрешить Торфону представлять себя (свой ID) этому контакту.
  • сравнение заранее согласованного секрета (слова, фразы). В OTR аналогичную функцию выполняет протокол Социалиста-Миллионера. В Торфоне используется аналогичный по свойствам (с нулевым разглашением) протокол SPEKE.

В случае, если у обоих участников сеанса имеются контакты (публичные ключи) друг друга, если аутентификация успешна и используется Tor (звонок на онион-адрес), то принимающая сторона осуществляет встречный звонок, используя онион-адрес вызывающей стороны из своей адресной книги. После установления соединения производится взаимная аутентификация по второму каналу, подтверждающая онион-адрес звонящего абонента. Аналогичную процедуру использует TorChat для аутентификации чатов, используя в качестве ID онион-адрес контакта.

Параллельное Tor-соединение состоит из иных цепочек, что выгодно используется для компенсации спонтанных задержек: речевые пакеты отправляются сразу в оба канала, используется пакет, пришедший ранее. Кроме того, ведется статистика задержек в обоих каналах, и, если один из каналов значительно медленнее, то он периодически переподключается в процессе разговора. Это снижает общую латентность аутентифицированного звонка в сравнении со звонком от неизвестного абонента.

Как показывает печальная практика, сегодня весьма важно научить приложение защищаться от возможных блокировок. К счастью, Торфон не имеет собственного сервера или облака, используя вместо него Tor. Поэтому блокировка Торфона возможна лишь путем блокировки Tor. Но сегодня это – тоже реальность, и в подобном случае останется лишь возможность выполнения звонков непосредственно на IP — адрес и TCP порт. В самом пессимистичном сценарии большой брат будет пытаться научить системы DPI (глубокого анализа пакетов) выявлять в контролируемой сети p2p трафик между двумя Торфонами. Поэтому были приняты дополнительные меры для максимального сокрытия такого трафика. Во первых, слушающий порт TCP может быть выбран вручную и фактически является частью адреса абонента. Во вторых, абсолютно все пакеты (в том числе и звуковые) в течение сеанса связи (TCP — сессии) не имеют никаких отличительных особенностей (постоянных или инкрементируемых полей, длины и т.п.) и для внешнего наблюдателя выглядят как случайные данные случайной длины. В третьих, для проведения активной пробы протокола требуется «подтверждение работы» (Proof of Job) в качестве защиты от массированного сканирования адресов и портов на предмет обнаружения Торфонов.

Фактически соединение выполняется двумя последовательными TCP — подключениями. Во время первого подключения стороны обмениваются первичными сессионными ключами в виде точек на эллиптической кривой X25519, выполняя обычный протокол Диффи-Хеллмана. Так как Montgomery-формат представления точки не является случайным числом, используется представление Elligator2, дополненное случайными байтами. После выведения общего секрета первая сессия разрывается, и через случайный промежуток времени (несколько секунд) устанавливается вторая сессия, все данные в которой зашифрованы ключом, выведенным из общего секрета. Генерируются новые сессионные ключи, и протокол Диффи-Хеллмана выполняется еще раз, теперь уже с коммитментом. Из полученного секрета выводятся симметричные ключи для шифрования и расшифровки. Затем выполняется тройной протокол Диффи-Хеллмана параллельно с протоколом SPEKE для защиты ID вызывающего абонента и аутентификации. В случае отсутствия ключей в адресной книге (неизвестный контакт) или любого несоответствия все сообщения заменяются случайными байтами., т.е. протокол не прерывается для предотвращения утечки информации об идентичности участников.

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

Для слоя обфускации был выбран симметричный алгоритм Serpent-128, работающий в режиме аутентифицированного шифрования OCB. Для основного слоя симметричного шифрования используется преобразование Keccak-800 в виде функции Shake-128 и однонаправленный счетчик пакетов CTR. Этот же примитив используется в качестве Hash, MAC и PKDF. Для шифрования адресной книги и генератора псевдослучайных чисел используется алгоритм ChaCha20. Ресидирование генератора производится в начале каждой сессии, для накопления энтропии в мультизадацных операционных системах используется алгоритм Havege, а в микроконтроллере – младший бит результата АЦП, измеряющего шум резистивного делителя. Накопление энтропии производится до необходимого количества, оцениваемого с помощью группового частотного теста.

Основные криптографические примитивы (элементарная математика для X25519, Keccak800, ChaCha20) используют не оптимизируемые компилятором ассемблерные реализации для микроконтроллерных платформ (Cortex M1 и M4), тщательно проверенные на постоянство времени выполнения и с минимизированными утечками по побочным каналам ЭМИ и флуктуаций тока потребления. Сразу скажу – эти ассемблерные коды получены от профессионалов с мировыми именами, я лишь портировал их из GNU ASM в среду Keil, более привычную для сборки встроенных проектов.

Ну, что в итоге?

Если вы дочитали до этого места и не умерли со скуки, то значит, этот проект Вам действительно может быть полезен. Если так, то по запросу на почту рад предоставить тестовые сборки (статически линкованные исполняемые файлы, не требуемые установки), а также исходные коды графического интерфейса для Windows, Linux и Android в соответствующих средах разработки. Ядро проекта выполнено на базе кроссплатформенной библиотеки torfone, доступной поиском на github. Там же можно найти прямые ссылки на альфа-версию Андроид-приложения и краткое руководство по его установке и использованию, что поможет всем желающим оценить латентность телефонии в сети Tor.

Графический интерфейс реализован отдельно для каждой платформы и не является вариантом выбора (пока что это лишь альфа-тестирование). Тестовое приложение для всех версий Windows (начиная с древней Windows 98) выполнено в старом, но мощном Borland C++ Builder 6. Для Linux GUI-приложение разрабатывалось с использованием забытой Wide Studio для графики X11 отдельно для i386 и ARM архитектур. Первое должно работать как на 32- так и на 64-разрядных десктопах, второе – на недорогих одноплатных компьютерах: RPi, Orange, Nano и др. Для Android доступен apk-файл, собранный в Embarcadero RAD Studio 10.2. Это далеко не лучший вариант и пока что не умеет создавать Foreground service, но, тем не менее, стабильно работает в Background при отключенной оптимизации использования батареи. Также в среде Android поддерживается автоматическое резервное копирование файлов конфигурации, ключей и адресной книги (в зашифрованном виде) во внешнее хранилище и восстановление при переустановке Торфона или переносе на другое устройство. На момент написания статьи ведется работа над проектом в среде Keil uVision, включающим транспортный, шифровальный модули, аудио и графический интерфейс на базе Arduino — совместимого 320*240 TFT+Touch дисплея. В качестве открытой аппаратной платформы будет использована NanoPi Neo c устанвовленным Debian server и плата Nucleo STM32F446RE, соединенные через физический UART. В отдаленных планах – портирование в iOS, хотя я с трудом понимаю, как это может сочетаться с элементарными гарантиями безопасности.

И в завершение.

Мне часто задают одни и те же вопросы: как можно управлять пользователями без центрального сервера? Как забрасывать обновления, рекламу? И, главное, зачем это все мне нужно, если в этом нет коммерческой ценности?

На самом деле мир не такой серый и испорченный. И есть много ценностей, которые не измерить деньгами. А ответ на первые два вопроса – никак. Ну, нельзя Торфон остановить. Нельзя получить от него «ключи», слить действия пользователей, даже замеченных в терроризме или педофилии, нельзя забанить неугодных. Нельзя заставлять обновляться. Нельзя управлять извне. Нет в Торфоне никаких утечек, побочных соединений, кроме как предусмотренных протоколом. Это можно легко проверить как в коде (почти каждая строчка прокомментирована и не так уж много файлов в проекте), так и сетевыми анализаторами. Поэтому никто не сможет управлять пользователями Торфона. Но помните: Торфон – лишь инструмент, а все ваши действия – на вашей совести, и за них отвечаете вы, а не автор проекта.

Комментарии (62)


  1. StarTrinity_CEO
    21.04.2019 16:10

    спасибо, интересно
    вы сами лично от проекта что-либо получаете?


    1. gegel Автор
      22.04.2019 20:37

      Нет. Каким образом? Нет сервера — нет возможности управлять пользователями.


  1. googlodrocher
    21.04.2019 17:25

    Хорошая работа.


    1. alexkbs
      22.04.2019 05:42

      Если кто-то пришел сюда найти ссылку на репо, то вот она:


      https://github.com/gegel/torfone


      (Автора очень хотелось бы попросить отформатировать текст, раз уж он уже приглашен, расставить абзацы и ссылки. Спасибо большое.)


  1. Tzimie
    21.04.2019 17:37
    +1

    Ихние публикации???
    Извините, но Хабр пал в моих глазах


    1. karavan_750
      21.04.2019 17:45
      +1

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


    1. unwrecker
      21.04.2019 19:32
      +1

      Извините, но вы сами пали в глазах всех, кто знает Русский не из мемасиков.


      http://gramota.ru/slovari/dic/?word=%D0%B8%D1%85%D0%BD%D0%B8%D0%B9&all=x


      1. DoctorMoriarty
        21.04.2019 21:44

        >Русский не из мемасиков

        Исключительно справедливости ради замечу, что если прогуляться по ссылкам помимо вашей, то выяснится, что обсуждаемое местоименное прилагательное относится к просторечным, употребляемым в речи малообразованных людей и в литературе используется, как правило, как художественный приём для отражения речи вышеупомянутой категории людей. «Живой язык» != «престижная норма».


        1. unwrecker
          21.04.2019 22:18

          Пусть не престижная норма, но уж точно не ошибка и не повод для проявления гнева. У Достоевского, кстати, используется широко, в том числе в тексте от автора.


      1. ParAmbula
        22.04.2019 19:33

        Как сказал один лингвист — «Если 90% страны говорит неправильно, это становится нормой»


    1. id_potassium_chloride
      22.04.2019 00:23
      +1

      В таких случаях Хабр рекомендует дипломатично выделить ошибку, нажать Ctrl+Enter и тихо сообщить об этом автору.


      1. Tzimie
        22.04.2019 09:10

        Спасибо
        А с телефона это можно?
        Мобильная функциональность сильно ограничена


        1. id_potassium_chloride
          22.04.2019 17:47

          Вроде бы с телефона можно только если зайти на полную версию сайта и клавиатура позволяет зажать Ctrl (то есть USB/Bluetooth клавиатура или типа HackerKeyboard на Андроид).
          В любом случае такое действие выглядит точно также, как если просто написать автору в личные сообщения «Ошибка в публикации <ссылка><цитата>[комментарий]».


  1. amarao
    21.04.2019 19:13

    +10 благ этому человеку.

    А вот риторический вопрос в воздух: сколько усилий нужно приложить, чтобы просто поговорить с другим человеком приватно, без посторонних ушей?


    1. Tzimie
      21.04.2019 19:18
      +1

      Во время моей молодости просто собирались на кухнях! Я думаю, этот опыт стоит иметь в виду


      1. nerudo
        21.04.2019 20:40
        +2

        Русская рулетка по-советски: рассказывать в компании политические анекдоты. Причем все знают что среди них есть стукач, знают кто именно. Но продолжают рассказывать ;)


    1. Xandrmoro
      21.04.2019 19:29

      Две одноразовые симки на чужие данные, желательно в роуминге.


      1. unwrecker
        21.04.2019 19:42

        Учитывая потенциальную возможность определения человека по голосу, этот способ уже не анонимен


      1. amarao
        21.04.2019 20:32
        +1

        Это даёт слабую надежду на анонимность, и только. Приватности оно не даёт, да и с учётом современных технологий поиска корреляций по IMEI, с большой вероятностью, будет известно где чужая симка кем используется.


      1. Baigildin
        22.04.2019 19:34

        Тогда уж и телефоны купленные не на свои данные.


    1. unwrecker
      21.04.2019 19:41

      Анонимно купленная VDS с VPN и астериском, 2 незасвеченных телефона, 2 анонимных симки.


      Торфон существенно упростит задачу. Спасибо автору!


  1. Gorthauer87
    21.04.2019 20:11

    Странный выбор для UI, можно было бы одним Qt обойтись для linux, windows, macos по примеру телеги.


    1. gegel Автор
      22.04.2019 20:43

      Да, согласен. Это, наверное, оптимальный вариант, хотя и громоздкий. Возможно, в итоге так и будет, но пока что все на этапе альфа-тестирования самой библиотеки, поэтому UI временно лепил на скорую руку.


  1. funca
    21.04.2019 21:12

    Вроде для tor находили атаки, позволяющие деанонимизировать источник при наличии определенного доступа к инфраструктуре. После этого интерес к технологии заметно ослаб. В статье описаны элементы кастомной криптографии с характерным профилем данных. Есть-ли понимание, для каких типов атак решение будет уязвимо или создает новые уязвимости для tor?


    1. domix32
      22.04.2019 16:07

      Слышал только про атаку а ля «51%», когда большое количество нод компрометируется и на основе их данных пытаются строиться пути доставки трафика и выяснить кто есть кто. Но это нетривиальная и дорогая атака, насколько мне известно. У торфона немало мер, чтобы избежать/затруднить идентификацию. Начиная от рандомизации пакетов до нескольких этапов шифрования id для связи.


  1. willyd
    21.04.2019 21:19
    +1

    Вот это проект! Аплодирую стоя.


  1. ianzag
    21.04.2019 21:29
    +2

    > Если так, то по запросу на почту рад предоставить тестовые сборки (статически линкованные исполняемые файлы, не требуемые установки)

    Как идея звучит конечно забавно, но если это open source то мне не понятно что мешает сразу разместить проект скажем на github? Зачем эта почта и вот это вот все :-? Если же нет… Кхм. Ну пилите, Шура, пилите :)


    1. steanlab
      21.04.2019 22:09

      1. willyd
        22.04.2019 00:39
        +3

        А вы коментария владельца репозитория читали под статье?


        1. steanlab
          22.04.2019 01:11

          Вот оно как… Действительно, не все так однозначно. Спасибо, что ткнули носом читателя rss


        1. karavan_750
          22.04.2019 01:38
          +1

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


          1. karavan_750
            22.04.2019 02:43

            UPD. Дело не в хэше, а в содержимом файла. Но сильно ли это меняет суть?


      1. s256
        22.04.2019 01:03

        Там «не все так однозначно»)


    1. gegel Автор
      22.04.2019 20:46

      Пока что отлаживаю ядро ( github.com/gegel/torfone ), UI будет переделываться, но доступно по запросу.


      1. ianzag
        22.04.2019 21:38

        Забавный код. В лучших традициях «embedded C». Почему-то вспоминается WiringPI.


        1. gegel Автор
          23.04.2019 10:19

          Собственно, проект изначально делался как embedded. И, действительно, там есть кусок из WiringPI (последовательный порт в Linux). Такой код легко портировать под ОС, хотя он, конечно, будет выглядеть несколько странно. Но код в традициях ОС очень трудно портировать для работы в bare metal. Поэтому в итоге получилось универсальное решение, не привязанное к ОС.


          1. ianzag
            23.04.2019 19:57

            Я бы порекомендовал причесать код. Сделать его более дружелюбным к интеграции со сторонними системами. Избавиться от глобальных переменных в пользу контекста. Добавить проверку статуса исполнения системных и библиотечных вызовов где это не проверяется. Поработать над четким разделением на модули, в том числе на уровне аргументов публичных интерфейсов модуля. В текущей реализации масса вызовов вида foo(char *data) что накладывает необоснованные требования на вызывающий код по выделению этого самого data. Шаг влево шаг вправо и креш. И поменьше смотреть в wiringpi — IMHO это один из анти-примеров как не нужно писать библиотечный код :) Удачи!


            1. gegel Автор
              24.04.2019 09:28

              Полностью с Вами согласен, код писался в течение месяца, поэтому однозначно сыроват. Четкое разделение на модули — основная цель реализации, процентов на 99 выдержана (кроме пары вызовов инициализации пути из main). Что касается вызовов foo(char *data), то сделано это с целью получить интерфейс, адаптированный к использованию UART микроконтроллера в режиме DMA. Конечно, по всем канонам это небезопасно, но в данном случае используются глобальные массивы фиксированного размера и фиксированные поля данных строго в пределах этих массивов. Понятно, смотрится это не очень красиво, тем более для библиотеки. Буду рад, если предложите более изящное решение, но в первую очередь удовлетворяющее требованием к интерфейсу, модульности и переносимости.


  1. s256
    22.04.2019 01:02
    -1

    Блин, это очень круто! К сожалению не могу поставить "+".
    И да, опубликуйте весь проект на github, а ссылку добавьте в статью.


  1. Taraflex
    22.04.2019 03:24

    Если так, то по запросу на почту рад предоставить тестовые сборки

    Если нет доверия к публичным github-like сервисам, то почему бы не поднять свое gogs.io?


  1. ProRunner
    22.04.2019 11:05

    С учетом end-to-end шифрования звонков в WhatsApp, Viber, Signal в чем преимущество сервисов на основе tor, кроме сокрытия самого факта звонка?

    Децентрализованные сервисы это отлично, но лично для меня побеждает удобство использования.


    1. Sjam
      22.04.2019 14:49

      Пожалуйста почитайте новости из Шри-Ланки, где были заблокированы подавляющее большинство ресурсов.


      1. ProRunner
        22.04.2019 14:52

        VPN всё решает, нет? Я себе настроил бесплатный Outline на AWS (через год перерегистрироваться и заново запустить)


  1. Ovoshlook
    22.04.2019 11:19

    DTLS-SRTP отменили уже?


  1. akhkmed
    22.04.2019 12:39

    Спасибо за очень важное приложение!

    Подскажите, пожалуйста, какие реальные значения latency могут быть в случае с EDGE, а какие — для широкополосного доступа?

    Возможно ошибаюсь, но с точки зрения latency Wave API проигрывает Direct Sound, хотя на общем фоне, вероятно, незначительно.


    1. gegel Автор
      22.04.2019 20:56

      Для GPRS (2G) задержка составляет около 0.8 сек, для WCDMA (3G) менее 100 мсек. Tor вносит от 0.5 до 1.5 сек. Но важен также jitter: для его компенсации необходим буфер, вносящий дополнительную задержку. В Торфоне этот буфер в широких пределах адаптируется к каналу, и алгоритм различен для звонка через Tor, TCP-звонка на IP-адрес и UDP-соединения после прохода NAT. Что касается различия между Wave API и Direct Sound, то оно ничтожно в сравнении с задержками в GPRS и, тем более, в Tor. Wave API было выбрано из-за лучшей совместимости (текущая Windows-версия работает от Win98 до Win 10).


  1. Mykola_Von_Raybokobylko
    22.04.2019 17:30

    Черт с ней с задержкой и кросплатформенностью. Мне больше интересует будут ли мешать операторы прохождению тор-траффика. Например сейчас операторы грешат тем что обрубают сессии к контенту если не могут предоставить надлежащее соединение.


    1. gegel Автор
      22.04.2019 21:01

      Несколько дней назад тестировал в Free WiFi на Киевском вокзале в Москве. WhatsApp и Viber не работают голосом, прямое TCP соединение блокируется на порт по умолчанию 4444, но успешно на 8080, соединение через Tor работает везде. Tor заблокировать не так просто, судя по опыту Китая и Ирана.


      1. Mykola_Von_Raybokobylko
        23.04.2019 09:45

        Дело даже не в блокировке как в таковой сколько в шейперах и прочей нечисти.


  1. Chapay81
    22.04.2019 19:34

    Вот поэтому личный разговор не сможет заменить никакой костыль.


  1. Rober
    22.04.2019 19:34
    +1

    Теперь все эти перипетии с Телеграмом кажутся чем-то ничтожным. Потому что вот он — проект, бескомпромиссно использующий современные технологии для приватной связи. Вот так в одночасье претензии на доступ к переписке стали бессмысленны, потому что появился способ действительно анонимной связи.


    1. vvzvlad
      23.04.2019 14:50

      … который из-за "удобства" пользования и сырости проекта никому не нужен. Все продолжают пользоваться телеграмом.


      1. Rober
        23.04.2019 16:04
        +1

        Это всё-таки разные продукты (если можно назвать Торфон продуктом на текущей стадии) и сравнивать их бессмысленно. Конечно, Телеграм как мессенджер с самым удобным интерфейсом в мире (IMHO) ультимативно привлекателен. Но у него закрыта серверная часть и фактически есть точки отказа. А здесь появился проект с вроде как открытым исходным кодом и другим способом связи. Да, ему без году неделя и пока не было никакого аудита кода. Но как концепт это просто «вау» — выжать из Tor-сетей такую низкую задержку при голосовой связи и одновременно обеспечить работу вне Tor сетей, пускай с потерей анонимности — это сильная идея.


  1. SeM13
    22.04.2019 19:34

    В чем проблема просто пользоваться телеграмом? Ведь там тоже имеется шифрование трафика по звонка. Или я чего то не знаю?:)


  1. Crazyvlad
    22.04.2019 19:34

    Спасибо за статью.
    Поясните, а что с MOS в реальной жизни? Проводились измерения?

    P.S.
    выражение " а также постепенное отвыкание пользователей от PSTN в пользу GSM связи с присущей ей значительной латентностью. " не верно.
    Качество голосовой связи оценивают несколько по другому, вот тут хорошая статья:
    habr.com/ru/post/177099


    1. gegel Автор
      22.04.2019 21:07

      Качество голосовой связи — понятие весьма многогранное. В данном проекте основным вызовом была задержка, вносимая Tor. И дискомфорт пользования Торфоном определялся именно эти фактором. Но человек может адаптироваться к задержке существенно выше рекомендованных 400 мсек. Именно это имелось в виду в плане постепенного «привыкания» пользователя к высоколатентным каналам голосовой связи.


      1. ianzag
        25.04.2019 07:49

        При необходимости человек прекрасно адаптируется к симплексной рации и нисколько по этому поводу не переживает — лишь бы работало надежно.


        1. gegel Автор
          25.04.2019 09:23

          Симплексная рация имеет кнопку «Передача», и это «дисциплинирует» участников. В дуплексных высоколатентных системах участник, задавая вопрос, ожидает ответ, и, не дождавшись, начинает опять говорить в то время, когда ответ как раз доходит. Просто к этому нужно привыкнуть (другой пример — прямое спутниковое включение журналистов ТВ и их диалог со студией).


  1. gegel Автор
    22.04.2019 21:11

    Спасибо всем за указание на мои глупые ошибки по тексту — поправил. Еще раз извините за мою невнимательность.


  1. truezemez
    24.04.2019 17:51

    Можете, как автор, сравнить ваш продукт с https://jami.net/?
    Обычно, все p2p звонилки и чаты имеют одну проблему — невозможность позвонить или отправить сообщение, если абонент оффлайн. Как у вас с этим?


    1. gegel Автор
      25.04.2019 09:48

      Хм, я впервые слышу об этом проекте. При беглом знакомстве напоминает Tox (p2p через DHT) плюс SIP-клиент. Последний функционал потребует SIP-сервер (например, поднять свой Asterisk на белом IP).
      DHT — это здорово, но я вижу тут другую проблему: количество участников должно быть достаточно большим, чтобы обеспечить безопасность системы. Но на старте проекта при недостаточной популярности, естественно, участников мало, и это весьма ограничивает развитие. Т.е. получается замкнутый круг.
      И, кстати, я не увидел внятного описания криптографии. Ее нет вообще, или я не нашел в их Вики? Подскажите ссылку, если она есть.
      Что касается оффлайн-состояния, то это проблема мессенжеров, но никак не звонилок: разговаривать с отключенным абонентом невозможно априори. Многие месенжеры решают проблему по разному, но это отдельная тема, и тут другие модели угроз. Я просто отказался от чата в Торфоне — нет чата, нет и проблем.


  1. truezemez
    25.04.2019 12:40

    Хм, я впервые слышу об этом проекте.

    Ранее назывался SFLphone, а потом GNU Ring.


    DHT — это здорово, но я вижу тут другую проблему: количество участников должно быть достаточно большим, чтобы обеспечить безопасность системы. Но на старте проекта при недостаточной популярности, естественно, участников мало, и это весьма ограничивает развитие. Т.е. получается замкнутый круг.

    Я предполагаю, что DHT используется только для поиска участников. Можете раскрыть мысль про проблемы с безопасностью и замкнутый круг?


    И, кстати, я не увидел внятного описания криптографии. Ее нет вообще, или я не нашел в их Вики? Подскажите ссылку, если она есть.

    Не подскажу — я ее сам не видел.


    Как я понимаю работу jami:


    • При создании аккаунта генерируется пара ключей (допустим rsa).
    • Для поиска участников используется что-то типа трекеров для торрентов.
    • При добавлении контакта происходит обмен ключами.
    • Далее используется end2end шифрование.

    Торфон делает похожие вещи, только вместо dht используются onion сервисы и трафик "блуждает" через промежуточные узлы.


    Но это только мои фантазии на тему.