id: Гость   вход   регистрация
текущее время 23:31 28/03/2024
создать
просмотр
ссылки

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).


 
На страницу: 1, ... , 11, 12, 13, 14, 15, ... , 50 След.
Комментарии
— Гость (31/03/2013 04:04)   <#>
Да – еще просьба:

3. У вас номер версии TorFone меняется, и это логично отражается в имени скачиваемом файле – torfone_V03a.zip
А вот имя файла мануала остается тем же – все тот же testingru1.pdf
Его бы то же стоило синхронно менять, чтобы пользователи не путались.
К тому же в нем по любому должно найти отражение изменения версии, в данном случае – появление AES256.
— Гость (31/03/2013 10:50)   <#>
AES256 – просто превосходно, супер!!!
Когда что-то начинает вызывать массовое безоговорочное эмоциональное восхищение, уже только это само по себе – повод задуматься...
— gegel (31/03/2013 11:59, исправлен 31/03/2013 12:09)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0
обеждена ли в версии 0.3 досадная ошибка, которая жутко мешает работать?

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


TorFone использует сторонние библиотеки? Если да, то как вы думаете, насколько мала вероятность нахождения в них "закладок"?

Сторонние библиотеки все в исходниках. Источники:


Оптимизированный AES взял тут: http://sourceforge.net/projects/libobfuscate/
А они использовали источник: http://www.efgh.com/software/rijndael.htm
Вектора сходятся. В исходника ничего, кроме AES, нет.


SHA1 отсюда: https://polarssl.org/sha-1-source-code
Надежный источник.


CODEC2 взят тут: http://codec2.org/ Приаттачен в виде статической либы, собираемой с исходников. Исходники просматривал, ничего, кроме математики, там нет.


MELP отсюда: h**p://health.tau.ac.il/Communication Disorders/noam/speech/melp/Download/Download.htm
Он упорно не хотел становиться, поэтому я его коды до последней строчки перелопатил, переделав с либы в include
Кроме математики, там ничего нет.


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


Остальные исходники родные. Надеюсь, Цммерманновскому DH-прайму можно доверять: сначала я хотел заменить его на прайм с rfc3526, но передумал – не будет совместимости.


Когда что-то начинает вызывать массовое безоговорочное эмоциональное восхищение, уже только это само по себе – повод задуматься...

Абсолютно согласен. Поэтому и оставил классический tDES 168bit – в те времена о бекдурах точно не думали.

— sentaus (31/03/2013 12:30)   профиль/связь   <#>
комментариев: 1060   документов: 16   редакций: 32
gegel, несколько вопросов и идей на будущее:

1) Симметричный шифр в каком режиме используется?
2) HMAC_SHA1 – можно ли в будущем на SHA2 хотя бы перейти? Маловероятно, что она станет небезопасной на практике, но всё-таки :)
3) Что думаете про кодек Opus? http://opus-codec.org/ У него минимальный допустимый битрейт не столь мал, как у CODEC2 или MELP, но очень маленькие задержки, размер кадра от 2,5 мс. Возможно его можно использовать как HQ-кодек.
— gegel (31/03/2013 15:17, исправлен 31/03/2013 15:18)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0

1. В режиме CTR. Счетчик имеет статическую часть (nonce) и изменяющуюся: 32-битный счетчик пакетов и 16-битный счетчик блоков в пакете (т.е. период оборота 9 лет при отправке пакета каждые 70 мс). Т.к. симметричный ключ (общий секрет DH) новый на каждый разговор, то этого более чем достаточно. Счетчик пакетов синхронизируется на обеих сторонах с помощью 16-битного ID пакета, передающегося в начале пакета в нешифрованном виде и восстанавливающегося до 32-битного значения.
2. Сперва я вообще думал Keccak использовать, но потом посмотрел реально: стойкость хеш-функции определяет время, необходимое только для подбора аутентификационной фразы. А время, необходимое для дешифровки разговора, определяется DH и симметричным шифром.
Поэтому, если фразу менять хотя бы раз в год, то стойкости 160 бит SHA1 по идее, достаточно.


PS: если интересна реализация остальной криптографии (DH, аутентификации) – спрашивайте, опишу, чтобы в исходниках не рыться. И дам ссылки на конкретные места в файлах. Мне кажется, что именно реализация определяет криптостойкость, а не математика используемых алгоритмов, поэтому уделил внимание тщательной ревизии кода, и в который раз преклоняюсь перед Циммерманном! SpeakFreely с ее DES-56 в CBC с постоянно нулевым IV для каждого пакета отдыхает :)


3. Есть и такая идея. И еще http://www.speex.org/ Хотя их преимущества в вариабельном битрейте, что не совсем подходит в плане криптостойкости.

— sentaus (01/04/2013 22:03)   профиль/связь   <#>
комментариев: 1060   документов: 16   редакций: 32
если интересна реализация остальной криптографии (DH, аутентификации) – спрашивайте, опишу, чтобы в исходниках не рыться.

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

И еще http://www.speex.org/

Эту разработку прекратили после выхода opus.

Хотя их преимущества в вариабельном битрейте

Это да. CBR, впрочем, тоже весьма неплох по качеству.
— Гость (02/04/2013 04:30)   <#>

