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

ZAS Communicator


ZAS Communicator Opensource Project: secure voice, file transfer and text chat.


http://www.zas-comm.ru


Комментарии, советы, предложения?


 
На страницу: 1, 2, 3, 4, 5, ... , 8, 9, 10, 11, 12 След.
Комментарии
— gegel (07/03/2014 00:37, исправлен 07/03/2014 00:39)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0

Если Вас не затруднит, опишите поподробнее этот момент:


В качестве алгоритма асимметричной криптографии используется обмен по методу Диффи Хеллмана (в варианте Эль-Гамаля).
Числа, используемые в обмене Диффи Хеллмана, защищены от атак типа "человек в середине" c помощью электронной подписи. Подпись использует 256-битный хеш от параметров Диффи Хеллмана.

Анализировать код пока нет времени, но хочу понять:
– как происходит первичный DH-обмен и из чего выводится общий секрет?
– какие параметры подписываются, какой алгоритм подписи используется?


Я к тому веду, что как бы Вы не повторили ошибку раннего OTR (возможность UKS-атаки). Это конечно, мелочь на общем фоне реализации, но все же.


Каждый пакет данных содержит 64-битный порядковый номер, 32-битную длину, поле данных произвольной длины, и 32-битный код (MIC)

Мне просто по человечески интересно, почему Вы так распределили размер полей? Ведь чем-то руководствовались же?


Неужели длина пакета может потребовать 32 бита? Неужели есть смысл передавать полный порядковый номер? Ведь достаточно передать short, а затем развернуть его до уникального long long на стороне получателя (посмотрите, как сделано Циммерманном в PGPFone). И, с другой сторны, неужели достаточно 32-битного MAC для декларируемого Вами более чем 128-битного уровня безопасности (судя по размеру DH-ключей)?

— ZAS (07/03/2014 20:25)   <#>
Вызывающая сторона предлагает свой прайм P, генератор g, и число X = (g^x) mod P; с подписью от (g,X,p).
Отвечающая сторона отвечает 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
— gegel (09/03/2014 12:53, исправлен 09/03/2014 13:08)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0
с подписью от (g,Y,p)

Собственно, так и ожидалось. Просмотрите fileРаздел 3.1 и fileРаздел 2.2 работ по OTR и не наступайте на те же грабли.


32 бита мало. Значит, 64 бита.

На будущее: скачайте fileисходники PGPFone и посмотрите файл:
PGPfone21-win.zip\PGPfone\src\common\CPFPackets.cpp
а именно: процедуры SendPacket (line 697) и GetPacket (line 829).
Вполне достаточно включать в пакет 16-битовый счетчик и на принимающей стороне восстановить 64-битовое исходное значение.


32-битная длина – тоже имелась в виду отправка файлов

Так это тоже счетчик отправленных байт? Но зачем второй? Или все же длина UDP-пакета? Но она ограничена и вполне вписывается в short. Для TCP длина пакета вообще неактуальна, т.к. все равно их лопатит алгоритм Нагля – и там же поток. Непонятно...


32-битный MAC – более чем достаточно

В принципе, если брать данную конкретную реализацию и не учитывать возможности атакующего в стандартных моделях, то, наверное, да. Тем более, что малый интервал между голосовыми пакетами (20 mS) в перерасчете, скажем, на год, эквивалентен еще 27 битам стойкости против брутфорса. Но такой подход сильно нервирует публику.
Где-то у Шнайера было замечание, что в случае VOIP собственно сам голос является аутентификатором (ведь, сверяя список слов, им же и пользуются для обнаружения MitM). В нативном PGPFone из этих соображений вообще нет никакой аутентификации голосовых пакетов. Но это ни в коей мере не относится к чату и к передаче файлов.


PS: и, ради Бога, по возможности прикрутите хотя-бы опционно нормальное шифрование и хеши. Если не доверяете финалистам AES и вариантам SHA, используйте что-то изз модерна, например, Бернштейновские Salsa20 и Blake2 отсюда и PRNG отсюда, а то как-то стремно пользоваться.

