id: Гость   вход   регистрация
текущее время 22:02 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, ... , 13, 14, 15, 16, 17, ... , 50 След.
Комментарии
— unknown (12/04/2013 09:44, исправлен 12/04/2013 10:43)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

SHA-256 — это хорошо. Но в строгом смысле — оно не PRF. Изучайте, где в протоколах и почему используется HMAC вместо просто хэшей.


Я не утверждаю, что это обязательно нужно всегда. Просто ставлю обратный вопрос — достаточно ли простого хэширования вместо PRF на HMAC, чтобы не развалить протокол пусть даже на уровне теоретических уязвимостей?


Вы же спокойно ле'пите (я без негатива и критиканства, с лёгкой доброжелательной иронией только) свой протокол из обрывочных знаний, даже не задаваясь элементарными вопросами.


fileSecurity Issues in the Diffie-Hellman Key Agreement Protocol


Глава 6.The DH Shared Secret Key
Обратите внимание на 6.1 Key Derivation Function (KDF)


In most, if not all, instances we need to modify the shared secret key obtained in the DH protocol in order to use it with other cryptographic primitives. Here are the main motivations for “modifying” the shared DH secret key:

Although some bits of the shared secret are provably secure [13] the security of the vast majority of bits in the shared DH secret key is not known (i.e. it is not known whether an attacker can compute knowledge about them)


In fact, given only p, g, gx and gy in Z*p, we can easily compute the Jacobi symbol p of gxy, and if g generates the whole group than we can also efficiently compute the last bit of xy.

См. также:


7.3 Using the Shared DH Secret Key


Here are the general points related to the utilization of the shared DH secret key.
1. Never Use the Key “As Is”: Always use a suitable key derivation function in order to get a session key.

Вы наивно полагаете, что SHA-256 — это "suitable key derivation function"? Я знаю только то, что она ей никогда не являлась.


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


Не падайте духом, но шифрпанки, искренне желающие написать "код без закладок", очень полезны для NSA.


Даже зачастую специально не придумать таких бэкдоров, которые может учудить оптимистичный софтописатель. Циммерман — тоже не криптограф, при всём к нему уважении, он такой же шифрпанк своего времени. Благо, его код привлёк в своё время очень большое внимание и его направлял даже Шамир.


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




OCB — похоже удачный и обоснованный выбор. Хотя и грамотно реализованный CTR с аутентификацией тоже бы подошёл.

— sentaus (12/04/2013 13:51)   профиль/связь   <#>
комментариев: 1060   документов: 16   редакций: 32
Поищу-почитаю, спасибо.


Пример PRF на базе HMAC можно найти в TLS 1.2 (rfc 5246, раздел 5)
Кстати, что unknown скажет про эту PRF?
— unknown (12/04/2013 14:14, исправлен 12/04/2013 14:16)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Если они ссылаются на это, то ничего плохого. Только без устаревших хэшей (sha-1, md5).


Ну разве что в отдалённом будущем ожидаются универсальные PRP-PRF-примитивы и все эти нагромождения когда-нибудь устареют.

— gegel (12/04/2013 14:44)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0
Огромное спасибо! Вчера уже поздно нагуглил dhfull.pdf и перечитал как раз те разделы, на которые вы позже указали. Уже приятно, что частично сам разобрался :)
Сегодня прикрутил AES256-OCB вместо CAST. По свободному времени займусь PRF.
ПС: я не ставлю основной целью разработать суперзащищенное приложение, просто мне интересно разобраться. Это как вязание для домохозяйки, что-ли... :)
— unknown (12/04/2013 14:55)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
ПС: я не ставлю основной целью разработать суперзащищенное приложение, просто мне интересно разобраться. Это как вязание для домохозяйки, что-ли... :)

Нормальная мотивация, информацию схватываете, работаете с ней самостоятельно, может и в профессиональный навык перейдёт :)
— gegel (14/04/2013 02:19, исправлен 14/04/2013 11:48)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0