Т.е. AES не стоило интегрировать, так надо это понимать?
— Гость (02/04/2013 18:33)   <#>
Это надо понимать так, что кроме AES должны быть и другие алгоритмы шифрования, желательно с возможностью объединения в каскад.
— Гость (03/04/2013 00:41)   <#>
Так они и остались – гляньте в программу, исключен только Blowfish
— gegel (08/04/2013 10:59)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0
как происходит подтверждение подлинности пакетов с данными? Я думаю, их лучше бы отбрасывать сразу без попыток декодирования голосовым кодеком. как себя сейчас в подобных случаях приложение поведёт?


Пакеты управления, текстовых сообщений и файлов содержат crc32 в зашифрованной части. После декрипта сверяется. Голосовые пакеты содержат 32-битный timestamp в зашифрованной части. В эту часть алгоритма я досконально не вник, но если таймстемп не вкладывается в определенные пределы, то пакет отвергается. Кроме того, при определенном к-ве потерь происходит рассоединение.

Так, при несинхронной смене nonce в процессе аутентификации+анти-MitM связь разрывалась, поэтому пришлось вводить дополнительный флаг смены nonce, и отвергать несоответствующие пакеты еще до декрипта.

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

Посмотрел opus: VC6 скомпилировала нормально. Качество лучше GSM при битрейте начиная с 10000 bps. Действительно, есть смысл прикрутить как HQ-кодек для прямого соединения. Учту в следующей версии, там же реализую переключение с TCP на UDP p2p.

Если анонимность не важна, то будет VOIP без сервера и регистрации: абоненты находят друг друга с помощью Tor HS, выполняют DH внутри Tor (что практически исключает MitM), затем переключаются на UDP, запрашивают свой адрес/порт на любом заданном STUN и опять же с помощью Tor выплняют NAT traversal, далее голос передается по UDP (причем нестандартным протоколом – не ZRTP, что в некоторой степени маскирует от DPI).
— unknown (08/04/2013 11:35, исправлен 08/04/2013 11:35)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

При всём уважении к программерскому энтузиазму.
Но это показывает наколеночность дизайна. Как будто HMAC не изобрели и методы аутентификации в каналах, хотя бы например как в SSL. И даже те, навороченные методы, периодически атакуют из-за того, что программеры не понимают, как надо реализовывать аутентификацию. Всякие теоретические оракулы вылезают в практические атаки. А программеры-шифрпанки по прежнему просто думают: "а давайте-ка воткнём CRC-32 в шифртекст и получим аутентификацию".

— gegel (08/04/2013 12:12, исправлен 08/04/2013 12:19)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0

Притензии не ко мне – лично к Циммерманну :)
Мне кажется, глупостей он не делал даже в то время.
Так, например, ключевой момент DH защищен SHA.


Собственно, аутентификацию для исключения MitM уже я реализовал lege artis на базе HMAC, могу детально описать релизацию.


Но все же, не используя шаблонные утверждения и догмы, покажите мне конкретно, где уязвимость, и как ее можно использовать в данном случае, если crc32 пакета передается вместе с пакетом в шифрованном виде? (шифрование в режиме CTR).
Возмем, к примеру, пакет с текстовым сообщение. Я так понимаю, хотим сделать подмену. Да, можно побитно манипулировать с текстом и с crc ( т.к. CTR), а дальше как???


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

— Гость (08/04/2013 12:27)   <#>
Намечается дискуссия на тему "практика vs теория" :)
— Гость (08/04/2013 12:48)   <#>

gegel, слишком толсто. Как раз обосванием занимаются теоретики в вузах, а шифрпанки определяют стойкость на глазок подобно тому, как студентота определяет работоспособность программы по признаку «ошибок не пишет — значит, работает правильно».

Свежий взгляд со стороны всегда полезен, даже если он шифрпанковский или ещё какой, но это не отменяет необходимости системных знаний, которым как раз и учатся специально (или в вузах или сами по книжкам/статьям).
— unknown (08/04/2013 13:30, исправлен 08/04/2013 13:38)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Вот чего люди стандарты пишут, головы ломают. Взяли бы AES-CTR + CRC-32 и не мучались.


Для построения стойкого аутентификационного канала обе функции должны быть криптостойкими, как шифрующая, так и аутентифицирующая. Причём это необходимое, но ещё даже недостаточное требование. Полностью достаточный набор требований я даже не решусь назвать. Для этого ещё только разрабатываются спецрежимы шифрования (часть уже стандартизирована и внедрена, но их безопасность недостаточно доказана), прорабатываются решения на основе Keccak. Пока проверенная классика: связка KDF для получения двух разных ключей из одного + HMAC для аутентификации + шифрование.


Разработчики IPSEC, к примеру, на аутентификации прокалывались. OpenSSL — это вообще нескончаемый поток багов в этом вопросе. Циммерман начинал тоже с шифрпанковского бажного подхода (и во многом на нём оставался).


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


Возмем, к примеру, пакет с текстовым сообщение. Я так понимаю, хотим сделать подмену. Да, можно побитно манипулировать с текстом и с crc ( т.к. CTR), а дальше как???

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


Это вы доказывайте, что вы взяли и внесли изменение в стандартный протокол безопасным образом и ваш метод построения канала безопасен в рамках каких-то моделей.


При всём уважении ко всем, кто, что-то реальное делает (К Циммерману, к команде OpenSSL, к вам и вашему проекту и др.), просто первый способ из этих двух откровенно достал уже:


The classical cryptography approach:

Problem -> Proposed solution -> Bug! -> Revised Solution ... -> Implement -> Bug! -> ... -> ad infinitum


The provable security paradigm:


Problem -> Definition -> Protocol -> Reduction -> Implement -> DONE

На страницу: 1, ... , 11, 12, 13, 14, 15, ... , 50 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3