— Reizer (09/03/2014 18:20)   <#>
Змеиное масло.
— ZAS (09/03/2014 21:46)   <#>
Все нормально. Cмотрим diffie_hellman.cpp:

* В подписи, кроме 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
— Гость (10/03/2014 04:34)   <#>

Перестраховочное крипто? Уже проходили, спасибо.

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

Вы хоть знаете, что такое каскады?

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

Наконц, вся суть в этих словах:

Наконец, если построят все варианты моделей каскадов, как у нас уже ранее обсуждалось, в рамках всех формальных моделей PRP/PRF-идеальной безопаности, то вместо каскада станет ясно, как создать очередной более стойкий шифр. Его и создадут, когда придёт время, а не потому что кому-то "хочется здесь и сейчас" — это не рынок в духе "любой каприз за ваши деньги". Специалисту непонятно, что даёт хоть десятерной каскад, кроме ощущения мнимой крутости. Есть единственная информационно-стойкая модель построения каскадов, когда разными шифрами шифруются разные куски гаммы одноразового блокнота. Откуда косвенно следует, что все остальные модели могут быть хуже или лучше друг друга, но не могут быть лучше этого предельного случая.


Надо так. Вам не понять. А TOR'а вообще нет, есть Tor.


Ссылки на каскады хорошо видно? Срач по ним, значит, тоже. Второго срача не будет. Топик прикроют, а все дальнейшие посты с рекламой вашего говноподелия будут отправляться сюда.
— gegel (10/03/2014 14:02)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0
с подписью от (g,X,p).


В подписи, кроме DH параметров, содержится собcтвенное ID и ID корреспондента.


Действительно, ИД корреспондента препятствует UKS. Но какому из утверждений верить? Не повторяйте моей ошибки – сделайте подробнейшее описание протокола, вынесите на обсуждение и не игнорируйте ни одного замечания. Больше коррекции – больше надежность.

сделать сильный криптоалгоритм, зная основы, не составляет труда.

No comments. После таких заявлений вы отгоните даже самых толерантных юзеров.

а раз так – нет смысла в новомодных изысках

Ладно, тестируйте пока. Если получится прилично с DHT-транспортом, я форкну и сам прикручу, не проблема.

Однако почему TOR а не I2P?


Во первых, см. коммент выше.
Но в основном из-за высокой латентности I2P. Год назад я провел много тестов, вручную поднимая I2P туннель (как general TCP, так и два встречных stream UDP) и пуская через них трафик Торфона, а также тестового софта, определяющего латентность, jitter и нарушение порядка пакетов для UDP. В отличие от Tor, I2P вел себя весьма своеобразно, накапливая данные и выдавая их пачками. Возможно, из-за моих слабых компьютеров и Java, но скорее всего, и из-за слабых машин других клиентов (в I2P, в отличие от Tor, каждый участник в обязательном порядке ретранслирует чужой трафик). Возможно, с тех пор что-то изменилось. Вы сами можете проверить, вручную подняв туннель между двумя компьютерами и настроив Торфоны на соответствующие порты локали.
Кроме того, в I2P нет готового механизма для автоматической установки туннелей (в отличие от SOCKS в Tor). Я общался с zzz, он подтвердил, что необходим отдельный софт, работающий с SAM.
— Гость (10/03/2014 15:24)   <#>
игнорируйте ни одного замечания
Поц игнорирует не то что бревно в глазу, а целый лесовоз. Какие к черту замечания, он никого кроме себя не слышит.

