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).
Гм, это неожиданный поворот. Здесь пока обсуждался Torfonе, по нему за столь огромный топик накопленомного вопросов и ответов, сложилась определенная оценка его возможностией и некоторое доверие.
А тут бац – и SpeakFreely. "© Кто такой, зачем, почему?"
Как к нему относится, он что, защищеннее TorFone, раз вы на него переключились?
В-общем, переход непонятен, поясните, плиз.
Это, как говорится, "внушает и впечатляет". Но в самом деле, как в этом довольно старом проекте с уровнем криптозащиты? AES, TwoFish и пр. в нем вроде не замечены, имхо.
комментариев: 393 документов: 4 редакций: 0
На сайте Торфона с самого начала существует страница, где сделан порт SpeakFreely-Win32 для работы через Tor.
В версии 7.2-Win32, которую я патчил год назад, AES нет, только DES-56 в ECB-режиме без никаких MAC (тоесть никак). В версии 7.6, на которую я давал ссылку, есть AES-128. Но не это сейчас главное: шифрование – не проблема, я прикручу все, что пожелаете. Планируется AES-256-OCB и Keccak-SpongeWrap в качестве красивой игрушки. Ну, и ECDH25519 для периодического наложения на имеющийся предрасшаренный ключ для PFS.
Гораздо важнее другое: TCP-транспорт, кодеки и т.д. Портировать Торфон под Linux as-is – весьма геморройное занятие. Нативный PGPFone написан на С++ под VisualC с использованием специфической для Win32 MFC и развитым GUI. Существенное снижение трудозатрат – взять готовый проект под Linux (пользовательский интерфейс, работа со звуком, буферизация, интернет-сокеты) и добавить к нему код из Торфона (благо, все, добавленное мною – на С). Это и шифрование, и кодеки, и проход NAT. Можно даже один в один повторить протокол Торфона, и сделать поную обратную совместимость, хотя эта идея не особо меня впечатляет, т.к. лучше сразу создать версии под разные платформы (или даже попробовать cygwin + прицепить GUI под Win32).
Можно назвать это Linux-Тофрон (или onionphone, чтобы не драконить Роджера).
Но в любом случае C-код SpeakFreely анализировать куда проще, чем С++ код Торфона, т.о. желающим будет проще найти потенциальные баги.
Еще раз повторюсь: из SpeakFreely я хочу взять командный интерфейс и логику консоли, работу со звуком и частично с сетью. Остальное – из Торфона.
Иначе, если пытаться делать новое Linux-приложение с нуля или один в один портировать Торфон вместе с GUI, этот проект так и умрет, не родившись.
К тому же Torfone сегодня уже хоть как-то, но работает! С прикручеными необходимыми аесами и т.п.
Зачем тогда было вообще браться за него, если SpeakFreely, как теперь оказывается, предпочтительнее?
Хотя, конечно, если получится обновленный SpeakFreely сделать быстро, то да. Идею с более простым консольным приложением на предыдущих страницах я подавал. Вопрос – насколько быстро?
комментариев: 9796 документов: 488 редакций: 5664
комментариев: 393 документов: 4 редакций: 0
Это и будет Торфон. Лучше бы я не упоминл о SpeakFreely, молча взяв оттуда парсер командной строки и кроссплатформенную звуковую библиотеку. Все остальное все равно от Торфона прилепится. А GUI под Linux никому тут не интересно.
Согласен на все 100%, со всеми новыми проектами так и делаю. Но Торфон вообще изначально не планировался как проект: я хотел просто показать возможность передачи голоса через Tor. Взял первое попавшееся под руку приложение, наскоро перевел на TCP и увеличил голосовой буфер. К сожалению, попался PGPFone, жестко заточенный под Win32.
Да кто ж с этим спорит. Но для того, чтобы что-то реальное сделать, нужно либо достойную оплату получать, либо жить в сытой стране, где нет никаких забот и можно спокойно заняться хобби, Voice over TOR, например :)
Gegel, давайте попробуем пообщаться в приватке https://fastzone.net, я там зарегился под ником Liteminer
unknown, вы все-таки не хотите помочь общему делу, ответив на заданные вам выше вопросы?
Вот именно! Одни ненужные проблемы.
Можете закидать меня камнями, но, чисто на мой неискушённый взгляд, есть штук 5 проектов, которые сейчас более важны для безопасности, чем шифрованная голосовая болтовня. Академикам лучше вкладываться в них.
Ещё в начале этого треда высказывались аргументы, что голосовая связь несовместима с анонимностью органически, и даже после всех страховок безопасности она всё равно будет хуже шифрованного IM. Как минимум, одна из неустранимых проблем — то, что голос могут прослушать локально, и это намного проще, чем ловить акустические или электромагнитные сигналы с ПК/клавиатуры/монитора.
А что с ней сейчас не так? На ограниченных группах работает прекрасно.
Есть рекомендация общего характера: если используется виртуальная машина, то прикладной софт нужно запускать в гостевой ОС, а рулить трафиком (и запускать сетевые средства анонимизации) в хостовой ОС, чтобы критичные для безопасности и анонимности вещи выполнялись не в той же гостевой ОС, где и потенциально уязвимые программы. Это самый простой вариант. Есть сложнее: сделать несколько гостевых ОС, в одной — только программы для конечного использования, в другой — только сетевая инфраструктера (Tor, VPN, файерволл).
Риск получить ошибку в проекте из-за невнимательности или недостаточной компетентности разработчика (без всякого АНБ), которая потом ещё и не будет исправлена из-за того, что никто не читает её код, намного выше риска получить злонамеренный бэкдор. Это если речь идёт о программах с открытым исходным кодом.
Да, в основном распространено именно такое мнение, хотя ЦРТ храбрится и пиарится изо всех сил. В любом случае, голосовой трафик пишется и складируется. Может быть, лет через 30, когда технологии позволят распознавать голос не хуже человека, весь архив голосовой связи будет «оцифрован» (превращён в текст), каталогизирован, а голоса говорящих распознаны. Сначала к архиву получат доступ избранные, типа полицейских, потом маркетологи, потом историки, а потом все остальные. Можно будет
прийти в Ленинкузайти на сайт и скачать полное собрание текстов разговоров (по телефону и другим средствам недостаточно защищённой связи) любого человека за всю его жизнь. Радуйтесь наступающему цифровому будущему, развиваются ведь не только средства шифрования и анонимности, но и средства слежки и анализа.Не повторяйте ошибок предыдущих поколений, ставьте Debian. Он ничем не сложнее, зато безопаснее.
Да не связывайтесь вы с curses-интерфейсами! Есть традиционный промышленный подход — командная строка + конфиги с пояснениями к опциям. onionphone --port NUMBER --call USER_ADDRESS --config-file /path/to/config — что-нибудь в духе этого. В домашней директории ~/.onionphone можно хранить не только конфиги, но и ключи. Любую опцию конфига по возможности должно быть возможным переопределить в командной строке при запуске программы. По такому принципу работают тысячи программ, включая GnuPG и climm. Интерфейс у последнего вполне удобен для общения с абонентами, его можно было бы и для звонков приспособить.
А кредентиалсы не подписаны. На pgpru есть возможность подписывать комментарии через gpg -sa. Почему бы этим не воспользоваться?
Но даже он не достаточно безопасен (на примере пранковских записей и всяких TV-шоу все могли в этом убедиться).
Эллиптика — минное поле, не стоит туда лезть мелким проектам. Даже в GnuPG-ключах рекомендуют придерживаться RSA, хотя эллиптика там есть. Т.е. даже касаемо проекта такой тотальной распространённости нет уверенности, что в его реализации эллиптики всё ОК, и это нигде потом не аукнется.
Самоподписанный сертификат. После добавления в исключения получаем
Примерно так:
Последние обсуждения того, как правильно писать безопасные правила для iptables, были тут. Низкоуровневость iptables, вытекающая из этого требовательность внимательности к мелочам, большой объём текста даже для самой минимальной политики фильтрации — основные факты, из-за которых считается, что в Linux нормального файерволла нет. Интеграции iptables с окружением тоже нет (поэтому всё делается в виде самописных скриптов). На старте системы правила могут не работать. Стандартных способов загрузки правил тоже нет: каждый их суёт туда, куда вздумается, в стартовых скриптах. Поддержки owner для входящих пакетов в iptables также нет.
iptables — говно, ненавижу^Wне используйте iptables.Там, где можно, не используйте iptables, используйте pf. У последнего нет перечисленых недостатков, правила удобочитаемые человеком, а писать их легко, приятно и безопасно.*Проверка загруженных правил — команда iptables-save.
*По ссылке пример намного более сложных правил, чем в этой рыбе-заготовке. Там несколько внешних интерфейсов + форвардинг, но при всём этом они легче читаются, чем вышеприведённая «ассемблерная» мешанина iptables.
комментариев: 9796 документов: 488 редакций: 5664
Я обсуждал на примере разработки торфона, что нехорошо лепить протоколы на коленке. Мне было интересно выяснить (думаю, что и Gegel'ю тоже), что протоколы с отрицаемой аутентификацией — гораздо более сложная вещь, чем кажется. И ведущими теоретиками проблема до сих пор не решена.
Сам торфон, как реальный программный продукт для пользователя мне пока никак не был интересен.
Сама такая возможность многим тоже интересна, как концепт. Я слежу за её развитием, но никакой конкретный проект пока практического интереса не вызывает. Ни в каком «общем деле» я не участвую. Отвечаю на те вопросы, которые лично считаю интересными со своей субъективной точки зрения и не более того.
Описка. Следует читать не "по голосу" а "по стилю". Речь идёт о распознавании автоматически озвученного текста, полученного из туда-сюда перевода распознанной в текст речи.
Чем вам этот случай не люб?
Мне кажется, живая речь содержит намного больше уникальных паттернов, чем письменная, как минимум, потому, что «поправить» уже произнесённое нельзя. А раз даже авторство письменной речи успешно определяется стилометрией, то что говорить про устную...