id: Гость   вход   регистрация
текущее время 17:04 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, ... , 12, 13, 14, 15, 16, ... , 50 След.
Комментарии
— sentaus (08/04/2013 13:33, исправлен 08/04/2013 13:36)   профиль/связь   <#>
комментариев: 1060   документов: 16   редакций: 32
Я так понимаю, хотим сделать подмену. Да, можно побитно манипулировать с текстом и с crc ( т.к. CTR), а дальше как???

Если номер и timestamp в вычислении хэша не участвует, то совсем беда. Номер и timestamp можно подделать. Если участвует, что уже сложнее, хотя тут возможно получится особенностями crc воспользоваться.


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

Все делают ошибки. :) Кстати, в PGP была одна слабость в механизме защиты секретных ключей, когда там crc32 использовалась. Её нашли и исправили уже в пост-Циммермановское время. Я деталей не помню, но вдруг аналогичный подход и тут сработает?


А вообще да, истории последних лет (SSL/TLS – ярчайший пример) как-то не вдохновляют: теоретические слабости часто вырастают в чудесные практические уязвимости.

— gegel (08/04/2013 15:55)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0
Спасибо за замечание, в первую очередь unknown. Подумав, не могу не согласиться со всем сказанным. Конечно же, на crc32 нельзя полагаться для подтверждения аутентичности пакета. И дело тут в первую очередь в режиме CTR. Например, зная, какой файл я собираюсь передавать с помощью PGPFone, злоумышленник может изменить его содержимое на свое (включаю общую SHA). Это тяжелый баг, и удивительно, что никто ранее не указал на него, а я никогда не ставил целью инспектировать код Циммерманна...

Вопрос к гуру: как вы относитесь к AES OCB в данном случае? В качестве IV для пакета можно использовать готовый неповторяемый counter, ранее использовавшийся для CTR. В качестве тага – часть хеша общего секрета.
Естественно, совместимости с V0.3 не будет, но лучше так, чем оставить как есть...
— unknown (08/04/2013 16:33, исправлен 08/04/2013 16:36)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Как понять готовый? Доказано, что, к примеру в CBC, IV должен быть строго рэндомный, из CS(P)RNG. IV-счётчик или IV-функция не прокатит — это позволяет строить различители блоков. Смутно припоминаю, что и для других режимов скорее всего также, иначе бы не изобретали заумных схем с SIV (синтетическим IV для детерминистического шифрования).


Советую не изобретать свой протокол, тем более без умения его формализовать, возьмите что-то готовое. Ну хотя бы внутри SSL/TLS-каналов пустите.



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

— gegel (08/04/2013 17:51, исправлен 08/04/2013 18:57)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0
Как понять готовый?

Счетчик, к сожалению... Я не особо профи в криптографии, но не хотелось прикручивать готовый SSL/TLS. Если будет возможность, дайте ссылку для повышения образованности на

это позволяет строить различители блоков

(или в двух словах об этом).
Поищу по OCB, может, там IV-счетчик и допускается.


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

— Гость (08/04/2013 20:00)   <#>

А если пакет потерялся нечайно? Много может быть неожиданностей, вплоть до «атакующий угадал counter». Одно время назад писалось про уязвимость TCP-стека в винде и линуксе из-за недостаточной случайности выбора случайных чисел, используемых как counter (утверждалось, что в OpenBSD с этим лучше; как сейчас — не знаю).
— gegel (08/04/2013 21:53, исправлен 08/04/2013 21:55)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0

Так IV по определению известный, зачем его угадывать. Другое дело, что он должен быть уникальным на каждый пакет, и, как указал unknown, рандомным, иначе, я так понял, облегчается дифференциальный криптоанализ.
Я выше уже описывал работу программы: в начале пакета PGPFone передает 2 байта инрементируемый ИД, восстанавливамый до 32-битного счетчика. Счетчик работает только вперед: пакеты с меньшим ИД будут отвергаться.
Конечно, это создает почву для DDoS, но не уязвимость криптографии.
А вот касательно IV-счетчика при наличии небольшого количества пар зашифр.-расшифр. блоков хотелось бы услышать мнение.

— unknown (08/04/2013 22:10, исправлен 08/04/2013 22:28)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Другое дело, что он должен быть уникальным на каждый пакет, и, как указал unknown, рандомным, иначе, я так понял, облегчается дифференциальный криптоанализ

Не по этому. Если облегчается, то такой шифр — на помойку сразу. Возможно вы не так поняли. Рэндомное только стартовое значение, дальше обычное приращение по счётчику. Счётчик разумеется открытый. Противник не должен до начала передачи предсказать значение счётчика.



Если вы претендуете на конструирование системы, скажем, со 128-битным уровнем безопасности, то каждый её кирпичик тоже должен обеспечивать такой уровень. Исключения надо обосновывать технической невозможностью включить что-то стойкое по уровню (высокие накладные расходы, а не "я не осилил правильный протокол, сойдёт и так") и считать, как это влияет на результат. Кое-какие вещи даже НИСТ не может осилить и допускает ляпы в стандартах.


Но если постараться, то может быть, у вас будет доказуемо безопасный протокол в некоем далёком приближении. Специалисты из АНБ говорили в интервью и в каких-то документах, что им не нужно взламывать 128-битные шифры или делать закладки. Реальная стойкость большинства программ бывает катастрофически низкой из-за некачественной реализации. Хотя там гордо красуются большие ключи и стойкие алгоритмы, но провалены протоколы.


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


Конкретно по этому вопросу читайте признанных специалистов:


fileEvaluation of Some Blockcipher Modes of Operation, Mihir Bellare.


Это только режимы, но не протоколы.