Ладно, тестируйте пока. Если получится прилично с DHT-транспортом, я форкну и сам прикручу, не проблема.
Как вариант. Хотелось бы увидеть криптографию на основе Keccak. На нем сразу реализуется всё что нужно: потоковый шифр с аутентификацией, хэш, PRNG. Это будет красиво и современно.
А асимметрику заменить на curve25519 (лучше на кривые большего размера, но для curve25519 есть готовый код, а для других нет).
— unknown (10/03/2014 16:38)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
2 /comment77362:
Не касаясь вашего конкретного случая, во многих режимах замена Random-IV на счётчик приводит к уязвимости, причём увидеть её можно только через формальный анализ. Детерминистичное шифрование в протоколах доказывается сложнее. Замены рэндомных частей на детерминистику обычно не являются простыми и выглядят контритуитивными.

Хотелось бы увидеть криптографию на основе Keccak. На нем сразу реализуется всё что нужно: потоковый шифр с аутентификацией, хэш, PRNG. Это будет красиво и современно.

Слишком амбициозно. Тот, кто сделает это первым и получит признание правильности реализации, рискует нечаянно отправить на свалку истории текущий подход OpenSSL и аналогов, если они не смогут своевременно принять этот код в свой проект.
— ZAS (10/03/2014 22:51)   <#>
В подписи, кроме DH параметров, содержится собcтвенное ID и ID корреспондента.

Действительно, ИД корреспондента препятствует UKS. Но какому из утверждений верить?


Верить тому, как сделано в коде.

Не повторяйте моей ошибки – сделайте подробнейшее описание протокола, вынесите на обсуждение и не игнорируйте ни одного замечания. Больше коррекции – больше надежность.


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

сделать сильный криптоалгоритм, зная основы, не составляет труда.
No comments. После таких заявлений вы отгоните даже самых толерантных юзеров.

Прописная истина. Любая нелинейность образует сильный шифр при достаточном количестве раундов. Искусство состоит в том, чтобы сделать максимально эффективно.


Ладно, тестируйте пока. Если получится прилично с DHT-транспортом, я форкну и сам прикручу, не проблема.


В текущей реализации DHT не транспорт; только для поиска юзеров. Конечно, серверная архитектура была бы намного проще, но как только появляются сервера, сразу же возникают вопросы к их владельцам.
Функция ретрансляции траффика будет. В основном для решения проблемы NAT loopback и для того, чтобы было возможно работать при закрытых портах. Очевидное продолжение – сделать возможность нескольких хопов, то есть анонимизацию.


Однако почему TOR а не I2P?
Во первых, см. коммент выше.
Но в основном из-за высокой латентности I2P. Год назад я провел много тестов, вручную поднимая I2P туннель (как general TCP, так и два встречных stream UDP) и пуская через них трафик Торфона, а также тестового софта, определяющего латентность, jitter и нарушение порядка пакетов для UDP. В отличие от Tor, I2P вел себя весьма своеобразно, накапливая данные и выдавая их пачками. Возможно, из-за моих слабых компьютеров и Java, но скорее всего, и из-за слабых машин других клиентов (в I2P, в отличие от Tor, каждый участник в обязательном порядке ретранслирует чужой трафик). Возможно, с тех пор что-то изменилось. Вы сами можете проверить, вручную подняв туннель между двумя компьютерами и настроив Торфоны на соответствующие порты локали.
Кроме того, в I2P нет готового механизма для автоматической установки туннелей (в отличие от SOCKS в Tor). Я общался с zzz, он подтвердил, что необходим отдельный софт, работающий с SAM.


Интересно. Cпасибо за информацию.
— gegel (10/03/2014 22:52, исправлен 10/03/2014 23:01)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0
Не касаясь вашего конкретного случая, во многих режимах замена Random-IV на счётчик приводит к уязвимости, причём увидеть её можно только через формальный анализ.

В презентации Кравчика наглядно показано, каким образом это проявляется на практике для CBC. (fileслайд 41 и далее). Со слов Шнайера, для CTR счетчик допустим. А Рогевей прямо указывает на допустимость счетчика для OCB.


