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).
комментариев: 1060 документов: 16 редакций: 32
Если номер и timestamp в вычислении хэша не участвует, то совсем беда. Номер и timestamp можно подделать. Если участвует, что уже сложнее, хотя тут возможно получится особенностями crc воспользоваться.
Все делают ошибки. :) Кстати, в PGP была одна слабость в механизме защиты секретных ключей, когда там crc32 использовалась. Её нашли и исправили уже в пост-Циммермановское время. Я деталей не помню, но вдруг аналогичный подход и тут сработает?
А вообще да, истории последних лет (SSL/TLS – ярчайший пример) как-то не вдохновляют: теоретические слабости часто вырастают в чудесные практические уязвимости.
комментариев: 393 документов: 4 редакций: 0
Вопрос к гуру: как вы относитесь к AES OCB в данном случае? В качестве IV для пакета можно использовать готовый неповторяемый counter, ранее использовавшийся для CTR. В качестве тага – часть хеша общего секрета.
Естественно, совместимости с V0.3 не будет, но лучше так, чем оставить как есть...
комментариев: 9796 документов: 488 редакций: 5664
Как понять готовый? Доказано, что, к примеру в CBC, IV должен быть строго рэндомный, из CS(P)RNG. IV-счётчик или IV-функция не прокатит — это позволяет строить различители блоков. Смутно припоминаю, что и для других режимов скорее всего также, иначе бы не изобретали заумных схем с SIV (синтетическим IV для детерминистического шифрования).
Советую не изобретать свой протокол, тем более без умения его формализовать, возьмите что-то готовое. Ну хотя бы внутри SSL/TLS-каналов пустите.
Это полуюмористическое замечание на самом деле. Глубоко в ваш проект не вникал. Тяжело разбирать наколеночный дизайн, руководствуясь догадками при отсутствии документации. Открытый код недостаточен и интересен уже в самую последнюю очередь, после анализа всего остального. Ну и нечаянно вышел наглядный пример, почему теоретики, в массе своей, программ не пишут, только мало кем читаемые публикации. Спасибо за то, что имеем, оптимистичным практикам.
комментариев: 393 документов: 4 редакций: 0
Счетчик, к сожалению... Я не особо профи в криптографии, но не хотелось прикручивать готовый SSL/TLS. Если будет возможность, дайте ссылку для повышения образованности на
(или в двух словах об этом).
Поищу по OCB, может, там IV-счетчик и допускается.
PS: немного погуглил и почерпнул знаний из Ваших же постов на форуме.
По ходу вопрос: а стоит ли на это обращать внимание, учитывая, что симметричный ключ для каждого сеанса новый? По подсчетам, за 1 час связи вряд ли будет больше 500 000 AES-блоков. Думается, это не совсем то, что нужно для практического использования описанной уязвимости, даже предполагая знание незашифрованных данных.
А если пакет потерялся нечайно? Много может быть неожиданностей, вплоть до «атакующий угадал counter». Одно время назад писалось про уязвимость TCP-стека в винде и линуксе из-за недостаточной случайности выбора случайных чисел, используемых как counter (утверждалось, что в OpenBSD с этим лучше; как сейчас — не знаю).
комментариев: 393 документов: 4 редакций: 0
Так IV по определению известный, зачем его угадывать. Другое дело, что он должен быть уникальным на каждый пакет, и, как указал unknown, рандомным, иначе, я так понял, облегчается дифференциальный криптоанализ.
Я выше уже описывал работу программы: в начале пакета PGPFone передает 2 байта инрементируемый ИД, восстанавливамый до 32-битного счетчика. Счетчик работает только вперед: пакеты с меньшим ИД будут отвергаться.
Конечно, это создает почву для DDoS, но не уязвимость криптографии.
А вот касательно IV-счетчика при наличии небольшого количества пар зашифр.-расшифр. блоков хотелось бы услышать мнение.
комментариев: 9796 документов: 488 редакций: 5664
Не по этому. Если облегчается, то такой шифр — на помойку сразу. Возможно вы не так поняли. Рэндомное только стартовое значение, дальше обычное приращение по счётчику. Счётчик разумеется открытый. Противник не должен до начала передачи предсказать значение счётчика.
Если вы претендуете на конструирование системы, скажем, со 128-битным уровнем безопасности, то каждый её кирпичик тоже должен обеспечивать такой уровень. Исключения надо обосновывать технической невозможностью включить что-то стойкое по уровню (высокие накладные расходы, а не "я не осилил правильный протокол, сойдёт и так") и считать, как это влияет на результат. Кое-какие вещи даже НИСТ не может осилить и допускает ляпы в стандартах.
Но если постараться, то может быть, у вас будет доказуемо безопасный протокол в некоем далёком приближении. Специалисты из АНБ говорили в интервью и в каких-то документах, что им не нужно взламывать 128-битные шифры или делать закладки. Реальная стойкость большинства программ бывает катастрофически низкой из-за некачественной реализации. Хотя там гордо красуются большие ключи и стойкие алгоритмы, но провалены протоколы.
Устойчивость к атакам с подобранными текстами на нерандомизированных IV не достигается, и вообще шифрование везде, за исключением особых случаев должно быть рэндомизированным, но IV в CTR как раз наиболее практичен в этом плане и прощает большинство ошибок.
Конкретно по этому вопросу читайте признанных специалистов:
Evaluation of Some Blockcipher Modes of Operation, Mihir Bellare.
Это только режимы, но не протоколы.
Здесь ещё смотрите: Lecture Notes on Cryptography, Shafi Goldwasser, Mihir Bellare. С примерами, как взломать CBC и CTR с неправильно используемым IV за одну операцию — запрос к оракулу. Такой модный криптоанализ с параллельными мирами, в которых сидят разные оракулы, тоже представлен, куда же без него-то теперь.
Дело ваше, набирайтесь знаний и опыта. Но я бы лично не взялся в одиночку конструировать протокол построения защищённых каналов связи с нуля, без посторонней помощи. У меня такой квалификации нет. В лучшем случае внедрить готовый стандарт. И там есть поле для наступания на грабли с фатальными ошибками и подкладыванием самому себе таких бэкдоров, от которых любое АНБ помрёт со смеху.
Ну и выкиньте из головы вопрос: "как это можно взломать?" Построение безопасной системы начинается с других вопросов: "как это можно отличить от идеальной модели?", "есть ли хоть какие-то самые абстрактные различители?", "как можно формально обосновать стойкость?".
Как из этого сделать практический взлом сходу не смогут оценить даже ведущие специалисты, им проще забраковать на сертификации недостаточно обоснованное в плане безопасности решение.
комментариев: 393 документов: 4 редакций: 0
Кстати, как раз нашел для OCB:
http://www.cs.ucdavis.edu/~rog.....faq.htm#describe-ocb
Тогда почему бы не взять AES128, а неиспользуемые в ключе биты общего секрета DH загнать в IV, и затем суммировать их со счетчиком?
Посмотрю исходники Mosh, там вроде тоже AES OCB.
комментариев: 9796 документов: 488 редакций: 5664
Bellare тут ни при чём, работа написана Рогавеем (хотя весь беллар работы в благодарностях).
Если gegel попытается её осилить, он быстрее ороговеет, чем станет Рогавеем, от работ которого будут роговеть уже другие, менее ороговевшие криптографы. IMHO.
комментариев: 9796 документов: 488 редакций: 5664
Спасибо за замечание, исправление ошибки по авторству и тонкий комментарий :) Согласен с каждым словом.
А работа выдающаяся, жаль, что её похоже ещё долго не смогут оценить даже
бюрократыспециалисты, составляющие стандарты в НИСТе. Ибо, судя не только по этой работе у них там не всё гладко, и в криптосообществе нарастает недовольство косностью НИСТа.Согласно Рогвею, смайлик, обозначающий случайного оракула, выглядит вот так: $(·,·). Gegel, вы уже вывели формулу с учётом IV для Adversary Advantage в своём протоколе: AdvεIND$ (A) = Pr[AεK(·,·) ⇒ 1] − Pr[A$(·,·) ⇒ 1] ?
комментариев: 393 документов: 4 редакций: 0
:)
Спасибо за ссылки, но становиться криптографом я и не собираюсь, меня больше прикладные задачи интересуют: я выбрал развитие вширь, а не вглубь. Эти надо было с детства начинать заниматься, сейчас мне уже поздновато :(
А поэтому, если можно, буду обращаться по ходу дела за готовыми выводами и мнениями.
Я имел ввиду: взять половину бит уже ключа. Но Вы опять натолкнули на размышления:
почитав rfc2631, а затем просмотрев код PGPFone в части DH (я раньше туда не смотрел), я нашел, что в качестве битов ключа используются непосредственно биты общего секрета (результата ExpMod). Это тоже можно считать уязвимостью?
Я подразумевал взять НЕИСПОЛЬЗУЕМУЮ половину бит: они по идее рандомны и никак не коррелируют с другими элементами протокола.
собственно, в синхронизации его у обоих абонентов. Потребуются дополнительные элементы протокола. В описанном выше варианте оба абонента уже имеют одинаковый и рандомный (причем рандомизированный обоими абонентами) IV, не связанный с другими криптоэлементами.
ПС: просьба не пинать, это не моя отрасль, но хочется разобраться. Посоветуйте, если что не так. С ув.
=== ППС: Вопрос по IV снят, но вопрос по DH актуален, посоветуйте, плз.
От Rogaway, слайд 9:
http://csrc.nist.gov/groups/ST.....resentations/ocb.pdf
комментариев: 9796 документов: 488 редакций: 5664
Они хоть похэшированы как-то? Результат сырого согласования по DH — не рэндомный и подвержен утечке битов через символы Якоби. Вот думаете, почему подписи RSA ломались в своё время? Из-за кривого стандарта дополнения в симметричной части. Для чего был придуман OAEP?
Для выведения общих секретов из одного используются PRF на хэшах.
Вот собрались как-то криптографы и ковырятели кода и почти поломали PGP. Не удивлюсь, если в спецагентствах команды из криптографов и кодокопателей давно ведут работу, выявляя на потоке большой массив уязвимостей по всевозможным VPN-ам и SSL, так что их суперкомпьютерам не нужно перебирать весь массив ключей.
комментариев: 393 документов: 4 редакций: 0
Поищу-почитаю, спасибо.