Здесь ещё смотрите: fileLecture Notes on Cryptography, Shafi Goldwasser, Mihir Bellare. С примерами, как взломать CBC и CTR с неправильно используемым IV за одну операцию — запрос к оракулу. Такой модный криптоанализ с параллельными мирами, в которых сидят разные оракулы, тоже представлен, куда же без него-то теперь.


Дело ваше, набирайтесь знаний и опыта. Но я бы лично не взялся в одиночку конструировать протокол построения защищённых каналов связи с нуля, без посторонней помощи. У меня такой квалификации нет. В лучшем случае внедрить готовый стандарт. И там есть поле для наступания на грабли с фатальными ошибками и подкладыванием самому себе таких бэкдоров, от которых любое АНБ помрёт со смеху.


Ну и выкиньте из головы вопрос: "как это можно взломать?" Построение безопасной системы начинается с других вопросов: "как это можно отличить от идеальной модели?", "есть ли хоть какие-то самые абстрактные различители?", "как можно формально обосновать стойкость?".


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

— gegel (08/04/2013 22:26)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0
ОК, теперь понятнее :)
Кстати, как раз нашел для OCB:
http://www.cs.ucdavis.edu/~rog.....faq.htm#describe-ocb

Let N be the 96-bit nonce—for example, a counter that gets incremented with each message you encrypt.


Рэндомное только стартовое значение, дальше обычное приращение по счётчику.
Тогда почему бы не взять AES128, а неиспользуемые в ключе биты общего секрета DH загнать в IV, и затем суммировать их со счетчиком?
Посмотрю исходники Mosh, там вроде тоже AES OCB.
— unknown (08/04/2013 22:40)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Неиспользуемые биты? Вот так просто взять? Во-первых, все такие связки по выведению одного секрета из другого делаются с помощью KDF, чаще всего HMAC-KDF. Во-вторых, в чём проблема сделать чистую рэндомизацию без синтетического IV, который в вашей схеме выводится из других элементов протокола? У вас же не смарткарта, где случайные числа получить неоткуда.
— Гость (10/04/2013 01:46)   <#>

Bellare тут ни при чём, работа написана Рогавеем (хотя весь беллар работы в благодарностях).
Если gegel попытается её осилить, он быстрее ороговеет, чем станет Рогавеем, от работ которого будут роговеть уже другие, менее ороговевшие криптографы. IMHO.
— unknown (10/04/2013 09:52, исправлен 10/04/2013 10:58)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Спасибо за замечание, исправление ошибки по авторству и тонкий комментарий :) Согласен с каждым словом.


А работа выдающаяся, жаль, что её похоже ещё долго не смогут оценить даже бюрократы специалисты, составляющие стандарты в НИСТе. Ибо, судя не только по этой работе у них там не всё гладко, и в криптосообществе нарастает недовольство косностью НИСТа.


Согласно Рогвею, смайлик, обозначающий случайного оракула, выглядит вот так: $(·,·). Gegel, вы уже вывели формулу с учётом IV для Adversary Advantage в своём протоколе: AdvεIND$ (A) = Pr[AεK(·,·) ⇒ 1] − Pr[A$(·,·) ⇒ 1] ?


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

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

Неиспользуемые биты? Вот так просто взять?

Я имел ввиду: взять половину бит уже ключа. Но Вы опять натолкнули на размышления:
почитав rfc2631, а затем просмотрев код PGPFone в части DH (я раньше туда не смотрел), я нашел, что в качестве битов ключа используются непосредственно биты общего секрета (результата ExpMod). Это тоже можно считать уязвимостью?

связки по выведению одного секрета из другого

Я подразумевал взять НЕИСПОЛЬЗУЕМУЮ половину бит: они по идее рандомны и никак не коррелируют с другими элементами протокола.

в чём проблема сделать чистую рэндомизацию без синтетического IV

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

=== ППС: Вопрос по IV снят, но вопрос по DH актуален, посоветуйте, плз.


От Rogaway, слайд 9:
filehttp://csrc.nist.gov/groups/ST.....resentations/ocb.pdf

What is OCB?
...
Lots of nice characteristics designed in:
...
Uses any nonce (needn’t be unpredictable)

— unknown (11/04/2013 23:16, исправлен 11/04/2013 23:28)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Они хоть похэшированы как-то? Результат сырого согласования по DH — не рэндомный и подвержен утечке битов через символы Якоби. Вот думаете, почему подписи RSA ломались в своё время? Из-за кривого стандарта дополнения в симметричной части. Для чего был придуман OAEP?


Для выведения общих секретов из одного используются PRF на хэшах.


Вот собрались как-то криптографы и ковырятели кода и почти поломали PGP. Не удивлюсь, если в спецагентствах команды из криптографов и кодокопателей давно ведут работу, выявляя на потоке большой массив уязвимостей по всевозможным VPN-ам и SSL, так что их суперкомпьютерам не нужно перебирать весь массив ключей.

— Гость (11/04/2013 23:43)   <#>
меня больше прикладные задачи интересуют: я выбрал развитие вширь, а не вглубь.
Криптография и есть прикладная штука. Вглубь — это становиться математиком и изучать теорию чисел, например.
— gegel (12/04/2013 00:40)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0
В том то и дело, что не хешированы: в качестве ключа используется сырой результат DH-согласования. Я поэтому и спрашиваю, на сколько это есть плохо. rfc2631 показывает, как из общего секрета получать ключ в случае, если длина ключа больше длины SHA. Т.к. у нас вопрос с IV отпал, то общий секрет будет использоваться ТОЛЬКО для формирования ключа. Наверное, вместо того, чтобы просто использовать часть его бит как ключ, стоит посчитать SHA-256 и использовать ее значение в качестве ключа, как думаете?

Результат сырого согласования по DH — не рэндомный и подвержен утечке битов через символы Якоби.


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