Покопал код PGPFone: действительно, уязвимо было...


Так, при DH из битов общего секрета (равного к-ву битов прайма) просто по очереди бралось необходимое к-во первых бит для двух ключей для двух направлений связи :(
симметричный шифр в режиме CTR вообще не имел никакой аутентификации (даже crc32 считалась от криптотекста и просто дописывалась в конец пакета :(


Изменил таким образом:
использую PKCS#5 v2.0 PBKDF2 using HMAC_SHA256, 4096 итераций;
https://polarssl.org/pbkdf2-source-code
http://tools.ietf.org/html/rfc2898#section-5.2
отдаю ей в качестве пароля все биты общего секрета DH;
получаю 512 бит кей-материала для двух ocb-AES-256 ключей;
в качестве IV для ocb использую счетчик от старого режима CTR;
128-битный таг дописываю в конец каждого пакета.


3DES и AES256 в режимах CTR без аутентификации оставил для случаев экономии трафика при работе внутри Tor, т.к. длина пакета на 16 байт меньше, а особой необходимости в шифровании и нету.


Если есть явные ляпы или предположения уязвимости, очень прошу озвучить.

— sentaus (16/04/2013 10:48)   профиль/связь   <#>
комментариев: 1060   документов: 16   редакций: 32
симметричный шифр в режиме CTR вообще не имел никакой аутентификации (даже crc32 считалась от криптотекста и просто дописывалась в конец пакета :(

Круто! :)
Значит в случае использования какого-нибудь adpcm можно было вообще заставить воспроизвести звуковой мусор.

PKCS#5 v2.0 PBKDF2 using HMAC_SHA256, 4096 итераций;

Мне кажется, это даже избыточно. PBKDF2 предназначена для получения ключей из совсем небольшого исходного материала(паролей) и довольно медленная.
Про OCB не скажу ничего, не знаком пока. :(
— gegel (19/04/2013 14:37)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0
в случае использования какого-нибудь adpcm


И не только. Многие синтезирующие кодеки, например, тот же melp, пакуют биты в кадр строго на свои места, и используют старое состояние для инициализации нового. Черт его знает, а вдруг есть возможность, последовательно манипулируя битами, установить определенный известный кадр, и затем менять его уже целенаправленно.
А касательно передачи файлов – полный п-ц: если злоумышленник точно знает, какой файл вы будете передавать, то вообще без никакой криптографии заменяет его на свой, тем самым подсовывая поддельный документ или трояна. Теперь исправил, aes256-ocb будет в следующей верии.

это даже избыточно. PBKDF2


Я вначале хотел использовать только PRF с подходящим размером выхода (например, SHA512 на два 256 бит ключа), но попал под критику :)
Хотя до сих пор тоже не могу понять смысл использования KDF для получения 512 бит кейматериала из 4096 бит DH секрета. Понятно, что без хеширования нельзя, т.к. биты секрета неравнозначны и коррелирующие между собой, но и KDF с ее итерациями и salt, затрудняющими подбор пароля по словарю, тут как бы и ни к чему.

PS: раз уж взялся за криптографию PGPFone (хотя никогда не собирался этого делать), то хочу еще проверить реализацию DH и особенно CSPRNG и коллектор энтропии, там тоже могут быть сюрпризы. Например, nautilus предупреждает, если аудиоэнтропии недостаточно для сидирования CSPRNG (микрофон отключен). PGPFone этого не делает, что уже нехорошо.
— unknown (19/04/2013 15:42, исправлен 19/04/2013 16:28)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

SHA-1 и SHA-2 являются не очень хорошими PRF. Для построения стойкого PRF из них используется HMAC. То, что из HMAC в свою очередь делается (для других уже целей) PBKDF2 не значит, что нужно тащить его туда весь. Достаточно правильно использовать только HMAC.


См. RFC4868 для описания PRF-HMAC-SHA-256, PRF-HMAC-SHA-384, PRF-HMAC-SHA-512.

— gegel (19/04/2013 22:45)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0
Спасибо! Наконец я понял, в чем заблуждался: мне казалось, что отличие между HASH и HMAC только к устойчивости к атакам на подмену подписи и выбранного откр.текста. Если вникнуть в то, как HMAC использует HASH-алгоритм, становится ясно, откуда псевдорандомность.
Еще раз спасибо за расширение кругозора: не знаю, пригодится ли это, но за плечами не носить :)
Переделывать уже не буду: PBKDF2 взял готовую (без напрягов), кроме того, по скорости не критично.

Я, наоборот, дополнительную задержку вводил после подсчета общего секрета: это еще один прикол PGPFone, опишу для поржать.
Во многих доках, начиная с 1996, упоминалось, что PGPFone иногда виснет на этапе согласования ключей. И действительно, около 1/20 конектов зависали. Я решил попробовать разобраться. После подсчета публичного ключа, как и положено, вычислялся его хеш. После предварительного обмена хешами происходил обмен самими ключами. После получения публичного ключа подсчитывался общий секрет и создавался енкриптор, при наличии которого ВСЕ дальнейшие пакеты уходили криптованными. Так вот, если один из участников запаздывал, другой участник формировал енкриптор и отсылал публичный ключ уже в криптованном виде :) Тупейшая ситуация... Я сначала вставил костыль в виде 1 сек задержки перед формированием енкриптора, а затем изменил код, чтобы публичный ключ никогда не шифровался. Теперь не виснет :)
Мне кажется, это не последние сюрпризы...
— Гость (20/04/2013 18:36)   <#>
А касательно передачи файлов – полный п-ц: если злоумышленник точно знает, какой файл вы будете передавать, то вообще без никакой криптографии заменяет его на свой, тем самым подсовывая поддельный документ или трояна.

Передача файлов практически во всех протоколах (за исключением имеющих встроенную поддержку передачи файлов на должном уровне, типа SSH и OpenVPN) не шифруется, поэтому нужно самому зашифровать файл, подписать с помощью gpg и отправить собеседнику. Подмена файла атакующим в этом случае (и только в этом) исключается. Например, так рекомендуется передавать файлы через XMPP и Skype.
— gegel (21/04/2013 10:09, исправлен 21/04/2013 10:11)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0

PGPFone использует нестандартный Циммерманновский протокол передачи файлов, задумывался он как надежный. Он достаточно сложный, я с ним детально не разбирался. Это как бы свой ftp-tcp поверх udp. Имя файла или папки получаем методом drag&drop, выстраиваем файлы в очередь, каждый файл инициализируем (имя, длина, SHA), передаем пакетами размером около 900 байт с указателем, подтверждаем группу байт, дублируем при потерях. Конечно, медленнее чем ftp или http, но выглядет надежно. Используется отдельный счетчик пакетов для передачи файлов. Его значение + тип пакета входят в IV.
Проблема была не в протоколе, а в режиме CTR без аутентификации: зная, какой файл будет передаваться (plaintext), ксором получаем гамму и затем формируем новый cifertext из гаммы и своего plaintext (включая пакет с именем файла, длиной, sha...), пересчитываем crc32 – и подмена готова.
При использовании OCB это исключено. Т.е. после согласования ДИффи-Хеллмана и аутентификации (голосом по списку слов или предустановленной фразой с использованием HMAC) можно быть уверенным в аутентичности файла и конфиденциальности: предварительное шифрование/подписывание PGP вроде как и не нужно. Хотя, конечно, береженого бог бережет...

— Гость (21/04/2013 21:14)   <#>
Мне кажется, что решать задачу защищённой передачи файлов следует, используя каждое средство для своего предназначения. Есть протоколы, обеспечивающие только передачу файлов (http и др.). Ими можно передавать файл. Шифровать его можно перед этим совсем другими средствами (gpg). gpg само по себе обеспечивает как шифрование, так и подпись файла, поэтому получателю всё равно откуда он его скачал, хоть с публичных торрентов. При желании всё это можно автоматизировать, добавив в torphone: он как сам шифрует и подписывает файл перед отправкой от себя, так и расшифроваывает и проверяет подпись при получении файлов от других.
— gegel (21/04/2013 23:15)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0
Можно, конечно, и так сделать, прикрутив, например, вызов консоли GPG с TORFone.
Но я веду к тому, что TORFone сейчас и без GPG обеспечивает как шифрование, так и аутентичность передаваемого файла, так что предварительное шифрование/подписывание необязательно. Скорость медленнее, чем ftp или http, но для небольшого файла не критично. Как преимущество – некоторая маскировка факта передачи файла за счет нестандартного протокола.
А вообще то это задумывалось как вспомогательная фича, а вариантов анонимного файлобмена может быть много, например GPG+стеганография и в облако, или PGP и в папку http-сервера на Tor HS.
Конечно, Вы в праве (и должны) НЕ доверять протоколу TORFone до изучения исходников, поэтому ручное предшифрование не помешает.
— gegel (11/06/2013 12:05, исправлен 11/06/2013 12:16)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0

Наконец нашлось время допилить Торфон до fileбеты 1.1. Постарался учесть все замечания и пожелания, а также реализовал две свои идеи, которые давно вынашивал. Руководство по тестированию в картинках обновлю в ближайшее время, пока можно пользоваться обновленным html-хелпом (англ., рус.) в пакете TORFona и на сайте.
Хочу представить Торфон как звуковой плагин для популярного Торчата: нужно лишь добавить строку в файл torrc.txt, запустить Торфон, и можно выполнять и принимать звонки. В любой момент разговора можно переключиться на прямое UDP-соединение (выполняя NAT Traversal), просто установив галочку "UDP". Затем можно выбрать HQ-кодек (например, OPUS) и наслаждаться связью. Или выбрать супер-экономный MELPE и расходовать всего 2 Мбайт GPRS (в обе стороны) за час постоянного разговора. Сравните со Skype...
Само собой, TORFone полностью портабельный, работает c трукриптовского диска, из-под виртуалки WinXP (с сетевыми и звуковыми драйверами) и из-под Wine. Я взял на себя смелость внести значимые изменения в криптографию, поэтому версия 1.1 не совместима с 0.X
Криптография:
1. Добавил fileAES-256-OCB (128 bit MAC).
Есть смысл использовать при прямых соединениях и меньше – при работе через Tor (чем больше длина пакетов, тем больше задержка)
2. Для получения ключей с общего секрета DH использую PKDF2
3. В процедуре аутентификации по списку слов заменил SHA1 на HMAC_SHA1 для предупреждения атаки подмены выбранного откр.текста (вместе с общим секретом там хеширутся еще куча параметров, которые можно менять).
4. Проверил источники энтропии CSPRNG, там все ОК (мышь, аудио вход, таймеры производительности и системного времени), но на выходе заменил SHA1 на HMAC_SHA1 из соображений рэндомности.
5. В двухфазной аутентификации с скрытым уведомлением под прессингом использовал PKDF2 для формирования тэга из фразы и HMAC собственно для аутентификации.
Голос:
1. Использовал кодеки MELP-2400 (MIL-STD-3005) (MELP не любит встроенный высокочувствительный микрофон: намного лучше выносной в составе гарнитуры у губ говорящего с минимально необходимой чувствительностью (в т.ч. и из соображений анонимности)) и CODEC2-1400 для работы через Tor, накапливая 900 и 1600 мс голоса соответственно в одном пакете: так компенсация Jitter даже лучше, чем при пользовании дополнительного буфера.
2. Добавил кодек fileMELPE-1200 (STANAG-4591 NATO) и CODEC2-3200 для работы через GPRS: при приемлемой задержке в 350 мс получается всего 0.3-1.0 Кбайт/сек в одном направлении.
3. Добавил HQ-кодеки GSM0610
(взял со SpeekFrealyOPUS в режиме VBR 6 Кбит/с с возможностью опции маскировки VBR для предупреждения fileатаки фонетической реконструкции.
4. Добавил опцию подавитель шума NPP7 для подавления случайных деанонимизирующих звуков окружения.
5. Добавил опцию вокодера для деперсонализации голоса. Использовал fileалгоритм синтезирующего кодека.
Можно выбрать стандартные предустановленные режимы (голос высокий, низкий, робота, шепот, интонация вверх и вниз). По данной теме очень мало материала в паблике, похоже, такой же алгоритм используется fileдачи анонимных свидетельский показаний в судах и выглядит надежным для правдоподобного отрицания при голосовой идентификации.
6. Поправил режим рации (PTT) и голосового управления (VOX), теперь не теряется конец фразы. PTT может быть использован для экономии GPRS-трафика и для удобства общения в Tor (В определенных пределах наблюдается четкая корреляция между общим трафиком и латентностью Tor-канала. Кроме того, латентность существенно выше при использовании Exit-нод, но это уже другая история: кому интересно, поделюсь результатами своих исследований для Tor и I2P).
Транспорт:
1. Наконец реализовал давнюю идею, позволяющую уменьшить Tor-задержки. После установки соединения с HS адресата ему посылается инвайт с указанием своего HS. Вызываемый устанавливает встречное соединение с вызывающим (по другим цепочкам). Голосовые пакеты дублируются в оба канала, используется пакет, доставленный первым (по таймстемпу). Накапливается статистика и периодически через заданный интервал времени более медленный канал согласованно переподключается, пока второй используется. Реально уменьшает задержки в полтора раза. Если отказаться от сторожевых узлов, то возможно, и больше. Не могу сказать, как такое дублирование повлияет на эффективность атак деанонимизации, на Tor-мейл-листе не ответили...
2. Также реализовал свою вторую идею: использование Tor в качестве SIP (если анонимность не важна). Нет привязки к конкретному VOIP-серверу, регистрации и логов на нем, DH выполняется внутри p2p-Tor-шифрования к HS (MitM практически нереально), используется нестандартный UDP-протокол (определенная обфускация от DPI)), если NAT Traversal невозможен, то Tor выполняет функцию TURN.
Абонент находит другого по onion-ссылке средствами Tor-HS инфраструктуры, затем выполняется Diffie-Hellmann под прикрытием Tor и затем NAT Traversal с использованием любого заданного публичного STUN. Я не использовал техники NAT penentratin, поэтому UDP не будет установлено, если оба абонента за симметричными NAT, но это бывает не так часто. Кроме того, проблемы могут быть, если оба абонента за любыми NAT (домашними роутерами) и затем за общим NAT (в локалке провайдера). У меня не было возможности проверить на большом количестве сетей, но во всех проведенных тестах прямое UDP-соединение было установлено. Вобще, было бы очень неплохо убедить разработчиков реализовать такой без-серверный VOIP, например, в Jitsi.
Другое:
1. Добавил индикатор исходящего/входящего трафика (с учетом IP-заголовков) в кбитах/сек и общий счетчик сеансового трафика в кбайтах, а также индикатор состояния двойного Tor-соединения.
2. Для компиляции fileисходного кода теперь достаточно установить Visual C 6.0 на Windows XP, открыть файл проекта и нажать кнопку. Больше никаких пакетов и внешних библиотек не требуется. Абсолютно все используемые библиотеки в С-исходниках и доступны для анализа.


Спасибо сообществу pgpru за помощь, буду благодарен за замечания и пожелания.

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