ZAS Communicator
ZAS Communicator Opensource Project: secure voice, file transfer and text chat.
Комментарии, советы, предложения?
|
||||||||||||||||||||||||||
|
||||||||||||||||||||||||||
Нормы пользования. Некоторые права на материалы сайта защищены по условиям лицензии CreativeCommons. Движок
openSpace 0.8.25a и дизайн сайта © 2006-2007 Vlad "SATtva" Miller.
|
||||||||||||||||||||||||||
комментариев: 393 документов: 4 редакций: 0
Если Вас не затруднит, опишите поподробнее этот момент:
Анализировать код пока нет времени, но хочу понять:
– как происходит первичный DH-обмен и из чего выводится общий секрет?
– какие параметры подписываются, какой алгоритм подписи используется?
Я к тому веду, что как бы Вы не повторили ошибку раннего OTR (возможность UKS-атаки). Это конечно, мелочь на общем фоне реализации, но все же.
Мне просто по человечески интересно, почему Вы так распределили размер полей? Ведь чем-то руководствовались же?
Неужели длина пакета может потребовать 32 бита? Неужели есть смысл передавать полный порядковый номер? Ведь достаточно передать short, а затем развернуть его до уникального long long на стороне получателя (посмотрите, как сделано Циммерманном в PGPFone). И, с другой сторны, неужели достаточно 32-битного MAC для декларируемого Вами более чем 128-битного уровня безопасности (судя по размеру DH-ключей)?
Отвечающая сторона отвечает Y = (g^y) mod P; с подписью от (g,Y,p)
Обе стороны вычисляют секрет соответственно = (X^y) mod P = (Y^x) mod P.
Подпись: одна из многих возможных реализаций подписи на основе дискретных логарифмов. То, что Шнайер называет p-new.
Точнее говоря, 64-битный счетчик байтов в данной сессии в данном направлении. Мы устанавливаем коммуникационную сессию на долгое время; чтобы не заниматься переустановкой лишний раз. Перекачка файлов – могут проходить гигабайты. 32 бита мало. Значит, 64 бита.
32-битная длина – тоже имелась в виду отправка файлов (TCP), а также для шифрования файлов на диске.
32-битный MAC – более чем достаточно для защиты от подсовывания левых пакетов или модификации пакетов на лету. Система не принимает пакетов со счетчиком из прошлого.
Оверхед от вспомогательных полей = +16 байт на пакет. Войсовый траффик ~ 40 байт на пакет. Нет смысла экономить байты, тем более что траффик и так невелик. PGP Phone в том числе работает через соединение по модему, им существенно ужать траффик. В нашем случае это несущественно.
zas@zas-comm.ru
комментариев: 393 документов: 4 редакций: 0
Собственно, так и ожидалось. Просмотрите Раздел 3.1 и Раздел 2.2 работ по OTR и не наступайте на те же грабли.
На будущее: скачайте исходники PGPFone и посмотрите файл:
PGPfone21-win.zip\PGPfone\src\common\CPFPackets.cpp
а именно: процедуры SendPacket (line 697) и GetPacket (line 829).
Вполне достаточно включать в пакет 16-битовый счетчик и на принимающей стороне восстановить 64-битовое исходное значение.
Так это тоже счетчик отправленных байт? Но зачем второй? Или все же длина UDP-пакета? Но она ограничена и вполне вписывается в short. Для TCP длина пакета вообще неактуальна, т.к. все равно их лопатит алгоритм Нагля – и там же поток. Непонятно...
В принципе, если брать данную конкретную реализацию и не учитывать возможности атакующего в стандартных моделях, то, наверное, да. Тем более, что малый интервал между голосовыми пакетами (20 mS) в перерасчете, скажем, на год, эквивалентен еще 27 битам стойкости против брутфорса. Но такой подход сильно нервирует публику.
Где-то у Шнайера было замечание, что в случае VOIP собственно сам голос является аутентификатором (ведь, сверяя список слов, им же и пользуются для обнаружения MitM). В нативном PGPFone из этих соображений вообще нет никакой аутентификации голосовых пакетов. Но это ни в коей мере не относится к чату и к передаче файлов.
PS: и, ради Бога, по возможности прикрутите хотя-бы опционно нормальное шифрование и хеши. Если не доверяете финалистам AES и вариантам SHA, используйте что-то изз модерна, например, Бернштейновские Salsa20 и Blake2 отсюда и PRNG отсюда, а то как-то стремно пользоваться.
* В подписи, кроме DH параметров, содержится собcтвенное ID и ID корреспондента. Кроме того, там есть сертификаты и много других полей. Все проверяется.
* Корреспонденты должны верифицировать друг друга; как и в любой системе на открытых ключах.
* Если противник украл эфемерную секретную экспоненту, то он может делать authentification replay атаки, выдавая себя за валидного корреспондента. Но, если противник умеет красть секретные экспоненты, почему бы ему сразу не украсть private key подписи, таким образом скомпрометировав юзера полностью?
* 16 или 64 битный счетчик. Cовершенно неважно. Нам не нужно уникальное число как IV для PRNG. PRNG инициализируется один раз при установлении связи с данным корреспондентом, и далее постоянно идет в направлении только вперед. Cчетчик нужен для проматывания PRNG вперед в случае пропуска пакетов; а также как переменный параметр при вычислении MAC.
* 32 битная длина текущего пакета в байтах. Cущественный параметр; т.к. фиксирует длину блока, для которого считается хеш MAC. Можно было бы сделать поле покороче; но нет никакого смысла экономить байты и нарушать общность. Одна и та же процедура шифрования используется для разных целей.
* 32 битный MAC пакета; считается от зашифрованных данных, с 64-битным cекретным MAC IV и 128-битным MAC ключом (независимыми от ключа для шифрования) Противник может посылать O(2^32) пакетов в надежде что какой-то из них будет принят, расшифруется в кучу мусора и как-то дезорганизует работу cистемы. Как вы представляете посылку 2^32 пакетов по UDP в промежутке между двумя валидными войсовыми, чатовыми и тем более пакетами с данными? Даже если противнику и удастся протолкнуть пачку случайного мусора, то какая ему от этого польза?
* Ecли не cтоит задача супер-оптимизации на скорость, то сделать сильный криптоалгоритм, зная основы, не составляет труда. Большинство обнаруженных слабостей криптоалгоритмов как раз вызваны тем, что авторы старались предельно оптимизировать скорость. В нашем случае скорость абсолютно неактуальна, а раз так – нет смысла в новомодных изысках. Оптимизация на скорость контрпродуктивна с точки зрения безопасности. Каскадировав несколько разных алгоритмов, получаем систему, достойную большего доверия, чем каждый из алгоритмов в частности.
Кстати, посмотрел ваш проект torphone. Вызывает уважение: безопасная телефония + анонимизация + deniability – широкий круг поставленных задач. Однако почему TOR а не I2P ?
...A ламеры пусть лечат собственную импотенцию повторением чужих мантр.
zas@zas-comm.ru
Перестраховочное крипто? Уже проходили, спасибо.
Вы хоть знаете, что такое каскады?
Наконц, вся суть в этих словах:
Надо так. Вам не понять. А TOR'а вообще нет, есть Tor.
Ссылки на каскады хорошо видно? Срач по ним, значит, тоже. Второго срача не будет. Топик прикроют, а все дальнейшие посты с рекламой вашего говноподелия будут отправляться сюда.
комментариев: 393 документов: 4 редакций: 0
Действительно, ИД корреспондента препятствует UKS. Но какому из утверждений верить? Не повторяйте моей ошибки – сделайте подробнейшее описание протокола, вынесите на обсуждение и не игнорируйте ни одного замечания. Больше коррекции – больше надежность.
No comments. После таких заявлений вы отгоните даже самых толерантных юзеров.
Ладно, тестируйте пока. Если получится прилично с DHT-транспортом, я форкну и сам прикручу, не проблема.
Во первых, см. коммент выше.
Но в основном из-за высокой латентности I2P. Год назад я провел много тестов, вручную поднимая I2P туннель (как general TCP, так и два встречных stream UDP) и пуская через них трафик Торфона, а также тестового софта, определяющего латентность, jitter и нарушение порядка пакетов для UDP. В отличие от Tor, I2P вел себя весьма своеобразно, накапливая данные и выдавая их пачками. Возможно, из-за моих слабых компьютеров и Java, но скорее всего, и из-за слабых машин других клиентов (в I2P, в отличие от Tor, каждый участник в обязательном порядке ретранслирует чужой трафик). Возможно, с тех пор что-то изменилось. Вы сами можете проверить, вручную подняв туннель между двумя компьютерами и настроив Торфоны на соответствующие порты локали.
Кроме того, в I2P нет готового механизма для автоматической установки туннелей (в отличие от SOCKS в Tor). Я общался с zzz, он подтвердил, что необходим отдельный софт, работающий с SAM.
Как вариант. Хотелось бы увидеть криптографию на основе Keccak. На нем сразу реализуется всё что нужно: потоковый шифр с аутентификацией, хэш, PRNG. Это будет красиво и современно.
А асимметрику заменить на curve25519 (лучше на кривые большего размера, но для curve25519 есть готовый код, а для других нет).
комментариев: 9796 документов: 488 редакций: 5664
Не касаясь вашего конкретного случая, во многих режимах замена Random-IV на счётчик приводит к уязвимости, причём увидеть её можно только через формальный анализ. Детерминистичное шифрование в протоколах доказывается сложнее. Замены рэндомных частей на детерминистику обычно не являются простыми и выглядят контритуитивными.
Слишком амбициозно. Тот, кто сделает это первым и получит признание правильности реализации, рискует нечаянно отправить на свалку истории текущий подход OpenSSL и аналогов, если они не смогут своевременно принять этот код в свой проект.
Верить тому, как сделано в коде.
Все-таки первично то, что система должна работать. Как вы знаете, технических проблем более чем достаточно. Криптография – малая и сравнительно простая часть.
Прописная истина. Любая нелинейность образует сильный шифр при достаточном количестве раундов. Искусство состоит в том, чтобы сделать максимально эффективно.
В текущей реализации DHT не транспорт; только для поиска юзеров. Конечно, серверная архитектура была бы намного проще, но как только появляются сервера, сразу же возникают вопросы к их владельцам.
Функция ретрансляции траффика будет. В основном для решения проблемы NAT loopback и для того, чтобы было возможно работать при закрытых портах. Очевидное продолжение – сделать возможность нескольких хопов, то есть анонимизацию.
Интересно. Cпасибо за информацию.
комментариев: 393 документов: 4 редакций: 0
В презентации Кравчика наглядно показано, каким образом это проявляется на практике для CBC. (слайд 41 и далее). Со слов Шнайера, для CTR счетчик допустим. А Рогевей прямо указывает на допустимость счетчика для OCB.
По Keccak не знаком с темой, если ткнете носом, почитаю. Если есть работы с готовыми конкретными алгоритмами (как писалось в соседней теме – в рамочках), то можно попробовать аккуратно реализовать на С, используя референс-код Keccak и соблюдая все меры безопасности. Именно так я и сделал для curve25519 в своем текущем проекте офф-лайн OTR: на базе библиотеки ED25519 реализовал практически все IKE, которые обсуждались в этой теме. В начале, конечно, пришлось разобраться с элементарными операциями над элементами группы и поля и добавить недостающие, но теперь любая математика на кривой реализуется за полчаса. Целостность библиотеки проверяется по Бернштейновским векторам для NaCl (также слямзил код selftest EC25519 с TorProject), а каждая IKE – сотней согласований с рандомными ключами. Исходники ОС-независимы и компилируются любым С-компилятором. Выложу, как только допилю сам протокол.
Вот так вот.
И что характерно, так считает 99% программистов и 99.999% пользователей. А занимаются ею скучающие извращенцы вместо того, чтобы просто складывать пазлы.
Здесь и здесь уже упоминалась ссылка http://www.ecrypt.eu.org/tools. Вроде бы там всё есть.
комментариев: 9796 документов: 488 редакций: 5664
Сам как-то развлекался с одной конструкцией, которая давала тривиальный различитель за два подобранных открытых текста при любом числе раундов. Потому, что прошлёпал понятие ортоморфизма. Только выписав простейшими формулами, на уровне почти школьной алгебры, сократив лишнее по раундам, увидел фэйл. Есть ещё классическая работа: Two Rights Sometimes Make a Wrong. Там описана похожая ситуация, которая была с шифром Akellare, когда пытались взять лучшее от актуальных на тот момент двух алгоритмов (RC5 и IDEA) и скрестить их в одном, получив тотальный фэйл с возможностью практического взлома. И это только самые очевидные примеры того, что бывает, когда шифр проектируется без достаточной системы доказательств.
Keccak будет стандартизирован как SHA-3-256, SHA-3-512 и пр., но на первых порах не более того. Расширенные режимы Keccak и подобных Sponge-алгоритмов являются предметом теоретических исследований. И с момента создания алгоритма и уже после его публикации и победы в конкурсе. Пользоваться Sponge-конструкциями будет легко, но пусть сначала теоретики перепишут протоколы и договорятся о всех режимах использования, чтобы было какое-то соглашение по реализациям. Пока нет смысла использовать Keccak (ну разве что в режиме простого хэша) на практике из-за непроработанности его применения.
комментариев: 393 документов: 4 редакций: 0
Просмотрел информацию по Keccack. Действительно, конструкция Sponge доступна для разработчика, и нашлось несколько хороших С-реализаций. В принципе, нет никакой сложности реализовать в коде однопроходное аутентифицированное шифрование на дуплексном Sponge и SPRNG под конкретный проект. Но полностью согласен, что, учитывая массу режимов (соотношения с/r, размер блока) и возможных вариантов реализации (взять тот же паддинг), получится абсолютно нестандартный эксклюзив. Поиск уже существующих реализаций шифрования не дал результатов. Но в плане эксперимента можно попробовать как вариант. Все же я больше склоняюсь к Blake2/Salsa20.