Хотелось бы увидеть криптографию на основе Keccak

А асимметрику заменить на curve25519

По Keccak не знаком с темой, если ткнете носом, почитаю. Если есть работы с готовыми конкретными алгоритмами (как писалось в соседней теме – в рамочках), то можно попробовать аккуратно реализовать на С, используя референс-код Keccak и соблюдая все меры безопасности. Именно так я и сделал для curve25519 в своем текущем проекте офф-лайн OTR: на базе библиотеки ED25519 реализовал практически все IKE, которые обсуждались в этой теме. В начале, конечно, пришлось разобраться с элементарными операциями над элементами группы и поля и добавить недостающие, но теперь любая математика на кривой реализуется за полчаса. Целостность библиотеки проверяется по Бернштейновским векторам для NaCl (также слямзил код selftest EC25519 с TorProject), а каждая IKE – сотней согласований с рандомными ключами. Исходники ОС-независимы и компилируются любым С-компилятором. Выложу, как только допилю сам протокол.


Криптография – малая и сравнительно простая часть.

Вот так вот.
И что характерно, так считает 99% программистов и 99.999% пользователей. А занимаются ею скучающие извращенцы вместо того, чтобы просто складывать пазлы.

— Гость (11/03/2014 03:11)   <#>

Здесь и здесь уже упоминалась ссылка http://www.ecrypt.eu.org/tools. Вроде бы там всё есть.
— Гость (11/03/2014 08:52)   <#>
Прописная истина. Любая нелинейность образует сильный шифр при достаточном количестве раундов.
Доказать сможете? Такие заявления без доказательств – верный признак симптома Даннинга — Крюгера.
— unknown (11/03/2014 11:33)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Сам как-то развлекался с одной конструкцией, которая давала тривиальный различитель за два подобранных открытых текста при любом числе раундов. Потому, что прошлёпал понятие ортоморфизма. Только выписав простейшими формулами, на уровне почти школьной алгебры, сократив лишнее по раундам, увидел фэйл. Есть ещё классическая работа: fileTwo Rights Sometimes Make a Wrong. Там описана похожая ситуация, которая была с шифром Akellare, когда пытались взять лучшее от актуальных на тот момент двух алгоритмов (RC5 и IDEA) и скрестить их в одном, получив тотальный фэйл с возможностью практического взлома. И это только самые очевидные примеры того, что бывает, когда шифр проектируется без достаточной системы доказательств.


Keccak будет стандартизирован как SHA-3-256, SHA-3-512 и пр., но на первых порах не более того. Расширенные режимы Keccak и подобных Sponge-алгоритмов являются предметом теоретических исследований. И с момента создания алгоритма и уже после его публикации и победы в конкурсе. Пользоваться Sponge-конструкциями будет легко, но пусть сначала теоретики перепишут протоколы и договорятся о всех режимах использования, чтобы было какое-то соглашение по реализациям. Пока нет смысла использовать Keccak (ну разве что в режиме простого хэша) на практике из-за непроработанности его применения.
— gegel (12/03/2014 02:50, исправлен 12/03/2014 02:59)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0
Пользоваться Sponge-конструкциями будет легко

Просмотрел информацию по Keccack. Действительно, конструкция Sponge доступна для разработчика, и нашлось несколько хороших С-реализаций. В принципе, нет никакой сложности реализовать в коде fileоднопроходное аутентифицированное шифрование на дуплексном Sponge и fileSPRNG под конкретный проект. Но полностью согласен, что, учитывая массу режимов (соотношения с/r, размер блока) и возможных вариантов реализации (взять тот же паддинг), получится абсолютно нестандартный эксклюзив. Поиск уже существующих реализаций шифрования не дал результатов. Но в плане эксперимента можно попробовать как вариант. Все же я больше склоняюсь к Blake2/Salsa20.

На страницу: 1, 2, 3, 4, 5, ... , 8, 9, 10, 11, 12 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3