Voice over TOR
Предлагаю для тестирования кипто VOIP-утилиту для работы через TOR (в режимах TOR -> доменное имя и TOR->скрытый сервис). Переделал с старого PGPFone: заменил транспорт на TCP и добавил адаптивный буфер для компенсации высокого jitter в TOR-туннеле. Также добавил обмен сообщениями и файлами.
Win98-XP-7-8. Полностью портируема. Работает peer-to-peer (звонить на доменное имя или TOR-hidden service). Использует DH4096+3DES.
Приветствуются замечания и пожелания.
Сайт проекта http://torfone.org (англ./рус.), там же доступны исходники (Visual C 6).
А еще linuxconf, но уже смутно
комментариев: 393 документов: 4 редакций: 0
Обсуждение, конечно, интересное. Но суть дела не совсем в этом. Начну издалека и постараюсь объяснить ход моих мыслей на этапе разработки ОР, и потом можно продолжить.
Я пытался сделать ОР максимально независимым от любой ОС, более того, с возможностью работы вообще без ОС. Единственный поток представляет собой цикл, в котором асинхронно (без ожидания события, с моментальным возвратом) опрашиваются:
– ввод звука. Если там есть данные, они добавляются к буферу, если набралось достаточно, передаются в кодек и далее пакуются и отправляются в сокеты при наличии соединения;
– чтение сокетов. Если есть входящие пакеты, они обрабатываются в соответствии с типом и текущим состоянием ОР. Если это голосовой пакет, декодируются и отправляются в буфер для проигрывания.
– чтение нажатой клавиши. Код клавиши преобразуется в символ, дописывается в мой буфер. Если символ управляющий (например, Ввод), буфер анализируется, и выполняется, например, команда или отправляется в чат. Причем я не могу асинхронно ввести всю строку, а только посимвольно (точнее – поклавишно), поломав (переключив в raw) стандартную консоль.
Последнее как раз и реализует ту псевдоконсоль, которая обсуждается выше. Но это не полноценная консоль, иначе бы пришлось кодить пол-ядра самому. Это минималистический эмулятор консоли, его можно (и нужно) вообще отключить при использовании ОР чисто в виде демона для стороннего IM. И есть смысл рассматривать команды, реализованные в нем, не как пользовательские, а в качестве низкоуровневого интерфейса взаимодействия между демоном ОР и каким-то отдельным пользовательским интерфейсом, запущенным в отдельном потоке (и в отдельном окне). На сейчас имеем Telnet и WebSocket. Не вижу проблем написать код, с одной стороны подключающийся к демону ОР через Telnet, а с другой – реализующее в полноценной Linux-консоли любое из вышеозвученных желаний, или даже все вместе, настраиваемые через конфиг. По трудозатратам это будет где-то так же, как был браузерный GUI на WebSocket, но проблема в том, что я понятия не имею, как сделать, чтобы всех устроило. Кстати, в моих Windows-проектах тоже всегда кто-то критиковал именно GUI: кому-то хотелось кнопки, а кому-то галки, кто-то возмущался по поводу выпадающих меню и требовал мини-бар.
Так что можно продолжать
циркобсуждение, и я тут не советчик. Как определитесь, подумаем, как это можно закодить, и сделаем в кратчайшие сроки.Если планируется консольный UI только под Linux, то проблем вообще не возникнет.
Команды можно придумать любые, интерфейс преобразует их в набор низкоуровневых команд ОР и передаст через Telnet. Точно так же можно отпарсить сообщения от ОР и преобразовать во что угодно для вывода пользователю. Будет желание придумать юзабельный командный интерфейс для практического пользователя – всегда Welcom.
А достаточно подробное описание практически всех низкоуровневых команд представлено в доке на ОР (англ.)
Подробности здесь.
при желании/необходимости, можно использовать туннелирование через TOR, i2p, vpn...
комментариев: 393 документов: 4 редакций: 0
Спасибо за чистку.
Как раз в этом нет уверенности. У Вас есть возможность провести простой эксперимент и опубликовать результаты? (я сам не проводил, но очень интересно): попробовать установить соединение между браузерами в локальной сети, изолированной от глобальной интернет? Кстати, каким образом происходит адресация, т.е. что является уникальным адресом клиента? IP? Или нужна регистрация на сервере WebRTC, Mozilla и т.п.?
комментариев: 393 документов: 4 редакций: 0
http://www.torfone.org/download/oph_lin051114.zip
http://www.torfone.org/download/oph_win051114.zip
Просьба сообщать о багах в новых сборках.
Сейчас проводим общую чистку кода и прогон на различных анализаторах.
Потом займемся озвученными выше пожеланиями к интерфейсу. И, наверное, будем пробовать портировать и в Android NDK.
комментариев: 301 документов: 8 редакций: 4
А что нового, очень интересно, в обновленных сборках? Очень хорошо бы для для этого вести ченжлоги.
комментариев: 393 документов: 4 редакций: 0
Спасибо за ссылку, но для ОР VOIP-библиотека уже точно не понадобится. Использование стандартных библиотек для VOIP – как раз та проблема, которая не давала реализовать эффективное решение для Tor: стандартные решения заточены для обычных условий, а не для высоколатентного окружения, в подавляющем большинстве используют UDP-RTP, и поэтому все сводится к UDP-VPN-TCP-Tor. Отказавшись от стандартов и от готовых библиотек, получилось вручную на нижнем уровне оптимизировать VOIP именно для Tor.
Хотя один вопрос остался открыт – видео. С каждым годом Tor становится все быстрее (не знаю, хорошо это или плохо), и уже сейчас, думаю, можно передавать 160*120 H264 видео с 5fps. Присматриваюсь к кросплатформенным библиотекам, использованным ZAS в его коммуникаторе. Можно будет попробовать сделать дополнительный интерфейс для видеопотока в демоне ОР, и, используя его, подключать отдельное приложение для отправки/приема видео через уже установленное ОР соединение. Это еще одно преимущество клиент-серверной архитектуры ОР: модульность.
Собственно, ничего для пользователя: pfactum помогает привести исходники в порядок после моих креативов, фиксит мелкие баги, см. коммиты на гите.
Если будут значимые для пользователя изменения, конечно же отдельно предупрежу здесь и заведу ченжлог.
С видео возникают дополнительные нюансы: синхронизация со звуком, и разбиение больших видеопакетов на размер, приемлемый для UDP. Довольно трудно сделать, чтобы работало мягко и ненавязчиво.
http://www.zas-comm.ru
Это означает, что возможно появление OnionPhone, работающего в Андроиде? Или он будет работать непосредственно в железе, совместимом с Андроид, но без него самого?
Может, не надо? По крайней мере пока. Поскольку противоречит самому понятию анонимности и безопасности, которое тем лучше, чем меньше идентифицирующих сведений об абоненте передается.
Для голоса вам уже и так приходится решать проблему анонимизации с помощью вокодера, а для видео тем более.
Ваш OnionPhone – по задумке серьезная программа, которой можно будет довериться, не чета всяким там Скайпам, и теме более не вот этой фигне, которую глупые разработчики сходу пристегивают к "ВКонтакте» и "Facebook" – о какой безопасности тут можно вообще говорить? Впрочем, если для шпионажа для гражданами – самое то, не все ж одному Скайпу шпионить.
В-общем, мое глубокое имхо: видео в OnionPhone – очень вредная вещь.
Конечно, найдутся и противники такой точки зрения, и даже может, их количество будет перевешивающим. В таком случае, ведите, пожалуйста, две версии: одну без видео (для тех, у кого безопасность является приоритетным фактором) и без него (кому OP нужен так, для "поиграться").
Надо, 0лайтов, надо. :)
Тогда и голос не нужен.
Я бы вокодеру свою жизнь не доверил. Мне интересней другой подход: научиться быстро печатать, а потом скармливать набираемый текст программе, которая его озвучивает собеседнику. При проблемах со связью такой режим уже тестировался: я собеседника слышу, а он видит только то, что я печатаю.
Gegel специально для таких "глубоких имх" как ваше указал: архитектура модульная. Хочешь — ставь модуль, не хочешь — не ставь. На самом деле, всё ещё проще: боишься видео — не используй, по умолчанию оно включаться на будет. Что ещё надо? Какая разница, есть ли такой функционал в программе?
ИзолентуПрищепкуКанцелярский зажим для камеры никто не отменял.Из двух зол обычно выбирают одно, и меньшее. С голосом хочешь не хочешь, но придется использовать, т.к. именно голос передает значащую информацию между собеседниками.
А морда лица – что? Одни эмоции. Без которых можно вполне обойтись.
Конечно, его можно использовать еще как уникальный идентификатор, ключ, чтобы убедиться, что собеседник не подстава. Но тогда уж лучше отпечаток пальцев или сетчатка глаза.
Я тоже. Но разве речь идет о защите сеанса разговора одним лишь вокодером?
Нет, речь о комплексе мероприятий, используемых в OP – шифрование с помощью самого OP, далее за счет ресурсов сети Tor, опять-таки, анонимизация с помощью Tor, и как еще одна ложка меда – вокодер.
Кстати, в принципе есть такие вокодерные алгоритмы, которые начисто уничтожают индивидуальные характеристики формант и прочих особенностей голоса (чуть ниже).
Ооооо! Не один вы над таким думаете, я уж лет несколько точно :)
Но потом голосовой анализатор Гугля подсказал более продуктивное решение – сначала речь распознается и переводится в обычный текст, который затем с помощью обычного речевого синтезатора переводится снова в речь, но уже – без всяких индивидуальных признаков.
Вопрос только в том, где взять такой алгортим распознавания, который можно использовать в OP.
Найдете – поставим вам памятник в PGPRU. При жизни :))
Не. Тогда уж лучше модульный. Поскольку вы забываете, что создание универсального "комбайна" – это неизбежный рост ошибок кода и путь в никуда. А модульный подход к созданию софта всегда упрощает реализацию и упрощает работу программиста.
Поечему путь в никуда – краткий пример: вспомните, как развивалась ICQ. Когда она была маленькой и крохотной, ею с удовольствием пользовались все. Но когда глюпый Mirabilis превратил ее в раздутого непоротливого монстра с кучей надуманных фич, тут же стали появляться компактные клоны, и народ стал разбегаться на них. И одним из наиболее востребованным конкурентом стала крохотная юркая Miranda, которая как раз и построена по модульному принципу – вешай на нее что хочешь. Потом Mitabilis спохватилась и выпустила облегченную Lite-версию, но было поздно, поезд ушел.
Конечно же, модульный принцип, API, плагины и все такое, тут с вами полностью солидарен.
Отличный инструмент – это НЕ универсальный инструмент. Не надо губить этим пагубным универсальным принципом OnionPhone – его ждет большое будущее! :)
Если идёшь по улице и тебе позвонили — да. А дома можно и на клаве понабирать. :)
Обычно — да, но у каждого свой сценарий. Если собеседник знает голос, то не скроешься. Если у противника-собеседника есть выбор лишь из нескольких подозреваемых, а ФИО всех подозреваемых известно, то тоже. Это превращается в средство сокрытия местоположения говорящего, но не анонимности, и анонимность тут висит разве что на вокодере.
У этого метода есть принципиальные ограничения в плане безопасности. Где бы речь ни происходила, если она произносится вслух, вероятность её утчеки намного выше. Могут случайные прохожие подслушать, могут соседи, могут быть микрофоны-жучки, может быть активирован микрофон на рядом лежащем мобильнике... Всё же распознавать речь по стуку клавиш, на мой взгляд, сложнее, чем прослушивать непосредственно. «Есть такие вещи, о которых вообще не стоит кому-либо когда-либо говорить вслух» ©. :-)