ZAS Communicator

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

http://www.zas-comm.ru

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

Комментарии

— SATtva (15/11/2013 09:51)
Что комментировать? По ссылке нет даже общего описания, не говоря о технической документации.

— gegel (15/11/2013 15:30, исправлен 15/11/2013 15:33)

Заменил users.xml на ваш новый, запустил, разрешил в брандмауере, сгенерировал ключ ОК.
Но Bootstrap не выполняется, причем абсолютно никакой сетевой активности при этом не наблюдается (контролирую весь трафик машины внешним снифером). Что не так делаю?

И еще вопросы:
Откуда взят DH-прайм?
Откуда исходник PRG?
Накапливается ли энтропия в процессе работы программы? Если да, то какие источники?
Чем собирали исходники (версия VC)?

— ZAS (15/11/2013 17:51)
Ищем единомышленников
Пишите письма
zas@zas-comm.ru

— ZAS (15/11/2013 17:57)

>Но Bootstrap не выполняется,

Поднимите свой бутстрап

> Откуда взят DH-прайм?

Праймы сгенерены. Можно добавлять.

> Откуда исходник PRG?

Нравится?

> Накапливается ли энтропия в процессе работы программы?

> Если да, то какие источники?

Да. Из трафика.

> Чем собирали исходники (версия VC)?

VS12

— gegel (15/11/2013 20:22, исправлен 15/11/2013 20:37)

Ищем единомышленников

Можете в том числе и меня считать таковым :)

Поднимите свой бутстрап

Повторюсь:

абсолютно никакой сетевой активности при этом не наблюдается

В том числе как udp-пакетов, так и tcp-syn-пакетов (контролирую снифером). Так что хоть чужой, хоть свой – все равно не понятно. Ладно, с этим потом разберусь, в т.ч. по исходникам.

Праймы сгенерены.

Посмотрите Циммермановкую доку на PGPFone^[link1] со стр.72, о генерации прайма по David
Kravitz (NIST). Иожет, оно и out-of-date сейчас, но все ж лучше, чем просто

Праймы сгенерены.

А то как бы не вышло как с Dual EC DRBG...

Нравится?

Пока не анализировал. Но несерьезное отношение к PRG всегда чревато. Я, конечно, не специалист в криптографии, но не совсем понятно, как трафик, изначально доступный злоумышленнику, можно использовать в качестве источника энтропии для PRG? Или, возможно, я что-то неверно понял?

— Гость (16/11/2013 17:00)

> как трафик, изначально доступный злоумышленнику, можно использовать в качестве источника энтропии для PRG?

Может, он имеет в виду генерацию случайных чисел из секретных для противника prime numbers. С ними вроде как всё плохо и непрактично, а из тех, что неплохие, известен только BBS^[link2]. Ну, и, наверно, он нам хочет сказать, что prime numbers можно поменять на свои.

— gegel (16/11/2013 20:00)
Нет, о Блюм-Блюм_Шуб речь не идет, не тот случай...

Я посмотрел код: для добавления энтропии в PRG используется функция криптопровайдера виндоус CryptGenRandom. Вызывается она на старте программы, при генерации ключа пользователя (многократно), так и перед каждой установкой соединения и Diffie-Hellman (генерацией секрета). Сиды хранятся в файле, обновляемом в процессе работы программы. В тонкости работы PRG я не вникал, но он использует полином для добавления данных в пул и и генерирует rand, используя IDEA.
Вообщем, выглядит как обычно.

Что касается DH: действительно, праймы можно подгружать из файла (при этом проводится проверка по Miller_Rabin, рабочий прайм выбирается случайно из доступных.

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

— Гость (16/11/2013 21:26)

> не сами ж Вы это все писали, почему бы не указать ссылки на источники фрагментов кода

По-моему, каждый файл GPL/BSD/etc-исходника содержит ~~копирайтный~~ копилефтный материал в начале файла в комментариях. Этот материал однозначно указывает на происхождение исходника и его авторство. По крайней мере, я много раз такое видел. Если у автора этого нет, то что это значит? Он выпилил все копирайты?

— gegel (17/11/2013 01:54, исправлен 17/11/2013 01:57)

Вот и я о том же: выпилено подчистую даже с реализаций idea, diffie-hellman и bignum (см. исходники^[link3]) Но мне кажется, что не разработчиком, а до него: скорее всего, весь комплект взят с какого-то другого проекта, возможно, закрытого/коммерческого.
И хотя это ничуть не умаляет функционал проекта, но просто затрудняет анализ исходников.
Хотелось бы услышать коментарий непосредственно автора, а не промоутеров.

— Гость (17/11/2013 12:40)

> По ссылке нет даже общего описания, не говоря о технической документации.

Так это же ЗАС^[link4]! Техническая документация на ЗАС^[link5] выдаётся только тем, кому положено.

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

Другим правительствам будете продавать решение или только в РФ?

— ZAS (21/11/2013 01:23)
ZAS Communicator opensource Project: secure voice and text chat

http://www.zas-comm.ru

Выпущена бета версия 0.2
Новый интерфейс
Исправлено много багов

Смотрите, тестируйте, присылайте пожелания, логи и баг репорты.

zas@zas-comm.ru

— Гость (21/11/2013 02:56)
Жестко содержательный сайт ))

— SATtva (21/11/2013 07:22)

* Fixed entropy collection

Вангую, что не в последний раз.

— ressa (21/11/2013 11:39)
Слушай, ZAS, а ты не мог бы чуть больше подробностей изложить по поводу своего творения?)
Ну я так понял, что только под винду, да? О какой приватности тогда идет речь? Какие планы дальнейшие и тд.
А то так ну совсем не интересно.

— ZAS (21/11/2013 20:18)
Скоро будет версия под Linux

Планов и дел много. Хороших и разных.
Кому интересно и кто хочет участвовать, пишите в личку.

zas.zas-comm.ru

— Гость (21/11/2013 23:12)

> Кому интересно и кто хочет участвовать, пишите в личку.

Тут приветствуют открытую модель разработки, а вы себя ведёте как убунта^[link6].

сделали бы всё стандартно, как остальные. … с открытой моделью разработки, публикацией роадмапов, теоретических работ, с гитом, тикетами и пр. †^[link7]

— Гость (21/11/2013 23:19)
http://www.zas-comm.ru/ZAS.asc ← почему бы не загрузить этот ключ к себе в профиль на pgpru, раз всё равно подписываетесь? Заодно и ник бы себе забили.

— ressa (22/11/2013 10:22)
Выложи исходники на GIT, напиши о планах на будущее.
Будет версия под Linux – с радостью протестирую.

— ZAS (25/12/2013 00:42)
http:\\www.zas-comm.ru

Выложен ZAS Communicator Beta 1.0

* Новый интерфейс
* Сильная криптография
* Телефонная связь, текстовый чат, передача файлов
* Прилагается описание программы и используемых протоколов

Присылайте баги, замечания и предложения.
Будем рады предложениям о сотрудничестве.

zas@zas-comm.ru

— Гость (25/12/2013 05:16)
Во-первых, /comment73707^[link8]. Во-вторых, не плодите по новому топику на каждый чих [уже есть /Форум/ПрактическаяБезопасность/ZASCommunicator^[link9]]. В-третьих, вы так и не ответили откуда у вас взят исходник PRG^[link10]. Есть, что сказать — пишите на форум, никто вам в личку стучать не будет, а то выглядите как те деятели, которые задают вопрос, оставляют мыло и пишут «отвечайте на mail», причём в сам топик после этого могут вообще не заглядывать.

— unknown (25/12/2013 09:26)
Ещё и ссылку на свой сайт криво поставили :)

— SATtva (25/12/2013 09:35)

http:\\

Виндоуз головного мозга.

— ZAS (28/12/2013 23:24)
Kод свой, кроме speex и upnp.

"Ничто не cтоит так дешево, и не ценится так дорого, как вежливость"
© Сервантес

— Гость (29/12/2013 00:12)
Ничто не бесит так сильно, как постоянное намеренное игнорирование правил поведения на форуме несмотря на неоднократно высказанные замечания.

— ZAS (28/01/2014 23:51)
ZAS Communicator Beta 1.3 (Win32)
Выложена на даунлод

http://www.zas-comm.ru

* Первая реально работающая версия
* Сеть поднялась
* Работают все опции: звук, чат, передача файлов

Пробуйте, смотрите исходники, присылайте баги и предложения

zas.zas-comm.ru

— gegel (29/01/2014 01:28)

Первая реально работающая версия

А я то думал, почему предыдущие у меня реально не работали :)

— Гость (29/01/2014 04:46)
Читаю и фигею.

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

Это хорошо, но сложно доказуемо. Были ли попытки хоть как-то доказать такое свойство? Или хотя-бы доказать, что ваша конструкция не слабее чем любой их составляющих ее алгоритмов по отдельности?

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

Абсолютно бредовый критерий. Вы отказываетесь от самых изученных алгоритмов в пользу чего-то полуподвального и малоизвестного. Принцип неуловимого Джо, да?

На основе вышеизложенных соображений, мы взяли за основу алгоритмы IDEA, XTEA, XXTEA

А ничего, что все три не удовлетворяют современным требованиям к безопасности, а последние два могут считаться взломанными? 64 битный блок резко снижает криптостойкость каскадной конструкции, что было доказано, но авторы это не читали. Наверно чукча не читатель, чукча писатель.
Для шифрования потока я бы выбрал каскад Aes256-CTR -> Serpent256-CTR -> Keccak.

Также используется самодельный блочный шифр нелинейной подстановки.

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

В каждой коммуникационной сессии простое число, используемое в качестве модуля, выбирается cлучайным образом из таблицы из 360 заранее рассчитаных безопасных простых чисел размером 4096 бит.

Это что-нибудь дает? Или запутывание ради запутывания? Типа чем больше накручу, тем лучше криптостойкость.

Таблица простых чисел сгенерена c помощью главного генератора случайных чисел. Таким образом, простые числа не имеют какой-либо внутренней структуры.

Что-за "главный генератор"? Где что сгенерирована? Я так понял, таблица сгенерирована у вас и зашита в код, тогда как вы докажете отсутствие закладок?

Главная хеш функция (COLLAPSE)

Этот раздел, вообще какая-то шифрпанковская муть. Почему ваша хэш фуненкция не представлена на конкурсе sha3, раз она такая замечательная?

Поточный шифр (KEYSTREAM)

Поточный шифр использует алгоритм IDEA для генерации псевдослучайных чисел, и XXTEA для модификации ключа IDEA. Нелинейно-конгруэнтный генератор со 128-битным состоянием используется как источник для IDEA в режиме счетчика и как ключ для xеш функции модификации ключа на основе алгоритма XXTEA.

Я фигею, дорогие товарищи. Нормальных потоковых режимов не используем, изобретаем какую-то мутную херь. Где ваши 100500 диссертаций по этой теме и где признание ведущих собаководов, что ваш подход хотя-бы не хуже общепринятого?

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

32 битная криптостойкость аутентификации, это замечательно. Редкостная дичь.

Основной генератор случайных чисел

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

Как я и думал, тут тоже какая-то самопальная дичь. Скорее всего криптостойкостью даже не пахнет.

Я еще удивлялся, почему unknown так резко выступает против шифрпанка. Я сам шифрпанк, но умеренный. Здесь же я вижу столь дикую дичь, что хочется взять свой топор и пойти учить авторов уму-разуму.

— Гость (29/01/2014 06:23)

Опыт показывает, что размер ключа 4096 бит обеспечивает безопасность.

Чей опыт, как измеряли безопасность?

Развитие квантовых компьютеров требует применения эллиптических кривых в больших полях (>1000 битов). Что практически сводит на нет преимущества эллиптической криптографии в скорости работы и в размере ключа

Интересно...

Широкораспространенные криптографические библиотеки, такие как OpenSSL, Crypto++, GPG и пр. не используются по ряду технических причин, из-за сомнений в безопасности примененных в них процедур, а также по соображениям копирайта.

Супер.

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

Оказывается, сделать алгоритм более стойким — это очень просто. И чего там теоретики изобретают какие-то дурацкие конструкции? Увеличил число циклов^[link11] — и всё на том^[link12].

Внутренняя структура PKF сделана с учетом того, чтобы усложнить аппаратную реализацию на FPGA.

Lyra^[link13], Catena^[link14] хуже?

Применить самодельный блочный шифр.

Втопку.

>> Критическая слабость любого одного из алгоритмов не должна приводить к потере безопасности.

> Это хорошо, но сложно доказуемо. Были ли попытки хоть как-то доказать такое свойство? Или хотя-бы доказать, что ваша конструкция не слабее чем любой их составляющих ее алгоритмов по отдельности?

Да, доказать хотя бы так^[link15] — реально?

> Где ваши 100500 диссертаций по этой теме и где признание ведущих собаководов, что ваш подход хотя-бы не хуже общепринятого?

«Академики» — дураки и старпёры, ничего не умеющие и ничего не добившиеся в жизни, которые сочиняют никому ненужную бумажную бредятину. Каждый местный Гость это знает.

> Я еще удивлялся, почему unknown так резко выступает против шифрпанка.

Выступает, старается быть ближе к «академикам», но по образу мышления и имеющемуся бэкграунуду он всё равно ближе к шифрпанкам-любителям, чем к академикам, IMHO. К тому же, он, как и многие тут, любит экспериментировать и всякий самопал — тоже черта любителя. :)

— unknown (29/01/2014 09:51)
Эти ваши XX-аналоги^[link16] TEA скоро превратятся^[link17] в нечто, напоминающее RC4 по уровню обоснованности стойкости. И столь любимое программерами, далёкими от крипто — никаких там полиномов, полей, специально проектированных блоков в набор операций самим превращать не надо и в особенности разных реализаций тоже вникать незачем. При создании уже подобрали набор логических операций, вроде как нелинейных и удобных для того, чтобы закодить всем на радость.

— ZAS (31/01/2014 04:44)
Очень рад, что вам понравилось. Кстати, текущая версия 1.31; многое поправлено в сетевой части.

Почему крипто сделано не совсем так как у всех – тема длинная и интересная. Конкретные вопросы?

По существу дела: нашли баг/эксплойт/слабое место?

— Гость (31/01/2014 06:59)

Почему крипто сделано не совсем так как у всех

Потому что вы безграмотные шифрпанки отрицающие научный подход.

Конкретные вопросы?

Нет, и так всё ясно.

По существу дела: нашли баг/эксплойт/слабое место?

Вся ваша криптография – одно сплошное слабое место. Прям всё сплошняком, от начала и до конца. Слабый дизайн, слабые алгоритмы, отсутствует научный подход. Всё печально.
Любое новое изобретение в криптографии, требует доказывания безопасности, на что уходят годы и десятилетия труда всего академического сообщества. Вы – даже не пытались ничего доказывать, нахуевертили какой-то шняги и выставляете панацеей. Смотреть ваш код, тем более чего-то в нем анализировать, никому не интересно, по одному описанию понятно что втопку.

— ZAS (31/01/2014 22:21)
Ругань, общие рассуждения и, как обычно, ни слова по делу.
Если вы действительно специалист, то могли бы помочь.
Это было бы полезно для всех.

— Гость (01/02/2014 00:06)
Хотите сделать что-то стоящее – не считайте себя самыми умными и используйте существующие наработки открытого научного сообщества. И вот либо прислушайтесь к общим словам, которые вам тут говорят, либо ищите советчиков в другом месте, потому что ваш формат разработки по многим критериям не укладывается рамки того, что здесь считается достойным внимания.

— Гость (01/02/2014 01:06)

По существу дела: нашли баг/эксплойт/слабое место?

— Я в гараже собрал самолёт, он летает. Садитесь, прокачу.
— Подождите, а как же инженерная документация, газодинамические расчёты, обоснования, испытания, проверка специалистами, сертификация, пробные полёты? Мы рискуем жизнью, садясь в ваш гроболёт!
— По существу дела: нашли баг/слабое место/выход на внеэксплуатационный режим/потерю управляемости? Можете сесть и показать, в каком месте и что надо сделать, чтобы моя суперразработка носом в землю стукнулась?

Ругань, общие рассуждения и, как обычно, ни слова по делу.
Если вы действительно специалист, то могли бы помочь.

Не в чем там помогать, там надо выкинуть всё и начинать с нуля, заменив разработчика, сделав внятную документацию, обоснования и дорожную карту проекта. Вы своими заявлениями полностью себя дискредитировали, теперь никто и никогда, по крайней мере, здесь, не будет доверять ни одному из ваших проектов. Это ханаанский бальзам^[link18], как минимум, по симптомам №1, 2, 4, 7 и эквиваленту 9-го, а ханаанского бальзама тут берегутся^[link19]. Есть FAQ^[link20], но я сомневаюсь, что вам он поможет, он всё-таки для думающих людей писался.

Продолжайте активнее вбрасывать в те аудитории, что легко поведутся, для pgpru это толсто. У вас же неплохо получалось:

Продолжайте в том же духе. На античате вроде тоже видел ваш топик или показалось? Даже там снесли поди уже.

— ZAS (03/02/2014 18:47)
...а караван идет :)

Oчередной Win32 билд 1.32 (250):
http://www.zas-comm.ru/downloads.html.ru

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

Смотрите, проверяйте, присылайте баги и предложения.

zas@zas-comm.ru

— SATtva (03/02/2014 19:27)

Смотрите, проверяйте, присылайте баги и предложения.

Вам уже всё написали.

— gegel (03/02/2014 20:23, исправлен 03/02/2014 20:23)

Чат теперь разноцветный

Ну наконец то! Этого все тут так ждали! Надо бы еще смайликов...

— ЗАЗ (03/02/2014 21:50)

>Ну наконец то! Этого все тут так ждали!

Вы как бы стебетесь? Разве не ждали? Кому охота жить серым и унылым чатом?

— ZASranets (04/02/2014 00:17)

>Вам уже всё написали.

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

"Сережа", как хобби сойдет. Вы знаете, что вы сделали не так, как надо бы, знаете, как делают другие. Не знаете, подсмотрите, поучитесь. Но это время, труд и нервы. И нет смайликов. Хотя их можно нарисовать в любой самый суровый проект.
~~Теперь всё.~~ Но и это ещё не всё! ©

— ZAS (04/02/2014 16:31)
Честно говоря, удивлен.
Мы делаем хорошее, полезное и нужное дело. И не просим ничего взамен.
Так нет же, кому-то показалось некошерным. Не соответствует канонам религии.
В общем, много разных общих слов. И, как обычно, ни одного аргумента по существу.

Жаль. Я надеялся найти если не единомышленников, то хотя бы взаимопонимание.

zas@zas-comm.ru

— Гость (04/02/2014 16:40)
Вы пишите, пишите. Вы тут всем приносите радость и веселье. Вас обязательно будут приводить в пример.

— Гость (04/02/2014 16:47)

>И, как обычно, ни одного аргумента по существу.

Были аргументы^[link23]
Если пропустить тон и форму подачи, то вопросы то были заданы по существу.
Действительно жаль, что вы не читаете ответы.

— SATtva (04/02/2014 17:08)

Мы делаем хорошее, полезное и нужное дело.

Вы делаете ханаанский бальзам и даёте пользователям, не разбирающимся глубоко в данной теме, ложное чувство защищённости^[link24]. Плохая криптография хуже, чем никакой.

Так нет же, кому-то показалось некошерным. Не соответствует канонам религии.

Сделайте проект высотного здания, положив ~~прибор~~ аргумент на ~~каноны религии~~ СНиПы. Интересно, как на Вас посмотрят строители и потенциальные жильцы.

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

— ZAS (04/03/2014 20:26)
Новый билд: ZAS Communicator Beta 1.4 (260) (March 2 2014):

http://www.zas-comm.ru

* Много новых опций и возможностей
* Пофиксено багов

Для пожеланий, предложений и баг-репортов: zas@zas-comm.ru

— Гость (04/03/2014 21:25)
Горшочек, не вари! ©

— gegel (07/03/2014 00:37, исправлен 07/03/2014 00:39)

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

В качестве алгоритма асимметричной криптографии используется обмен по методу Диффи Хеллмана (в варианте Эль-Гамаля).
Числа, используемые в обмене Диффи Хеллмана, защищены от атак типа "человек в середине" 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)

с подписью от (g,Y,p)

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

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

На будущее: скачайте исходники PGPFone^[link27] и посмотрите файл:
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 отсюда^[link28] и PRNG отсюда^[link29], а то как-то стремно пользоваться.

— 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)

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

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

Перестраховочное крипто^[link30]? Уже^[link12] проходили^[link11], спасибо.

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

Вы хоть знаете, что^[link15] такое^[link32] каскады?

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

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

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

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

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

>...A ламеры пусть лечат собственную импотенцию повторением чужих мантр.

Ссылки на каскады хорошо видно? Срач по ним, значит, тоже. Второго срача не будет. Топик прикроют, а все дальнейшие посты с рекламой вашего говноподелия будут отправляться сюда^[link37].

— gegel (10/03/2014 14:02)

с подписью от (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)
2 /comment77362^[link38]:

>16 или 64 битный счетчик. Cовершенно неважно. Нам не нужно уникальное число как IV для PRNG.

Не касаясь вашего конкретного случая, во многих режимах замена 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)

Не касаясь вашего конкретного случая, во многих режимах замена Random-IV на счётчик приводит к уязвимости, причём увидеть её можно только через формальный анализ.

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

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

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

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

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

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

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

> Если есть работы с готовыми конкретными алгоритмами (как писалось в соседней теме – в рамочках), то можно попробовать аккуратно реализовать на С, используя референс-код Keccak и соблюдая все меры безопасности.

Здесь^[link40] и здесь^[link41] уже упоминалась ссылка http://www.ecrypt.eu.org/tools. Вроде бы там всё есть.

— Гость (11/03/2014 08:52)

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

Доказать сможете? Такие заявления без доказательств – верный признак симптома Даннинга — Крюгера^[link42].

— unknown (11/03/2014 11:33)

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

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

>то можно попробовать аккуратно реализовать на С, используя референс-код Keccak и соблюдая все меры безопасности.

Keccak будет стандартизирован как SHA-3-256, SHA-3-512 и пр., но на первых порах не более того. Расширенные режимы Keccak и подобных Sponge-алгоритмов являются предметом теоретических исследований. И с момента создания алгоритма^[link44] и уже после его публикации и победы в конкурсе^[link45]. Пользоваться Sponge-конструкциями будет легко, но пусть сначала теоретики перепишут протоколы и договорятся о всех режимах использования, чтобы было какое-то соглашение по реализациям. Пока нет смысла использовать Keccak (ну разве что в режиме простого хэша) на практике из-за непроработанности его применения.

— gegel (12/03/2014 02:50, исправлен 12/03/2014 02:59)

Пользоваться Sponge-конструкциями будет легко

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

— Гость (12/03/2014 06:51)

Blake2/Salsa20

Тогда лучше AES-256-CTR / SHA-512 / SHA-512-HMAC / SHA-512-HMAC-DRBG. Кто такие эти Blake2/Salsa20? Имеют ли они доказательную базу или опыт использования сопоставимые с AES/SHA2?

— unknown (12/03/2014 10:29, исправлен 12/03/2014 10:31)

>Blake2/Salsa20

Форсятся Бернштейном как быстродействующая и более устойчивая к утечкам по тайминг-каналам альтернатива существующей симметрике.

Если его эллиптика — весомая альтернатива, по крайней мере на фоне недостатков стандартов НИСТ, то в пользу его симметрики особых аргументов нет. Хотя горячие головы его симметрику даже в Tor хотели внести. Видимо за компанию с эллиптикой, на уровне аргументации «только, чтобы всё не как у НИСТа».

>Имеют ли они доказательную базу или опыт использования сопоставимые с AES/SHA2?

Нет.

— gegel (12/03/2014 12:55)
Все же Blake – финалист SHA3, точно так же, как и недавно Keccack.

— unknown (12/03/2014 15:46, исправлен 12/03/2014 15:48)

Попутал Blake с Salsa и аналогами^[link48]. Blake2^[link49] — это к тому же послеконкурсная модификация изначального Blake.

— Гость (12/03/2014 20:01)
А что, Blake/Blake2 чем-то существенно лучше KeccaK? Или это опять уровень спекуляций?

— gegel (12/03/2014 21:43, исправлен 12/03/2014 21:43)

Попутал Blake с Salsa и аналогами

Я почему-то подумал, что соотношение между Blake2 и ChaCha (вариант Salsa20) то же, что и Keccack и симметричного шифрования на основе двойного Sponge. Но теперь не уверен в причинно-следственной связи: тут^[link49] сказано, что Blake2 спроектировано из СhaCha, а тут^[link50] показано, как ChaCha получен с Salsa20.
Но в любом случае, общность налицо.

— unknown (13/03/2014 09:53, исправлен 13/03/2014 16:23)

А что, Blake/Blake2 чем-то существенно лучше KeccaK? Или это опять уровень спекуляций?

Лично я могу только оценить, насколько тщательно и фундаментально авторы готовили свои работы. По конкурсу SHA-3 отметил для себя только Skein и Keccak. Команды практически этих же авторов готовили Twofish и Rijndael для AES. Это ничего не говорит напрямую о качестве самого алгоритма, только позволяет судить о качестве усилий по его разработке. Плюс, есть субъективные привычки к определённому стилю изложения со стороны читающих и изучающих работы по этой тематике. Так что да, на уровне спекуляций.

— ZAS (21/03/2014 19:20)
ZAS Communicator: версия 1.5 (278)

Работает очень прилично.

* Много новых опций в /Network, /User, /Privacy
* Win32/64 варианты. В x64 варианте арифметика с большими числами работает более чем в два раза быстрее
* Новый протокол установления соединения с PFS и deniability. Спасибо Von Gegel за идею. Старый протокол опционально поддерживается для совместимости.
* Чат сохраняется в файлы
* Есть стандартный инсталер/деинсталер. Бинарники тоже выложены, продвинутые пользователи могут просто заменить .exe и .dll файлы. Конфиги и ключи совместимы.
* Можно запускать несколько инстансов программы от имени разных identities.
* Пофиксено багов

Подключайтесь к сетке. Потестируем, как оно будет работать в большой системе.

zas@zas-comm.ru

— Гость (21/03/2014 20:38)

> Работает очень прилично.

Не ругается, не хамит, ведёт себя учтиво?

— gegel (21/03/2014 21:20)

Новый протокол установления соединения с PFS и deniability. Спасибо Von Gegel за идею.

Да не за что, хотя я абсолютно не пойму, за что спасибо: вроде как никаких идей напрямую я не высказывал. Очень хотелось бы увидеть хотя бы схематичное описание протокола, а также ваше понимание PFS и deniability применительно к этому проекту.

— ZAS (21/03/2014 22:46)
PFS: невозможность повторного вхождения на тех же данных. Чтобы обеспечить PFS, протокол должен состоять минимум из трех действий (можно обойтись двумя, если ввести дополнительные сущности типа привязки данных к абсолютному времени и/или запоминания предыдущих соединений; но это неудобно).

Deniability: Если Вася послал Пете бумажку, а Петя ее подписал, то Вася может доказать наличие транзакции с Петей. Если процедура к тому же видна со стороны третьим лицам, то они тоже могут доказать наличие транзакции. Если Вася написал бумажку, подписал ее и послал Пете, то эта бумажка доказывает только что ее написал Вася. Протокол установления соединения должен аутентифицировать стороны но не доказывать факта транзакции.

Пользователь идентифицируется своим ключом проверки подписи. Хеш ключа – ID пользователя в системе.

Протокол:

1: A->B: g,p, X = g^x mod p. A посылает В числа g,p,X
2: B->A: Y = g^y mod P, B вычисляет общий секрет и устанавливает ключ MAC и ключ шифрования. B посылает A число Y, а также в зашифрованном виде подпись от (g,p,X,Y) и ключ проверки подписи B.
3: A->B: A вычисляет общий секрет и устанавливает ключ MAC и ключ шифрования. A посылает B зашифрованную подпись A от (g,p,X,Y) и ключ проверки подписи A.

Далее обмен идет в шифрованном виде; поточный шифр единожды инициализирован и идет в направлении только вперед.
Шифр и MAC, разумеется, разные в направлении A->B и B->A.

Примерно так.

— gegel (22/03/2014 02:49, исправлен 22/03/2014 02:50)

Примерно так.

Это похоже на STS, я их уже столько перелопатил... Кравчик считает его небезопасным (стр. 36, слайды 80 и далее^[link51])
А почему бы вам не остановиться на доказуемо безопасном SIGMA (по аналогии с OTR)? См. по слайдам далее.
Если вы online, и нет ограничения на количество предварительных трансакций, то есть масса несложных и доказуемо стойких вариантов, это не проблема. Скопируйте, например, реализацию Sigma-R с OTR^[link52], и Вас никто не упрекнет.
Гораздо интереснее стоит вопрос с offline (например, почтой). Есть масса изощренных однопроходных вариантов с отрицаемостью (например, на базе эвристики Фиата-Шамира с заменой одностороннего хеширования на обратимый Эль-Гамаль, или вариант с одноразовыми подписями), но все они требуют сложной математики и передачи значительного количества ключевого материала, а поэтому без эллиптики в этих случаях не обойтись.
Ну и, раз у Вас шифропанковсий подход, обратите внимание на 3DH, реализованный в протоколе Axolotl^[link53]. Это близко к протоколу KEA+, просто и изящно, но без доказательств.

— ZAS (22/03/2014 03:53)

Это похоже на STS, я их уже столько перелопатил... Кравчик считает его небезопасным (fileстр. 36, слайды 80 и далее)

Не относится к нашему случаю.
Во-первых, по построению системы, хеш сертификата является identity. То есть E не может заявить себя как A.
Во-вторых, кроме шифрования, имеется MAC. Протокол не STS, а Sigma-I с шифрованием. По системным соображениям удобен вариант именно с тремя ходами.

обратите внимание на www3DH, реализованный в протоколе Axolotl. Это близко к протоколу KEA+, просто и изящно, но без доказательств.

Примерно так был сделан протокол в предыдущих версиях; для совместимости опционально поддерживается и сейчас. Проблема с authentication replay. Даже если противник не знает использованных эфемерных ключей, он все равно может дезорганизовывать протокольный стек, подсовывая запросы, которые выглядят как валидные.

— gegel (22/03/2014 15:28)

кроме шифрования, имеется MAC

Я просто не заметил, когда читал. Тогда вопрос снят. Sigma-l, действительно, оптимальный вариант в этом случае, т.к. нет смысла защищать id ответчика от активного атакующего. DHT сама выводит на peer по заданному id, поэтому id ответчика заранее известен инициатору. В свою очередь, id инициатора защищен от активного атакующего (подставного ответчика, контролирующего DHT).

Ну, раз уж пошла такая байда, то осмелюсь предложить заменить обычную DH на эллиптику. Ваш аргумент о квантовых ком'ютерах, ломающих эллиптику и бессильных против дискретных логарифмов, весьма странен. Ну, и набор праймов тоже не вносит никакой дополнительной стойкости в систему, скорее наоборот.
Посмотрите компактную библиотеку ED25519^[link54]: она легко компилируется в любой среде, имеет все необходимое в виде простых функций (ECDSA-подпись и DH-обмен ключами), обеспечивает 128-битный уровень защиты при размере ключей всего 256 бит. Таким образом, проход вашей Sigma не надо будет разбивать на куски: все войдет в один UDP-пакет. Сразу лишитесь кучи геморроя, и никто не будет упрекать: Curve25519 – это не NIST, Бернштейну можно доверять.
Если заинтересуетесь, я скину функцию конвертирования из формата Edvards в Mongomery, чтобы можно было сравнить с оригинальными Бернштейновскими тестовыми векторами для EC25519 и убедиться в коррекности реализации в вашем коде.

— ZAS (22/03/2014 19:49)

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

1. Эллиптика – патентное минное поле.
2. Для взлома ключа требуется количество кубитов порядка размера ключа, и для эллиптики, и для криптографии на числах. Трудность поддержания когерентности экспоненциальна количеству кубитов.

Ну, и набор праймов тоже не вносит никакой дополнительной стойкости в систему, скорее наоборот.

В смысле, нечестный юзер может взять плохой прайм и, тем самым, сделать переговоры видимыми третьей стороне?

Набор праймов: была мысль, что каждый юзер cгенерит личный прайм для DH и подписи, и этот прайм будет частью identity. Пришлось отказаться, т.к. генерация долгая процедура. Тем не менее возможность оставлена. Те, кто не доверяет дефалтовым праймам, могут использовать свои.

Посмотрите компактную библиотеку wwwED25519: она легко компилируется в любой среде, имеет все необходимое в виде простых функций (ECDSA-подпись и DH-обмен ключами), обеспечивает 128-битный уровень защиты при размере ключей всего 256 бит. Таким образом, проход вашей Sigma не надо будет разбивать на куски: все войдет в один UDP-пакет. Сразу лишитесь кучи геморроя, и никто не будет упрекать: Curve25519 – это не NIST, Бернштейну можно доверять.

Размер ключа – мелкая техническая проблема. Более существенны вычислительные затраты, которые велики для криптографии на числах.

Если заинтересуетесь, я скину функцию конвертирования из формата Edvards в Mongomery, чтобы можно было сравнить с оригинальными Бернштейновскими тестовыми векторами для EC25519 и убедиться в коррекности реализации в вашем коде.

Cпасибо за ссылки.
Сейчас придумывается протокол версии 2.0; чтобы можно было работать на закрытых портах и/или при нерабочем NAT loopback. Возможно, приделаем 512-битную эллиптику.

zas@zas-comm.ru

— unknown (23/03/2014 17:15, исправлен 23/03/2014 17:18)

>Эллиптика – патентное минное поле.

После принятия стандартов NIST — нет. Хотя, не помню, соранилась ли там заморочка, что можно использовать только или в проприетарном коде, или полностью свободном (BSD), но не в вирусно-свободном (GPL). А эллиптика от Бернштейна — тем более, изначально свободная, в ней точно никаких патентных заморочек нет.

>Размер ключа – мелкая техническая проблема. Более существенны вычислительные затраты, которые велики для криптографии на числах.

Они в пользу эллиптики и существенно. Вы там теоретическую часть прорабатывали вообще, или делали из того, что под руку подвернулось?

— SATtva (23/03/2014 17:51)

Более существенны вычислительные затраты, которые велики для криптографии на числах.

Они в пользу эллиптики и существенно.

Вангую, что автор имел в виду затраты на взлом с использованием КК.

— ZAS (23/03/2014 19:29)

>Эллиптика – патентное минное поле.

После принятия стандартов NIST — нет.

Заблуждение.
Патентов на эллиптику немеряно. Хороших и разных. Одна из целей стандартизации – заставить других пользоваться патентами.

Хотя, не помню, соранилась ли там заморочка, что можно использовать только или в проприетарном коде, или полностью свободном (BSD), но не в вирусно-свободном (GPL).

Кто угодно может выпустить что угодно под любым соглашением; что отнюдь не освобождает от патентов.

А эллиптика от Бернштейна — тем более, изначально свободная, в ней точно никаких патентных заморочек нет.

Подобные заявления имеют вес только в виде рекомендации от патентного юриста (даже не самого Бернштейна).

>Размер ключа – мелкая техническая проблема. Более существенны вычислительные затраты, которые велики для криптографии на числах.

Они в пользу эллиптики и существенно.

Именно.
Cейчас начальное вхождение в сеть занимает существенное время из-за необходимости много раз вычислять Диффи-Хеллмана и подпись на числах, это на PC. Что говорить о более слабых платформах, таких как PDA.

— SATtva (23/03/2014 19:49)

Патентов на эллиптику немеряно. Хороших и разных. Одна из целей стандартизации – заставить других пользоваться патентами.

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

In all of these cases, it is the implementation technique that is patented, not the prime or representation, and there are alternative, compatible implementation techniques that are not covered by the patents.
<...>
The patent issue for elliptic curve cryptosystems is the opposite of that for RSA and Diffie-Hellman, where the cryptosystems themselves have patents, but efficient implementation techniques often do not.

— Гость (23/03/2014 23:18)

> можно использовать только или в проприетарном коде, или полностью свободном (BSD), но не в вирусно-свободном (GPL).

Странное сочетание. Типа «делайте что угодно, но так, чтобы проприетарщики всегда могли захапать себе ваш код»?

> Подобные заявления имеют вес только в виде рекомендации от патентного юриста (даже не самого Бернштейна).

Исходя из общих соображений: если я на базе чьего-то патента сделаю свою разработку и начну её продавать (даже, возможно, запатентовав её), это не освободит меня от возможных претензий со стороны первого патентодержателя. Грубо говоря, патент заразный: всё, что хоть как-то использует факты, отражённые в патенте, считается использующим патент. А в плане конкретно ECC — да, тут надо разбирать конкретную ситуацию, что там могут и что не могут предъявить патентодержатели, SATtva привёл ссылку. Если вспомнить историю с Diffie^[link56], возникает вопрос, почему аналогичное не может повториться с Бернштейном и его кривой.

— unknown (24/03/2014 09:58)

>«делайте что угодно, но так, чтобы проприетарщики всегда могли захапать себе ваш код»?

В качестве явного последствия получается именно это, но формальное обоснование такого казуса крылось в чём-то другом.

>возникает вопрос, почему аналогичное не может повториться с Бернштейном и его кривой.

Бернштейн специально разрабатывал альтернативные реализации ECC так, чтобы увести их из под патентов^[link57].

Если кривые от НИСТа попали в OpenSSL ещё раньше кривых от Бернштейна, то вроде как потому, что сообщество СПО решило, что на ряд методов ECC патенты не распространяются. Даже дистрибутивы и проекты, которые всерьёз следят за патентной чистотой, уже ECC поддерживают. Нужно смотреть, как реализовано у них, чтобы не копировать методы, которые могут попасть под патент.

— ZAS (23/04/2014 01:59)
www.zas-comm.ru

Выложен на даунлоад ZAS Communicator 1.6

Secure voice, file transfer and text chat.
Билд 298 Win32/64 (XP/W7/W8)

Прилагается инсталлер под Windows, а также комплект бинарников и исходного кода для продвинутых пользователей.
По опыту эксплуатации и пожеланиям добавлено много новых опций; см. меню "Settings".
Файлы истории чата и даунлодов зашифрованы. В отладочных целях можно писать весь траффик в лог.
Исправлена работа при отсутствии UPnP. Исправлен ряд моментов в DHT и сетевой части.

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

Подключайтесь, пробуйте, присылайте баг-репорты и пожелания.

zas@zas-comm.ru

— ZAS (12/05/2014 20:05)
Новая версия: ZAS Communicator 1.7 (билд 332, Win32/Win64)

http://www.zas-comm.ru

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

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

Как обычно, добавлено новых полезных опций и пофиксено багов.

Пробуйте, присылайте баг-репорты и пожелания.

zas@zas-comm.ru

— Гость (12/05/2014 21:24)
Пока для Linux не будет – даже всерьз рассматривать нет мысла. Труд хороший, но о какой криптографии может идти речь, если пользоваться можно только под виндой?

— Гость (13/05/2014 09:19)

> Труд хороший

Вы хоть тред-то читали?

— ZAS (27/05/2014 19:18)
Выложен ZAS Communicator 1.8 (билд 340, Win32/Win64)

http://www.zas-comm.ru

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

Концептуально мы готовы к тому, чтобы включить протокол с мультихопом, т.е. анонимизацией. Во-первых, это решило бы проблему с NAT loopback, то есть с несколькими пользователями, сидящими за одним NAT на одном внешнем IP адресе. Во-вторых, т.к. шифрование делается между оконечными пользователями, для анонимизации минимально достаточно иметь цепочку из двух промежуточных узлов, а не трех, как в TOR или I2P. (Хотя протокол допускает цепочки произвольной длины). Однако сейчас сеть слишком мала; ляжет под траффиком. Подключайтесь, будем растить сеть.

Пробуйте, присылайте баг-репорты и пожелания.

zas@zas-comm.ru

— Гость (28/05/2014 00:25)

> Пробуйте, присылайте баг-репорты и пожелания.

Сколько BTC вам нужно закинуть на счёт, чтобы вы перестали страдать этой ерундой и опоганивать и так не самый лучший мир оупенсорца?

— ZAS (28/05/2014 05:40)
Мы делаем хорошее, полезное и нужное дело. И не просим ничего.

Написано, кстати, очень прилично. Профессионально, творчески и со знанием дела. И не open source, хотя исходники приложены. В лицензии написано, что код прилагается только для review. Поэтому не приведены юнит-тест-бенчи, тестовые вектора, анализ примитивов и процедур и пр. Вся положенная кухня, конечно, имеется.

Можно подумать насчет учреждения приза за лучший анализ алгоритмов и протоколов. Предлагаю $500 за анализ и $1000 за практическую атаку на программу (атаки на винду и на сам комп не считаются).

zas@zas-comm.ru

— Гость (28/05/2014 13:10)
О чем ты говоришь? Полезное и нужное дело и "И не open source".. А твоя ZAS Professional под линукс в каком виде то будет? Тоже "не опенсорс"? За что конкретно планируется взиматься плата?
А предложение в 500$ за аудит непонятного проекта, да еще и с целью PR от имени сообщества PGPRU – вообще смешно..
Опиши нормально концепцию своего "творения". Что хочешь добиться, в какие сроки, что конкретно предложить людям из имеющихся конкурентноспособных аналогов. Чем лучше торфона или xmpp с соответствующим XEP'ом + TOR. Да хоть I2P...
Раз в квартал выкладывать непонятно что с невменяемым ченджлогом – это по-твоему "полезное и нужное дело"?
Почему тогда проект никто всерьез не рассматривает?
Лучше бы усилия и знания в другое русло направил..

— Гость (28/05/2014 16:44)

> Опиши нормально концепцию своего "творения". Что хочешь добиться, в какие сроки

Аффтар уже всё описал. Начнём с того, что у него самодельные шифры, и он считает их лучше общепризнанных. Дальше можно не продолжать и не описывать, так ведь? Я ж говорю, вы тред-то прочитайте, прежде чем комментить.

— ZAS (28/05/2014 18:55)

под линукс в каком виде то будет?

Во-первых, перед тем, как бороться с разными версиями линуксов, нужно 100% отладить протокол.
Во-вторых, Линукса и Андроиды поднимают целый ряд своих проблем. Например, как унифицировать юзеровский интерфейс, аудио интерфейс и интерфейс сети/upnp. Эти проблемы непринципиальны и решаются трудом и временем, которого нет.
Была идея сделать на QT но отказались из-за крайней монструозности, глючности и лицензионных проблем QT.

За что конкретно планируется взиматься плата?

За плагины с продвинутыми опциями. Видео, desktop sharing и пр.

предложение в 500$ за аудит непонятного проекта, – вообще смешно..

Никто не заставляет и не тянет за язык. Если действительно разбираешься, можешь показать на деле.
Повторять чужие мантры умеет любой дурак.

Опиши нормально концепцию своего "творения".

Бессерверная сеть с маршрутизацией с помощью DHT (Kademlia). Все участники равноправны. Каждый участник идентифицируется 256-битным ID. ID вычисляется как хеш от открытого ключа проверки подписи этого участника.
Весь обмен зашифрован и подвергнут обфускации; так что стороннему наблюдателю придется разбирать пакеты, чтобы вообще установить наличие траффика. Вхождение в связь по протоколу подобному Sigma-I. DHT обеспечивает поиск участников, как по ID, так и по ключевым словам.

Чем лучше торфона или xmpp с соответствующим XEP'ом + TOR. Да хоть I2P...

В отличие от, система пригодна для рядового юзера и обеспечивает хорошее качество звука. Подключился и работай.
В отличие от, система не закладывается на чужую инфраструктуру и является самодостаточной.
В отличие от, cистема обеспечивает поиск и соединение юзеров друг с другом.

что конкретно предложить людям из имеющихся конкурентноспособных аналогов.

Единственным конкурентоспособным аналогом является Скайп. Но Скайп – частная и закрытая система со всеми вытекающими.
Плюс циркулирующие слухи на тему skype spyware.

— ZAS (28/05/2014 19:31)

Начнём с того, что у него самодельные шифры, и он считает их лучше общепризнанных. Дальше можно не продолжать и не описывать, так ведь?

нп
Разбираясь в основах криптографии, не составляет никакого труда сделать сильный шифр. Трудно сделать шифр сильный и эффективный в реализации. Особенно если претендовать на мировые рекорды скорости.

В данном случае эффективность по скорости третьестепенна. Поэтому мы можем сделать так, как нам удобно, вместо того, чтобы приспосабливать к нашим нуждам то, что является модным сейчас.

Что нам удобно:

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

2. Шифр не должен хранить большого обьема вспомогательных данных. Идеально чтобы все состояние шифра описывалось количеством битов, равным ключу.

Предлагается следующая конструкция (см. random.cpp):

128-битная машина состояний, гарантирующая минимальный период последовательности. Счетчик – скушно и слишком предсказуемо. Полином – особая точка =0, которую нужно проверять. Мне нравятся нелинейно-конгруэнтные генераторы
типа X[n+1] = (X[n]^A)*B mod C, потому что их нельзя представить как F(n), нужно вычислять пошагово.

256-битная хеш функция, ключуемая машиной состояний. Берется XXTEA c 20 раундами, с запасом. Сила раундовой функции XXTEA порядка трех бит, так что хватило бы 11 раундов.

128-битный криптоалгоритм, использующий хеш функцию как ключ и машину состояний как данные. Тут используется IDEA.

Получился не слишком эффективный алгоритм, зато надежный и удобный. A попробуйте придумать что-то более эффективное и сильное с однонаправленной функцией, гарантированным 128-битным периодом, 256-битной стойкостью и 384-битным состоянием.

— gegel (28/05/2014 20:38)

256-битная хеш функция, ключуемая машиной состояний. Берется XXTEA c 20 раундами

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

A попробуйте придумать что-то более эффективное и сильное с однонаправленной функцией, гарантированным 128-битным периодом, 256-битной стойкостью и 384-битным состоянием.

Я уже предлагал использовать Keccak SpongeWrap mode. Это, во всяком случае, академично, имеет теоретический базис, и никто Вас не упрекнет в самодеятельности.

ПС: напомните, какие голосовые кодеки и битрейты вы используете?

— ZAS (28/05/2014 21:39)

256-битная хеш функция, ключуемая машиной состояний. Берется XXTEA c 20 раундами

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

Есть статья Elias Yarrkov где показано, что XXTEA с 6 раундами как криптоалгоритм не обеспечивает 128-битной стойкости, адекватной размеру ключа. Функция раунда XXTEA не биективна, что упрощает поиск коллизий для хеш функции на основе XXTEA. Однако поиск коллизий != обращение функции.

A попробуйте придумать что-то более эффективное и сильное с однонаправленной функцией, гарантированным 128-битным периодом, 256-битной стойкостью и 384-битным состоянием.

Я уже предлагал использовать Keccak SpongeWrap mode. Это, во всяком случае, академично, имеет теоретический базис, и никто Вас не упрекнет в самодеятельности.

С вектором состояния больше килобита.

какие голосовые кодеки и битрейты вы используете?

Speex Wideband 8/16/24k режимы

Если работать медленнее чем 8k, то скорость в канале определяется оверхедом IP. Можно, конечно, упаковывать несколько пакетов аудиоданных в большой пакет, но это увеличит задержку.

http://www.zas-comm.ru
zas@zas-comm.ru

— Гость (28/05/2014 21:55)

Во-вторых, Линукса и Андроиды поднимают целый ряд своих проблем. Например, как унифицировать юзеровский интерфейс, аудио интерфейс и интерфейс сети/upnp.

Самый лучший интерфейс – командная строка, всё остальное – мусор.

— gegel (28/05/2014 23:13, исправлен 28/05/2014 23:52)

Есть статья Elias Yarrkov

Да, именно эту работу я и подразумевал.

поиск коллизий != обращение функции.

На сколько я понимаю, в таком применении хеш-функции как раз достаточно поиска коллизий.

С вектором состояния больше килобита.

Так используйте меньше (соответственно требуемой криптостойкости всей системы), если это имеет для Вас значение: F-преобразование ведь позволяет работать с различными соотношениями.

Самый лучший интерфейс – командная строка

Я, кстати, тоже с этим столкнулся в процессе работы над onionphone. Все же он интерактивный по сути, и без интерфейса будет неудобен и непрактичен. Например, установив соединение через Tor, пользователь захочет переключиться на прямое, используя выбранный STUN. Или в процессе разговора изменить кодек, подстроить компенсацию jitter в изменившемся Tor-канале и т.д. Пока остановился на curces.

Speex Wideband 8/16/24k режимы

Я так понимаю, VBR маскируется вашей обфускацией. При малых задержках и высоких битрейтах реконструкция фонем по VBR – уже не теоретическая, а практическая уязвимость.
Я ради интереса прикрутил много кодеков: MELPE-1200, CODEC2-1400, MELP-2400, LPC10-2400, GSM-FR, GSM-HR, GSM-EFR, G729, G723.1, CELP, LPC, ILBC, BV16, SILK, SPEEX и OPUS. Часть из них под патентами, часть свободна. Попробуйте добавить CODEC2 для возможности работы через GPRS, лишним не будет.
Также интересна возможность у LPC-кодека манипулировать описателями речи. Кодируете фрейм, изменяете описатели, затем декодируете. Получаются различные эффекты вокодера. Если использовать рандомные изменения (в определенных пределах) или статические значения, то, наверное, можно теоретически оценить устойчивость к идентификации (вероятность ошибки при сравнении с эталоном определенной длины).

— ZAS (29/05/2014 00:51)

поиск коллизий != обращение функции.

На сколько я понимаю, в таком применении хеш-функции как раз достаточно поиска коллизий.

Нужно найти все коллизии (по 256-битному входу), и выбрать из них ту, которая правильная. И так на каждом шагу прокручивания алгоритма в обратном направлении. Это если противник полностью завладел текущим состоянием шифра. Если противник знает только гамму шифра, задача еще более усложняется. Знание и гаммы, и текущего состояния тоже не сильно поможет.

С вектором состояния больше килобита.

Так используйте меньше (соответственно требуемой криптостойкости всей системы), если это имеет для Вас значение: F-преобразование ведь позволяет работать с различными соотношениями.

Разве смысл не в том, чтобы использовать готовую стандартную функцию Keccak без своих переделок?

Я, кстати, тоже с этим столкнулся в процессе работы над onionphone. Все же он интерактивный по сути, и без интерфейса будет неудобен и непрактичен.

Именно.

Например, установив соединение через Tor, пользователь захочет переключиться на прямое, используя выбранный STUN. Или в процессе разговора изменить кодек, подстроить компенсацию jitter в изменившемся Tor-канале и т.д.

По-моему, технические настройки должны работать автоматически. Скайп показывает хороший пример, чего можно добиться.
Им потребовалось 10 лет для того, чтобы научиться работать так устойчиво и качественно, как сейчас.

Speex Wideband 8/16/24k режимы

Я так понимаю, VBR маскируется вашей обфускацией. При малых задержках и высоких битрейтах реконструкция фонем по VBR – уже не теоретическая, а практическая уязвимость.

VBR не используется. Юзер может выбрать одну из трех фиксированных скоростей, согласно качеству канала. Как показал опыт, бывают cлабые каналы, по которым не проходит аудио на 16.8kbps.

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

Я ради интереса прикрутил много кодеков: MELPE-1200, CODEC2-1400, MELP-2400, LPC10-2400, GSM-FR, GSM-HR, GSM-EFR, G729, G723.1, CELP, LPC, ILBC, BV16, SILK, SPEEX и OPUS. Часть из них под патентами, часть свободна.

Ваш интерес понятен и близок. Занимался кодеками.

Попробуйте добавить CODEC2 для возможности работы через GPRS, лишним не будет.

Скорость кодека ниже 8kbps не имеет смысла для VoIP, т.к. траффик в этом случае определяется оверхедом самого IP протокола. Группировать аудиоданные в большие пакеты = увеличивать задержку.

Также интересна возможность у LPC-кодека манипулировать описателями речи.Кодируете фрейм, изменяете описатели, затем декодируете. Получаются различные эффекты вокодера. Если использовать рандомные изменения (в определенных пределах) или статические значения, то, наверное, можно теоретически оценить устойчивость к идентификации (вероятность ошибки при сравнении с эталоном определенной длины).

Эффекты и идентификация – другая тема, хотя тоже интересная.

http://www.zas-comm.ru

zas@zas-comm.ru

— Гость (29/05/2014 04:20)

> предложение в 500$ за аудит непонятного проекта, – вообще смешно..

Аудит одного дня^[link58]. 500$ в день — это так мало?

> В отличие от, cистема обеспечивает поиск и соединение юзеров друг с другом.

OnionPhone gegel'я тоже.

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

KeccaK PRP + специальные режимы использования. Вопрос толком теоретически не проработан, но прорабатывается. Стандартов, я так понимаю, мы ещё долго не увидим.

> гарантированным 128-битным периодом

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

> Однако поиск коллизий != обращение функции.

А теоретический/сертификационный криптоанализ ≠ практическому. Но весь объём накопленных знаний, примеров и опыта говорит о том, что шифры, разработанные устойчивыми к первому устойчивы и ко второму, причём с очень хорошим запасом (обратное обычно неверно), поэтому устойчивость к первому принимается за максиму в любом респектабельном научном или академическом сообществе. Любительские шифры, даже «созданные с запасом», условиям сертификационного криптоанализа не удовлетворяют, их ломают только так. Навиная попытка компенсировать своё незнание и непонимание дизайна шифров их запутыванием часто ведёт к их ослаблению. Unknown даже недавно приводил конкретный исторический пример (подскажите ссылку, так и не смог найти), как соединив вместе два по отдельности стойкие примитива получили полностью нестойкую конструкцию (тривиальный взлом?).

— ZAS (29/05/2014 06:34)

> предложение в 500$ за аудит непонятного проекта, – вообще смешно..

Аудит одного дня. 500$ в день — это так мало?

Пока вы меня не убедили в том, что ваша стоимость $120k в год.
Кто-то говорил что любительские шифры ломает в пять минут?

> В отличие от, cистема обеспечивает поиск и соединение юзеров друг с другом.

OnionPhone gegel'я тоже.

Допустим, я хочу позвонить Васе Печкину. Каким образом найти Васю Печкина в TorPhone?

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

KeccaK PRP + специальные режимы использования. Вопрос толком теоретически не проработан, но прорабатывается. Стандартов, я так понимаю, мы ещё долго не увидим.

Необязательно keccak; подойдет любая хеш-функция + хеш функция от хеш функции. Можно взять за основу, например, BLAKE, SKEIN как, впрочем, и любой другой cильный блочный шифр. A можно построить необратимую пермутацию а-ля RC4, только посложнее. Но это потребует существенно больше памяти для хранения состояния. Способов множество.

> гарантированным 128-битным периодом

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

Сами себе возводите какие-то аргументы, потом сами же их опровергаете.
Заговариваетесь?

> Однако поиск коллизий != обращение функции.

А теоретический/сертификационный криптоанализ ≠ практическому. Но весь объём накопленных знаний, примеров и опыта говорит о том, что шифры, разработанные устойчивыми к первому устойчивы и ко второму, причём с очень хорошим запасом

Так как насчет того чтобы инвертировать хеш функцию с использованием XXTEA с 20 раундами и 256-битным блоком?
При известном 128-битном ключе. Или найти хотя бы одну коллизию?

Unknown даже недавно приводил конкретный исторический пример (подскажите ссылку, так и не смог найти), как соединив вместе два по отдельности стойкие примитива получили полностью нестойкую конструкцию (тривиальный взлом?).

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

Есть интересная статья Бирюкова и Шамира насчет конструкций типа SASAS. Заставляет хорошо задуматься о проблемах AES – подобных шифров.

http:\\www.zas-comm.ru
zas@zas-comm.ru

— Гость (29/05/2014 07:46)

> Допустим, я хочу позвонить Васе Печкину. Каким образом найти Васю Печкина в TorPhone?

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

> Кто-то говорил что любительские шифры ломает в пять минут?

Речь о теоретическом криптоанализе шла.

>>> гарантированным 128-битным периодом

>> Опять началось. Отсутствие периода не подразумевает криптостойкость.

> Сами себе возводите какие-то аргументы, потом сами же их опровергаете. Заговариваетесь?

Простите, но про период вы тут начали. К чему этот аргумент? О том, что нет периода = всё стойко, тут до вас успела повещать орава виндовых троллей (кажется, в топиках типа сжатия диска и в топиках про каскадные шифры, но мне лень искать точные цитаты).

>> Unknown даже недавно приводил конкретный исторический пример

> Речь шла об Akelaire – хороший пример слабого шифра.

Оказывается, об это было здесь же на предыдущих страницах^[link59] [но написано с опечаткой]. Вики^[link60].

— Гость (29/05/2014 07:50)

> Так как насчет того чтобы инвертировать хеш функцию с использованием XXTEA с 20 раундами и 256-битным блоком? При известном 128-битном ключе. Или найти хотя бы одну коллизию?

Безопасность примитива доказывает тот, кто его выдвигает, а не наоборот («пока не нашли уязвимость, оно безопасно»). Тяжесть доказательства^[link61] и всё такое.

— unknown (29/05/2014 10:16)
/comment79981^[link62]:

>Разбираясь в основах криптографии, не составляет никакого труда сделать сильный шифр. Трудно сделать шифр сильный и эффективный в реализации. Особенно если претендовать на мировые рекорды скорости.

/comment79982^[link63]:

>Я уже предлагал использовать Keccak SpongeWrap mode. Это, во всяком случае, академично, имеет теоретический базис, и никто Вас не упрекнет в самодеятельности.

/comment79983^[link64]:

>С вектором состояния больше килобита.

Keccak в чём-то неоптимален, а самопальные алгоритмы изначально не претендуют на оптимальность реализации, пытаясь компенсировать этим свои слабости разработки. В чём выигрыш такого подхода, неясно.

Даже в реализации известных алгоритмов могут быть уязвимости, неотлавливаемые годами (как в OpenSSL), а если ещё и алгоритм неизвестный, то как там его неидеальности лягут на всё остальное, докопаться смогут не скоро.

— ZAS (29/05/2014 20:31)
(...описание алгоритма cм выше...)

поиск коллизий != обращение функции.

Насколько я понимаю, в таком применении хеш-функции как раз достаточно поиска коллизий.

Требуется обращение хеш функции, т.е. найти все входные вектора которые дают заданный выходной вектор. Поиск коллизий, т.е. нахождение каких-то двух разных входных векторов, дающих один и тот же результат – более простая задача. Во втором случае мы можем подбирать слабые ключи или данные, в первом – нет.
Но даже во втором случае, для XXTEA вероятность уходит за 2^-100 после первых 5 раундов.

Keccak в чём-то неоптимален, а самопальные алгоритмы изначально не претендуют на оптимальность реализации, пытаясь компенсировать этим свои слабости разработки.

Конкретнее. Какие именно слабости?

В чём выигрыш такого подхода, неясно.

Уже писал, каких целей хотелось достичь. Необратимости алгоритма, минимальной памяти, практической стойкости, простоты реализации.

http://www.zas-comm.ru
zas@zas-comm.ru

— Гость (30/05/2014 02:51)

> Во втором случае мы можем подбирать слабые ключи или данные, в первом – нет.

Перепутаны местами «во втором» и «в первом»?

> Какие именно слабости?

Если бы не было слабостей, разаработчики таких любительских креативов не исходили бы из того, что чем сильнее без понимания напутают всякого и разного, тем лучше. Грубо говоря, своё непонимание они компенсируют сложностью и запутанностью.

— ZAS (30/05/2014 19:20)
Прошу прощения, постинг сьел функцию.

const u32 rounds = 32;

u32 s_box(u32 x)
{
x = (x << 4) - x;
x ^= x >> 10;
x = (x << 7) | (x >> 25);
return x;
}


void encrypt(u32 *x, const u32 *key, const u32 len)
{
u32 N = 0;

for(u32 i = 0; i < rounds; i++)
 {
 for(u32 j = 1; j < len; j++)
  {
  x[j] += s_box(x[j-1] ^ (N + key[j]));
  N++;
  }
 x[0] += s_box(x[len-1] ^ (N + key[0]));
 N++;
 } 
}

void decrypt(u32 *x, const u32 *key, const u32 len)
{
u32 N = rounds * len;

for(u32 i = 0; i < rounds; i++)
 {
 N--;
 x[0] -= s_box(x[len-1] ^ (N + key[0]));

 for(u32 j = len - 1; j > 0; j--) 
  {
  N--;
  x[j] -= s_box(x[j-1] ^ (N + key[j]));
  }
 }
}

— unknown (31/05/2014 10:02)
Так придумать шифр много кто может. А проанализировать — нет. Я не являюсь сколь-нибудь серьёзным специалистом по криптоанализу, поэтому не могу доверять шифрам, которые бы сам попытался создать. Я в примере выше упоминал, что как-то пытался сделать простейший аналог шифра IDEA, потом обнаружил тривиальный различитель на двух блоках подобранного открытого текста, действующий при любом числе раундов. Скорее всего, он легко превращался в атаку нахождения ключа, но не было смысла разбираться.

Моя логика проста: вероятность фатальной ошибки в собственноручном шифре гораздо выше, чем в созданном признанными специалистами в открытом сообществе при соблюдении всех определённых условий и формальностей. А по последствиям самопальный шифр м.б. хуже любой закладки. Причём, скорее всего, дырка будет такая, что создатели криптозакладок помрут со смеху, когда до неё докопаются. Я бы ни за что не стал доверять собственноручно созданному шифру, если только не стал бы проводить муторную многолетнюю работу по его академической публикации, привлечению других спецов и пр. Или только как в качестве демопримера для изучения каких-нибудь свойств новых функций в теоретических работах.

И по отношению к шифру, опубликованному псевдонимом без серьёзного теоретического бэкграунда я рассуждаю примерно также. Мне приблизительно понятно к какой группе шифров его можно отнести и какие примерно методы криптоанализа против них обычно применяются. Если там явная слабость, то может он и поломается легко. А если нет, то тратить массу времени на поиск реализаций атаки с негарантированным результатом — неинтересно. И ради чего собственно? Я лучше AES или SHA-3 лишний раз поковыряю. Оно как-то полезнее будет, даже если крохотную атаку на них показать.

Вот только почему бы вам самому не начать это делать, на вашем шифре? Попробовать самому выяснить, сколько раундов вашего шифра ломаются. За сколько шагов, с какими затратами, какими атаками. Алгебраическую сложность функции рассчитать, дифференциальные и прочие характеристики. Показать, что с ростом раундов сложность атаки будет расти вот по такой-то формуле. Тогда может кто-то найдёт зацепку для атаки, исходя из ваших возможных неправильных теоретических предпосылок как разработчика алгоритма.

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

— ZAS (31/05/2014 19:09)

Так придумать шифр много кто может. А проанализировать — нет. Я не являюсь сколь-нибудь серьёзным специалистом по криптоанализу,

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

Я бы ни за что не стал доверять собственноручно созданному шифру,

Не доверяю ни себе, ни другим. Поэтому вышеописанная конструкция на основе XXTEA/IDEA.
Была мысль сделать все на основе DES, потому что DES изучен вдоль и поперек. Но слишком неэстетичный алгоритм.

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

Функция s_box() биективна, в отличие от используемых в Enrupt и XXTEA. По моим оценкам, обеспечивает наихудшую вероятность дифференциальной характеристики не хуже 2^-3. Параметры s_box оптимизированы. Исходя из вероятности диф. характеристики получаем минимально необходимое число раундов 11..12 для всей UFN. Слабость s_box в том, что она линейна по краям, т.е. есть "сильные" и "слабые" биты. Еще одно потенциально слабое место – key schedule, которое регулярно и ни разу не оптимально. Лечим проблемы количеством раундов.

симметричных алгоритмов публикуют и так много.

Алгоритм имеет смысл публиковать только если он в чем-то лучше многих существующих. Например, быстрее и/или эффективнее в реализации. Если алгоритм ничем не лучше, то зачем такой нужен.
Во многих случаях был бы удобен универсальный блочный примитив с ключом и блоком произвольных размеров, пусть неэффективный, но простой в реализации. Известны XXTEA и Enrupt, в которых авторы недооценили нужное число раундов в погоне за скоростью. Универсальный безопасный шифр легко построить со количеством операций порядка N^2, где N-размер блока, но слишком неэффективно. Я попытался изобразить нечто подобное со сложностью порядка N.

А в криптоалгоритме без каких-либо теоретических наработок могут поковыряться разве что, если его авторами будет АНБ

Simon интересен как идея, да. Но доверять NSA не хочется.

http://www.zas-comm.ru

— Гость (01/06/2014 02:19)
[offtop]

> Моя логика проста: вероятность фатальной ошибки в собственноручном шифре гораздо выше, чем в созданном признанными специалистами в открытом сообществе при соблюдении всех определённых условий и формальностей. А по последствиям самопальный шифр м.б. хуже любой закладки. Причём, скорее всего, дырка будет такая, что создатели криптозакладок помрут со смеху, когда до неё докопаются.

Даже если всё делать по-академичному, есть личный пример: я находил опечатки, ошибки и непонимание авторами в уже опубликованных статьях. В моих статьях тоже находили серьёзные ошибки. Очень часто статья выходит, но её никто не читает, и если там есть ошибка, она там может сидеть хоть десятилетиями.

Вообще, если рассматривать пристально, статьи — отражение форума. Часто пишут непонятно, проглатывают мысли, ставят не те ссылки, опечатваются, приводят фальшивые аргументы, а иногда вообще ошибаются и пишут неправильные результаты. Этим страдает, пожалуй, чуть ли ни каждая вторая статья в архиве. И когда платят за количество, а не за качество, мало кто остаётся верен высокой планке качества: лучше выбросить сырой непродуманный результат, оформленный наспех, в надежде, что мелочёвка потом будет общими усилиями исправлена (вычитка редакторами, рецензентами, самим перед принятием к публикации), а глобальных проблем в работе нет.
[/offtop]

— unknown (01/06/2014 03:23)

>статьи — отражение форума. Часто пишут непонятно, проглатывают мысли, ставят не те ссылки, опечатваются, приводят фальшивые аргументы, а иногда вообще ошибаются и пишут неправильные результаты

Ответ на околостатейный офф., ещё и на этот комент^[link65] и далее по текущему топику. У авторов AES и Keccak — одни из лучших статей, просто за счёт подробности обоснований. Но когда они слегка накосячили в обеих проектах их есть куда ткнуть носом. Про AES по памяти помню, они ввели определение "Hermetic и K-Secure". После взломов можно сейчас найти эти строки, фигурально ткнуть пальцем и разобрать, почему это доказательство и эта модель были ошибочны. Сложнее, но также можно покопаться, почему в Keccak ошиблись с выбором нулевого вектора для старта начального раунда (решили, что это некритично?), что привело к созданию атак на различители с нулевой суммой, а также спорить и пытаться прогнозировать, что там у них оказался заниженный результат с уровнем алгебраической сложности. Не будь качественной развёрнутой теоретической работы (пусть даже ошибочной), сами эти ошибки не стали бы столь наглядными и поучительными, имели бы больше шансов пройти незамеченными.

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

Попытка заменить S-блок алгебраическими функцией были придумана давно. Видимо вам такой подход нравится: IDEA, {X,XX,}TEA, RC{5,6}, MD5, SHA{1,2}. Теперь вот Salsa, ChaCha и Treefish/Skein. Получается виртуальный S-блок большого размера (32 бита).

Обычный таблично-представимый 8-битовый S-блок можно изучить на все придумываемые зависимости методом перебора, хотя с межблочными зависимостями внутри раунда и межраундовыми зависимостями так не получится. Используются оптимизационные алгоритмы поиска, которые часто не публикуются, а публикуется лишь общая идея и найденные результаты.

Ваш виртуальный S-блок похож на ARX (Addition-Rotation-Xor), хотя и использует немного другой набор операций, но суть похожа. Методом перебора пар текстов и ключей в таком большом массиве что-либо найти сложно (пытаться перемножить, перексорить, складывать и пр. все комбинации 32-битных блоков, 2⁶⁴ варианта как минимум). Поэтому такие функции были очень популярны, хотя оставалось сомнение в доказательстве их стойкости. Проблема возникла, когда для ARX-подобных шифров нашли метод оптимизированного поиска характеристик без полного перебора. К сожалению работы не вспомню, общая идея была понятна, но тоже не запомнилась, а подробности самой реализации поиска, как и предполагалось, в работах оказались скрыты.

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

Но смешивание создания криптопримитивов и программной разработки в лучшем случае — показатель излишней самоуверенности. Хотя бы формально разнесли по разным проектам и не пихали одно в другое (разумеется, решать всё вам, никто кроме вас вам не указ), да ещё занимаясь саморекламой с непрерывной простановкой ссылок на свой сайт, непрерывным постингом ченджлогов, репортов и пр. Общие идеи, пожалуйста, обсуждайте. У нас несколько достаточно-достойных русскоязычных проектов о себе заявило в менее навязчивой форме. Но если активным участникам форума проекты в чём-то не нравятся и не всегда охота подробно разбирать в чём, это не знак молчаливого одобрения для того чтобы их форсить не через свой ресурс.

— ZAS (01/06/2014 17:51)

Обычный таблично-представимый 8-битовый S-блок можно изучить на все придумываемые зависимости методом перебора, хотя Ваш виртуальный S-блок похож на ARX (Addition-Rotation-Xor), хотя и использует немного другой набор операций, но суть похожа. Методом перебора пар текстов и ключей в таком большом массиве что-либо найти сложно (пытаться перемножить, перексорить, складывать и пр. все комбинации 32-битных блоков, 2^64 варианта как минимум).

В таких случаях удобно сделать, скажем, 16-битную версию функции и проанализировать на предмет возможных проблем. Оптимальные параметры функции и конкретные слабости будут, разумеется, другими, но классы проблем вы увидите. Другой прием с той же целью – сделать функцию частично или полностью линейной, заменяя addition на xor.

A попробуйте на досуге 4-битную версию RC4, прикольно :)

http://www.zas-comm.ru

— unknown (01/06/2014 21:06, исправлен 01/06/2014 21:08)

>Другой прием с той же целью – сделать функцию частично или полностью линейной, заменяя addition на xor.

Да, напомнили, вроде ключевые слова — "ARX linearisation". Одну из букв в ARX выкидывают, подбирая наиболее похожую, но более линейную функцию, на которой легче найти дефект. В окрестностях дефекта упрощённой функции ищут дефект исходной, полной нелинейной функции. Какая-то такая была идея, именно так, как вы описываете.

Пара вопросов, небольших критических замечаний по теме.

Создавая «негосударственный» шифр вы можете доказать отсутствие явной или тайной связи с влиянием государства только самому себе. Как другие могут поверить в отсутствие этой связи, даже если бы вы были не аноним, а человек с репутацией? Это как взлом. Явно продемонстрированный взлом доказывает нестойкость однозначно, а стойкость в большинстве областей современной криптографии доказывается плохо, косвенно и неполностью.

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

Ваш проект под какой лицензией идёт? Если не GPL/BSD и вы даже не хотите брать куски такого кода и линковаться с ним, шарахаетесь от патентов на эллиптику, которые, вроде как решены для опенсорсных лицензий, да ещё хотите коммерциализировать часть проекта, то всё это наводит на подозрительную мысль. Автор может в случае успеха подсадить часть пользователей на свой негласный стандарт, а затем закрыть или полностью коммерциализировать проект, сделав вендор-локинг.

Ваш проект обещает какие-то деньги за аудит. Откуда они у беззвестного анонима? Не стоИт ли за этим коммерческая контора или мутный стартап, который даст попользоваться бесплатно, а затем закроет исходники, перепродасться и заобфусцирует часть кода и протокол. Самопальный простые шифры как раз очень для этого подходят — в скомпиленном коде с обфускацией их труднее отреверсить.

Даже в случае успеха с таким подходом и позиционированием проекта маячут, как минимум лавры трукрипта или ещё какие сюрпризы.

— ZAS (03/06/2014 06:48)

Пара вопросов, небольших критических замечаний по теме.

О вкусе устриц. Вместо абстрактно-отвлеченных cуждений, посмотрите cобственно проект. И вопросов будет меньше.

Даже в случае успеха с таким подходом и позиционированием проекта маячут, как минимум лавры трукрипта

Вклад создателей трукрипта в дело защиты гражданских свобод трудно переоценить.

http://www.zas-comm.ru

— ZAS (27/06/2014 18:35)
ZAS Communicator 1.8.1 (билд 352) выложен на даунлод.
http://www.zas-comm.ru

Win32/Win64 версии, исполняемые файлы и исходники.

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

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

— Гость (15/07/2014 04:10)
Какой смысл использовать шифр IDEA ?
In 2012, full 8.5 round IDEA was finally broken, using a narrow-bicliques attack, with a reduction of cryptographic strength of about two bits, similar to the effect of the previous bicliques attack on AES.

— Гость (15/07/2014 16:23)
Да удалять нужно отсюда этот "проект".. Мало того, что под винду, так еще и непонятная система монетизации и какие-то дартарьянские амбиции автора. Пили под Линукс – тогда возможно посмотрят. Плюсов и различий с другими аналогами – нет. Только минусы. с ТОХ ты как конкурировать собрался, виндузятник?

— ZAS (15/07/2014 22:31)

Какой смысл использовать шифр IDEA ?

Не знаю. Причем тут вообще IDEA?

In 2012, full 8.5 round IDEA was finally broken, using a narrow-bicliques attack, with a reduction of cryptographic strength of about two bits,

Если уж упоминули IDEA и bicluques: 126-битная стойкость при 128-битном ключе. И...?

Да удалять нужно отсюда этот "проект".. Мало того, что под винду, так еще и непонятная система монетизации и какие-то дартарьянские амбиции автора.

Вместо обычного бормотания не по делу, попробуйте сделать хоть что-то сами. Хотя бы предложите что-нибудь полезное или умное.

Пили под Линукс – тогда возможно посмотрят.

Версия под Linux в процессе. Приходится обрастать bloat в виде QT; тот еще отдельный гемор.

Плюсов и различий с другими аналогами – нет.

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

c ТОХ ты как конкурировать собрался, виндузятник

Очень рад за TOX, спасибо за наводку. Приятно видеть, что идея распределенной cистемы связи на основе DHT имеет сторонников. Если действительно в TOX все хорошо, первый буду пользоваться. Тем не менее, надо растить и совершенствовать свою систему.

http://www.zas-comm.ru

— Гость (16/07/2014 09:12)

> Очень рад за TOX, спасибо за наводку.

Для тех, кто в танке: новость^[link66] была ещё год назад.

— gegel (16/07/2014 14:05, исправлен 16/07/2014 14:06)

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

Торфон обеспечивает поиск абонента средствами TorHS (по его onion-адресу), а затем переход на прямое UDP-соединение с NAT-traversal через уже установленное onionHS-соединение и любой STUN. Я давно продвигал эту идею, как более практичную, чем свой DHT.

Что касается обфускации трафика, то Торфон использует нестандартный протокол (не RTP) без особых паттернов, причем при выходе из onion на прямое p2p UDP-соединение уже шифрованный (причем согласование ключей выполнено внутри Tor).

По качеству связи: куча кодеков на выбор, в т.ч. OPUS.

— ZAS (16/07/2014 18:32)

Торфон обеспечивает поиск абонента средствами TorHS (по его onion-адресу)

Во-первых, неудобно; нужен обычный произвольный поиск юзеров по ключевым словам без предварительных согласований или публикации каких-то таблиц на каких-то серверах. Во-вторых, концептуально не нравится зависимость от третьих сущностей в виде TOR.

, а затем переход на прямое UDP-соединение с NAT-traversal через уже установленное onionHS-соединение и любой STUN. Я давно продвигал эту идею, как более практичную, чем свой DHT.

Вполне понятно желание разработчика упростить себе жизнь.

Что касается обфускации трафика, то Торфон использует нестандартный протокол (не RTP) без особых паттернов,

Траффик ZAS в любой фазе соединения выглядит как поток случайных UDP пакетов случайной длины; порты тоже выбираются случайно.

По качеству связи: куча кодеков на выбор, в т.ч. OPUS.

Для хорошего голоса достаточно одного кодека, с самплрейтом 16kHz. Но дело не столько в кодеке, сколько в правильном алгоритме буфферизации, адаптирующемся под канал. Каналы oчень разные.

/*

*/
Была идея использовать Скайп как транспорт, подсунув ему на вход свое устройство в виде псевдо-аудио/псевдо-видео.
Или перехватывать на уровне сетевого стека уже установленное соединение Скайпа и накладывать на него сверху свой шифрователь. Таким образом, решаются проблемы с поиском и соединением. Но появляются третьи сущности, которым вряд ли это нравится. Кроме того, заклад на негарантированные свойства. Такой проект может пойти как мелкий хак; но вряд ли получится сделать большую систему. Хотя идея проста и очевидна. Кто-нибудь пробовал?

http://www.zas-comm.ru

— gegel (16/07/2014 20:06)

нужен обычный произвольный поиск юзеров по ключевым словам без предварительных согласований или публикации каких-то таблиц на каких-то серверах.

Я давно хотел у Вас спросить: есть ли в этом смысл? Для поиска абонента надо точно знать имя (или любой другой идентификатор), чтобы искать по хешу. Чем это практичнее поиска по заранее опубликованному адресу? Конечно, можно организовать какой-то перебор при поиске, или же, наоборот, публиковать различные варианты (ключевые слова) и т.п. Но всего ведь не учтешь, да и поиск существенно затянется. Мне кажется, что перебор – это непрактичный костыль в данном случае. А как реализован поиск у Вас? Можно ли найти всех абонентов, содержащих в имени 'gegel'?

Кто-нибудь пробовал?

У меня тоже была идея использовать Скайп в качестве транспорта. Но тут вы правы: рано или поздо это не понравится Microsoft, и на этом все закончится. Зависеть от Microsoft несравненно хуже, чем зависеть от Tor.

— ZAS (16/07/2014 21:01)

нужен обычный произвольный поиск юзеров по ключевым словам без предварительных согласований или публикации каких-то таблиц на каких-то серверах.

Я давно хотел у Вас спросить: есть ли в этом смысл? Для поиска абонента надо точно знать имя (или любой другой идентификатор), чтобы искать по хешу. Чем это практичнее поиска по заранее опубликованному адресу?

В любом случае придется хранить, обновлять и доступаться до информации, соединяющей идентификатор абонента в системе, произвольное описание абонента и его текущие IP:port. Альтернативы две – выделенный сервер или распределенная DHT. Cерверная система намного проще, однако сервера крайне уязвимы. Через проблему cервера или DHT уже прошли p2p файлообменные сети.

А как реализован поиск у Вас? Можно ли найти всех абонентов, содержащих в имени 'gegel'?

Можно найти всех абонентов, содержащих в user info подстроку gegel и/или подстроку torphone, например. И показывать, скажем, только тех, у которых в user id есть последовательность битов 0x12345.

http://www.zas-comm.ru

— Гость (16/07/2014 21:33)
Банальная атака на такую систему: создаем клон ника и становимся человеком посередине. Никто не заметит прослушку.

— ZAS (16/07/2014 22:40)

Банальная атака на такую систему: создаем клон ника и становимся человеком посередине.

Невозможно. Приняты меры. Для этого есть аутентификация.

1. При установлении связи происходит взаимная аутентификация сторон с помощью электронной подписи. Чтобы аутентификация работала, мне нужно один раз убедиться, что мой визави Вася Печкин действительно имеет user id 1234 5678 .... (всего 256 бит). После чего я добавляю Васю Печкина в доверенные юзера.

2. Кроме того, в нижней части окна показываетcя число: session id. Это хеш от общего секрета, установленного при Diffie Hellman обмене с другой стороной. Session id должно быть одинаково у обеих сторон; можно взаимно свериться в любой момент.

3. Чтобы создать клон ника, нужно cгенерить фальшивую пару ключей подписи. Для этого нужно сгенерировать другой прообраз для заданного значения хеш функции размером 256 бит. Притом прообраз должен выглядеть как валидный ключ.

4. Можно стать человеком посередине если украсть секретный ключ подписи и пароль, которым закрыт ключ; но это уже не из области криптографии.

http://www.zas-comm.ru

— Гость (16/07/2014 23:21)

ZAS (15/11/2013 17:51)
Ищем единомышленников
Пишите письма
zas@zas-comm.ru

И напишу! – Чхал я на ваш этот ZAS глюкатор, если даже на главной якобы русской странице вместо русского пиндосовская англосаксятина вроде этой -

27.06.2014 Выпущена версия beta 1.8.1

Maintenance/Bugfix release:

Fixed old problem with no sound when moving/resizing window during phone communication.
Fixed possible GUI crash when adjusting parameters.
Fixed several bugs in networking protocol.
The program collects entropy from system events, in addition to CryptGenRandom calls and collection of entropy from incoming/outgoing data
и т.д.

Это что по-вашему – русский??

Глубоко имел в виду тех, кто не любит свой родной язык! И их поделия – тоже!

— Гость (17/07/2014 05:47)

> н^[link67]ужен обычный произвольный поиск юзеров по ключевым словам без предварительных согласований или публикации каких-то таблиц на каких-то серверах.

Как-то плохо это согласуется с анонимностью участников и их сеансов связи.

> Во-вторых, концептуально не нравится зависимость от третьих сущностей в виде TOR.

А нет других сетей, предлагающих настоящую анонимность (ну разве что Freenet), поэтому любой продукт, требующий анонимности, будет завязан на Tor в любом случае.

> Глубоко имел в виду тех, кто не любит свой родной язык! И их поделия – тоже!

Это как латынь в средние века. Хочешь написать точно, правильно и грамотно — пиши на языке оригинала. Язык CS — английский.

— ZAS (17/07/2014 06:38)

нужен обычный произвольный поиск юзеров по ключевым словам

Как-то плохо это согласуется с анонимностью участников и их сеансов связи.

В ZAS каждый участник имеет произвольное текстовое поле, в которое он может поставить любые слова, по которым его будет возможно найти в DHT. Участники идентифицируются 256-битным userid, поиск нужен только для удобства установления связи в первый раз. Текстового поля можно и не вводить; а можно и изменить в любой момент.

Можно одновременно работать от нескольких разных identities.

Во-вторых, концептуально не нравится зависимость от третьих сущностей в виде TOR.

А нет других сетей, предлагающих настоящую анонимность (ну разве что Freenet),

Не бывает и не может быть общедоступных сетей, обеспечивающих анонимность. TOR и Freenet – не исключения.
Анонимность может обеспечить система прокси серверов, где все верифицированы, то есть личная система и только для своих хозяев. Например, ботнеты или тот же Скайп.

поэтому любой продукт, требующий анонимности, будет завязан на Tor в любом случае.

Протокол ZAS допускает туннели с произвольным числом хопов. Это сделано не столько для анонимности, а для борьбы с проблемой NAT loopback. Сейчас эта фича не используется. Но в принципе можно сделать и анонимизацию; с теми же неизбежными проблемами с недоверием что и у всех остальных систем.

http://www.zas-comm.ru

— Гость (17/07/2014 07:00)

> Не бывает и не может быть общедоступных сетей, обеспечивающих анонимность.

Необщедоступные сети неанонимны заведомо. Даже GCHQ это понимает^[link68].

— gegel (17/07/2014 23:13)

Невозможно. Приняты меры. Для этого есть аутентификация.

Опишите в конце концов Ваш протокол в виде, как, например, описан OTR. Или хоть как нибудь. А то приходится лишь догадываться о вашей аутентификации.

— Гость (17/07/2014 23:40)
ТОХ вчера в альфе вышел. Весь день общались сегодня по нему. Сделали алиасы вида ник@сервер. ТОХ действительно шедевр! Очень оперативно развивается, клиентов уже полно и модель его неубиваема – разрабы анонимны и их реально много.

— Гость (18/07/2014 00:28)
Я тоже тестировал его сегодня. Мне очень понравился, и интерфейс у него не плохой.
Вот только непонятно – он генерирует на разных машинах разные TOX ID, как и TorChat. А если нужно запустить с другой машины? Как контакт-лист свой сохранить и залогиниться под первым TOX ID, который уже безопасно передан всем знакомым?

— ZAS (18/07/2014 00:45)

Опишите в конце концов Ваш протокол в виде, как, например, описан OTR.

Посмотрите же наконец файл diffie_hellman.cpp; там предельно очевидно.

Каждый пользователь идентифицируется 256-битным userid.
Userid вычисляется как хеш от открытого ключа проверки подписи этого пользователя. Userid = hash(K).

1) A->B:
* A выбирает g,X,p. (g – генератор, X – секретное число, p – модуль). Посылает g,(g^X)%p, p.

2) B->A:
*B выбирает секретное число Y. вычисляет общий секрет S = ((g^X)^Y)%p
из общего секрета получаются разные ключи для шифрования и MAC данных (MAC данных и аутентификация протокола – разные сущности).

* вычисляется ответное значение: (g^Y)%p,

* вычисляется хеш: H = hash { g, p, g^X%P, g^Y%P } от открытых значений.

* H подписывается подписью B: Sb = SignB(H)

* Берется { Sb, Kb }. Kb = ключ проверки подписи B. Эти значения зашифровываются потоковым шифром с добавлением MAC.

Response = cipher { Sb, Kb, MAC }

Посылается значение (g^Y)%P и Response.

3) A->B:

* A вычисляет общий секрет S = ((g^Y)^X)%p, из секрета получает ключи для MAC и шифрования,
* расшифровывает Response
* вычисляется хеш: H = hash { g, p, g^X%P, g^Y%P } от открытых значений.
* проверяет MAC, проверяет подпись B. Если известно что userid B соответствует Васе Печкину, то A убедился в том, что B действительно Вася Печкин.
* подписывает H подписью A: Sa = SignA(H)

* Берется { Sa, Ka }. Ka = ключ проверки подписи A. Эти значения зашифровываются потоковым шифром с добавлением MAC.
Посылается значение Confirmation = cipher { Sb, Kb, MAC }

4) B расшифровывает Confirmation, проверяет MAC и подпись. Если B известно что userid A cоответствует Пупкину, то B убедился в том, что A действительно Пупкин.

Все ключи MAC и шифрования во всех направлениях разные. Userid передаются по каналу в зашифрованном виде. Протокол обеспечивает сильную взаимную аутентификацию, невидимую третьей стороне. Обеспечивается и отрицаемость.

Примерно так. Вспомогательные детали типа проверки валидности g,P – отдельная история; здесь не приведены для ясности.

— Гость (18/07/2014 08:05)

> модель его неубиваема – разрабы анонимны и их реально много.

Т.е. код никто не подписывает?

> Посмотрите же наконец файл diffie_hellman.cpp

Только говношифропанки считают, что спецификаця на код — это сам код. Люди сначала пишут спеки, потом к спекам код. Шифрпанки сначала пишут код, а соответствующие спеки часто даже сами не знают.

— ZAS (18/07/2014 09:46)
Возражений по существу протокола аутентификации не поступило. Очень хорошо.

> Посмотрите же наконец файл diffie_hellman.cpp

Только говношифропанки считают, что спецификаця на код — это сам код.

Приятно иметь дело с умным интеллигентным собеседником. Вы cами хоть что-нибудь полезное делать умеете?

Люди сначала пишут спеки, потом к спекам код. Шифрпанки сначала пишут код, а соответтвующие спеки часто даже сами не знают.

— unknown (18/07/2014 10:11, исправлен 18/07/2014 10:11)

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

Наверное, ваш проект делается по методике Остапа Бендера. Нью-Васюки прилагаются? Международный шахматный турнир когда будет?

— Остап_Ибрагимович (18/07/2014 10:50)
unknown, "Мы чужие на этом празднике жизни.." © Он же.
А по поводу сабжа: " Предмет моей лекции — плодотворная дебютная идея. Что такое, товарищи, дебют и что такое, товарищи, идея? Дебют, товарищи, — это «Quasi una fantasia». А что такое, товарищи, значит идея? Идея, товарищи, — это человеческая мысль, облечённая в логическую шахматную форму."

— ZAS (18/07/2014 11:09)

"Мы чужие на этом празднике жизни.." © Он же.

Киса, позвольте спросить вас, как криптограф криптографа...

http://www.zas-comm.ru

— gegel (19/07/2014 14:21)

он генерирует на разных машинах разные TOX ID, как и TorChat.

Торчат элементарно переносится копированием каталога \bin\Tor\hidden_service, содержащим приватный ключ и b32-отпечаток публичного. Думаю, с TOX ситуация аналогичная.

Возражений по существу протокола аутентификации не поступило. Очень хорошо.

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

открытого ключа проверки подписи этого пользователя

Я так понимаю, это публичный ключ пользователя, который должен быть известен второй стороне, и вторая сторона должна доверять этому ключу (т.е. однозначно связать его с именем пользователя). Тут возникает вопрос: как вторая сторона впервые получает этот ключ? Если по постороннему доверенному каналу, то к чему тогда эта изюминка с поиском по ключевым словам, которой Вы так гордитесь? Если же через DHT после поиска, то как передается доверие к ключу?
Тут есть амбициозный вариант создать свою PKI (но тогда надо предусмотреть передачу подписей вместе с ключом и проверку цепочек), или же можно использовать PGP. Если Вы будете использовать PGP, то опишите, как именно планируете это делать.
Не подумайте, что я придираюсь к мелочам, но на практике ломать вашу IDEA и даже XTEA никто в здравом уме не станет, а вот на кривом протоколе аутентификации эксплоит будет использован сразу же при достижении проектом хоть какого-то уровня популярности.

— ZAS (19/07/2014 19:29)

открытого ключа проверки подписи этого пользователя

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

Публичный ключ проверки подписи связан с 256-битным userid пользователя: userid = hash(Key).
Нам нужно один раз убедиться что данный userid действительно соответствует тому пользователю, с кем мы общаемся. Для этого мы созваниваемся с этим пользователем по ZAS и сверяем наши userid (предполагается что опознаем друг друга). После чего обе стороны помещают проверенные userid в доверенный список.

То есть для доверенной связи с Васей Печкиным мне достаточно один раз проверить, что userid = 0x1234... это действительно Вася Печкин.

Тут возникает вопрос: как вторая сторона впервые получает этот ключ?

См. описание процедуры соединения. При установлении связи всегда стороны передают друг другу свои открытые ключи, по недоверенному каналу. Если мы уже сверяли userid, то достаточно проверить if(userid == hash(Key))... Если не сверили, всегда можно сверить.

Если по постороннему доверенному каналу, то к чему тогда эта изюминка с поиском по ключевым словам, которойВы так гордитесь?

Как я могу найти gegel в ZAS, не зная его userid? Только по ключевым словам в DHT.

Если же через DHT после поиска, то как передается доверие к ключу?

См. выше. Разумеется, будучи заранее незнакомыми с gegel-ем, мы не сможем верифицировать друг друга. Как, впрочем, и при любом другом контакте.

В дополнение к подписям, можно всегда сверить параметры текущего соединения, аналогично как делается в PGPhone и пр.

Тут есть амбициозный вариант создать свою PKI (но тогда надо предусмотреть передачу подписей вместе с ключом и проверку цепочек),

Идея PKI в принципе порочна и ненадежна. Не стоит недооценивать противника. Если есть концептуальная возможность что-то взломать, она уже задействована.

или же можно использовать PGP. Если Вы будете использовать PGP, то опишите, как именно планируете это делать.

Моя жизненная позиция – по возможности не зависеть от третьих сущностей.

Хотя, если есть любой канал, по которому можно гарантированно узнать, что gegel = userid 12345..., то можно воспользоваться этим каналом. Но, даже если мы точно знаем userid, все равно нужно найти текущие IP:port корреспондента. Это делается через DHT.

— gegel (19/07/2014 23:49, исправлен 19/07/2014 23:51)

(предполагается что опознаем друг друга)

Я так понимаю, речь идет о биометрической (голосовой) идентификации путем сверки произносимых абонентами отпечатков сессионного ключа. Это стандартный подход, ОК. Единственное что – проверьте по своему заветному DiffieHellman.cpp: т.к. вызываемый абонент может в определенной степени влиять на общий секрет путем подбора y по известному X, то он может за разумное время подобрать такое Y, что скажем, 32 бита вашего отпечатка совпадут с заданными. Т.о. можно отмитмить соединение так, что произносимые короткие отпечатки совпадут. Обычно в таких случаях используют коммитмент или Y, или какого-то случайного мидификатора подсчета отпечатка. Надеюсь, Вы это учли, сейчас влом смотреть Ваш код.

Разумеется, будучи заранее незнакомыми с gegel-ем, мы не сможем верифицировать друг друга. Как, впрочем, и при любом другом контакте.

Представляете, обычно для этого и используют PGP :) Но можно и по-другому. В какой-то теме unknown уже приводил пример, когда Алиса советует Бобу по данному вопросу обратиться к Еве, но Боб с ней не знаком лично и не может идентифицировать по голосу. Логичным и естественным решением тут будет предусмотреть возможность передачи чужих ключей по уже установленному каналу. В таком случае Алиса через защищенное соединение отсылает Бобу ключ Евы (или удостоверяет его отпечаток), и если Боб доверяет Алисе, то он доверяет и полученному ключу. Вариант PKI.

В OnionPhone (проект в процессе) можно будет использовать 4 варианта аутентификации:
– голосом по отпечатку общего секрета;
– публичными DH-ключами + они могут быть подписаны PGP + могут передаваться в процессе соединения и автоматически сохраняться на диске; позже можно проверить подпись и вручную назначить уровень доверия к каждому ключу в адресной книге; + они могут быть переданы по другому доверяемому каналу и добавлены в книгу вручную.
– общим секретом (фразой) + скрытое уведомление под принуждением изменением части фразы;
– по onion-адресам (по Abadi, аналогично аутентификации в TorChat путем создания встречного соединения по указанному onion-адресу и обмена доказательствами).
Хотелось бы видеть возможность выбора и у Вас, и у TOX.

— ZAS (20/07/2014 01:16)

Надеюсь, Вы это учли, сейчас влом смотреть Ваш код.

Summary по ZAS аутентификации.
Посвящается тем, кто не читает то, о чем писали в треде много раз:

1. Sigma протокол. В ZAS каждый пользователь идентифицируется 256-битным userid. Это userid представляет собой хеш от открытого ключа пользователя. Чтобы иметь защищенную связь с Васей, достаточно знать факт, что данное userid принадлежит Васе. Достаточно один раз в этом убедиться. Неважно, каким cпособом. При личной встрече, биометрически, c помощью PGP, третьих доверенных лиц, PKI или голубиной почты. Как угодно.
Если я удостоверился, что Вася = userid 12345.. то я могу добавить запись "Вася = 12345..." в свой файл проверенных юзеров. Это делается кликом мышки.
(мой файл проверенных юзеров защищен от посторонней модификации моей подписью)
(проверенные и непроверенные юзера показываются разным цветом в списке)

2. Независимо от (1), всегда можно сверить отпечаток DH параметров, которые должны быть одинаковы у A и B.
Отпечаток = хеш от открытых значений { g,p, g^X, g^Y }.

Мне кажется, что (1) + (2) практически достаточно. Может быть полезно добавить еще один механизм аутентификации на основе pre-shared secret password с уведомлением о прессинге; cпасибо за мысль. Подумаю на эту тему.

(не знаю, какая модель security принята у TOX; навскидку не нашел вразумительного обьяснения).

http://www.zas-comm.ru

— gegel (20/07/2014 19:54)

Достаточно один раз в этом убедиться. Неважно, каким cпособом. При личной встрече, биометрически, c помощью PGP, третьих доверенных лиц, PKI или голубиной почты.

Пока что рассматриваем биометрический вариант: абоненты знают друг друга по голосу, устанавливают связь впервые. Какие Вы им даете рекомендации по сверке UserID, т.е. что конкретно кто должен произнести? Я так понимаю, у каждого на экране будут отображены UserID-ы: собственный и противоположной стороны. Что дальше? Кто и чей ИД должен зачитать?
Дело в том, что в данном случае тактика влияет на безопасность.

— ZAS (21/07/2014 00:54)

Пока что рассматриваем биометрический вариант: абоненты знают друг друга по голосу, устанавливают связь впервые. Какие Вы им даете рекомендации по сверке UserID, т.е. что конкретно кто должен произнести? Я так понимаю, у каждого на экране будут отображены UserID-ы: собственный и противоположной стороны. Что дальше?

Cтороны зачитывают оба userid по очереди. Группами по 32 бита. Сначала Вася зачитывает 32 бита от userid Пети, потом Петя зачитывает следующие 32 бита от userid Пети, потом опять Вася зачитывает очередные 32 бита от userid Пети, потом опять Петя зачитывает очередные 32 бита своего userid и.т.д. потом та же процедура сверки userid Васи.

http://www.zas-comm.ru

— Гость (21/07/2014 01:35)

> Cтороны зачитывают оба userid по очереди.

А если противник, обладая голосовым банком данных, преварительно создал запись их голосов для фейковых отпечатков, он может устроить MITM. :)

— gegel (21/07/2014 15:36, исправлен 21/07/2014 15:37)

обладая голосовым банком данных

Для этого даже не нужен банк данных.

Для лучшего понимания перепишем инструкция так:
"Стороны зачитывают начало (половину) чужого ИДа и конец своего."
Достаточно заставить их произнести полные ИДы Еве, и можно подставлять записи при MitM. Помню фильм, когда девушка в баре выуживала с парня по слову для построения фразы доступа, и никак не могла заставить произнести последнее дурацкое слово, неестественное для свидания.

Точнее, такая аутентификация относительно безопасна лишь однократно. Аутентифицировать голосом постоянные параметры неразумно. Кроме того, часть ИДа Боба, произнесенная Алисой, даем возможность Бобу-информанту показать судье факт связи с Алисой, так что об отрицаемости можно забыть.

Правильно будет отказаться от такого способа аутентификации (это лишь вводит в заблуждение пользователей) и оставить только озвучивание параметров соединения. Так сделано в ZRTP и всех VOIP-утилитах, его использующих. После биометрического подтверждения параметров друг другу MitM исключается, и тогда можно спокойно сохранить отпечатки текущих ключей как доверенные.
Причем еще правильнее озвучивать не публичные параметры (X и Y), как сделано у Вас, а хеш от общего секрета + дополнительные параметры, как сделано Циммерманном: если Алиса смогла зашифровать свой голос секретом, то понятно, что она его знает. И если она произнесла хеш секрета, то дополнительно ничем себя не скомпроментировала.
Но если Алиса произнесла публичные параметры (X, Y), то позже Боб-информант может предоставить судье-наблюдателю доказательство того, что зафиксированный судьей зашифрованный разговор был его и Алисы.

— ZAS (21/07/2014 19:01)

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

Да, Вы правы. Тем более если параметры соединения верифицированы, то переданные по этому соединению userid можно считать тоже верифицированными.

Причем еще правильнее озвучивать не публичные параметры (X и Y), как сделано у Вас, а хеш от общего секрета + дополнительные параметры,

Это тоже учтем в следующем билде.

Спасибо за критику и дельные предложения.

http://www.zas-comm.ru

— ZAS (21/07/2014 20:37)

Достаточно заставить их произнести полные ИДы Еве, и можно подставлять записи при MitM.

т

Нет, не так.

Для того, чтобы Ева могла организовать MitM, ей нужно выдать cебя за A и за B. Для этого Еве придется произнести фиктивные сгенерированные ею userid голосом A и голосом B. Записи настоящих голосов A и B могут быть использованы только как материал для манипуляции. Но в случае атаки манипуляции процедура ничем не хуже озвучивания параметров соединения.

http://www.zas-comm.ru

— Гость (21/07/2014 21:36)

> Для того, чтобы Ева могла организовать MitM, ей нужно выдать cебя за A и за B.

Не обязательно. Если она подменяет только одну сторону, она сможет читать все сообщения, предназначенные этой стороне (но не её ответы абоненту).

— ZAS (21/07/2014 22:17)

Для того, чтобы Ева могла организовать MitM, ей нужно выдать cебя за A и за B.

Не обязательно. Если она подменяет только одну сторону, она сможет читать все сообщения, предназначенные этой стороне (но не её ответы абоненту).

Не получится. Такой вариант невозможен по сути протокола. Cекрет общий, аутентификация в обе стороны.

http://www.zas-comm.ru

— gegel (21/07/2014 23:11, исправлен 21/07/2014 23:15)

Для этого Еве придется произнести фиктивные сгенерированные ею userid голосом A и голосом B.

Ева генерирует фиктивные UserID, инициирует тестовые сессии с А и с Б, и А и Б произносят эти UserID в процессе первичной аутентификации с Е (правда, не ту половину, но все же).

Правда, проблема для Евы в том, что при этом А и Б сохраняют эти UserID, как принадлежащие Еве, и будут слегка удивлены, если потом будет совпадение. А если не сохранят (не добавят Еву в контакт-лист)?

Но это все так шатко выглядет, что лучше делать, как все (как Циммерманн в данном случае) и не искать приключений.

— Гость (21/07/2014 23:28)

> Не получится. Такой вариант невозможен по сути протокола.

Да, может быть. Я про верификацию PGP думал, когда писал.

— ZAS (24/07/2014 18:48)

Ева генерирует фиктивные UserID, инициирует тестовые сессии с А и с Б, и А и Б произносят эти UserID в процессе первичной аутентификации с Е (правда, не ту половину, но все же).

Не ту половину ID – это раз.

А и Б сохраняют эти UserID, как принадлежащие Еве, и будут слегка удивлены, если потом будет совпадение.

Совпадение – это уже два.

Но это все так шатко выглядет, что лучше делать, как все (как Циммерманн в данном случае) и не искать приключений.

Не более и не менее шатко, чем верификация по хешу общего секрета (тем более что такой режим тоже поддерживается).
Зиммерман – руководство к действию, а не образец для копирования во всем.

— ZAS (15/10/2014 18:16)
На даунлоад выложен ZAS 1.9.0 (билд 357); Win32/Win64.

http://www.zas-comm.ru

Инсталлер, бинарники, исходники. Работает сразу, настраивать не требуется.
Рекомендуется UPnP или отфорвардить порты вручную; хотя по факту работает и без того и другого.
Cовместимо с XP/W7/W8, 32/64. Нормально идет в виртуалке.
Не требует дополнительных сущностей типа Tor, Java, QT и пр. и рингтон работает.

Изменений много:

Полностью переделана симметричная криптография.
Решена проблема со связью между пользователями за NAT. Работает без NAT reflection.
Хорошо работает Find по DHT. Можно искать юзеров по ключевым словам и по части userid.
Исправлено багов; добавлено новых опций в GUI по пожеланиям юзеров.

Изменился формат ключей и сетевой протокол. Нужно перегенерить ключи; соответственно будут другие userid.

— gegel (15/10/2014 20:58)

Полностью переделана симметричная криптография.
Решена проблема со связью между пользователями за NAT. Работает без NAT reflection.

Можно по этим двум пунктам поподробнее?

— Гость (15/10/2014 21:45)
Не с того начали – реализация под Windows сразу лишает доверие к проекту.
Поскольку порт под Linux теперь всегда будет по остаточному принципу.

— Гость (15/10/2014 23:04)
To ZAS
Просмотрел сайт, не заметил описания установки программы. Она устанавливается в систему или работает в портабельным виде?

— ZAS (15/10/2014 23:08)

Можно по этим двум пунктам поподробнее?

Решена проблема со связью между пользователями за NAT. Работает без NAT reflection.
Полностью переделана симметричная криптография.

NAT reflection
Большой проблемой было непрохождение UDP от одного юзера к другому, если оба юзера находятся на одном и том же внешнем IP адресе, поделенном через NAT. То есть я могу позвонить кому угодно в Интернете, но только не своему соседу за соседним столом. Если посылать UDP на свой внешний IP адрес, то разные роутеры создают разнообразные глюки. Пакеты могут ходить, а могут не ходить, или могут доходить с измененным IP/port, и.т.п. Даже если в роутере через NAT reflection нормально ходит TCP, то не означает, что ходит UDP.

Решение: работаем с локальными юзерами напрямую по локальным адресам, c дальними юзерами – по внешним адресам. Пришлось переделать сетевой протокол.

Крипто

В предыдущей хеш-функции были найдены псевдоколлизии. Хотя до атаки на второй прообраз далеко, решено было переделать и cделать с хорошей перестраховкой. Заодно переделан основной потоковый шифр, и многие другие вещи в симметрике продуманы и вычищены. Асимметрика прежняя: DH и электронная подпись на 4096-битных числах.
С удовольствием обсужу детали, что, как и почему сделано; отдельная большая тема.

Не с того начали – реализация под Windows сразу лишает доверие к проекту.
Поскольку порт под Linux теперь всегда будет по остаточному принципу.

Cначала нужно добиться безукоризненной работы ядра сетевого протокола и DHT. Это непросто.
В планах приделывание QT интерфейса и видео. Если кто-то может помочь в реализации кросплатформенного юзеровского интерфейса, будем рады.

http://www.zas-comm.ru

— ZAS (15/10/2014 23:16)
Просмотрел сайт, не заметил описания установки программы. Она устанавливается в систему или работает в портабельным виде?

Работает в портабельном виде. Продвинутым пользователям нужны два файла: zas.exe и upnp.dll. Все прочие файлы создаются в той же директории. Ничего в реестр Windows не пишется, если сами не взведете соответствующие галочки в опциях. Можно запускать с флешки.
Для непродвинутых пользователей есть инсталлер.
Для advanced пользователей – исходники. Собирается VS12.

http://www.zas-comm.ru

— gegel (16/10/2014 01:49)

Решение: работаем с локальными юзерами напрямую по локальным адресам, c дальними юзерами – по внешним адресам. Пришлось переделать сетевой протокол.

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

— ZAS (17/10/2014 00:46)

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

Kто-то третий должен быть хабом. Думали насчет протокола с мультихопом; тогда хабы получаются сами собой. Это есть в коде и даже как-то работает в тестовых условиях, но реально никогда не пробовали.

— ZAS (18/11/2014 18:57)
Выложен ZAS 2.0 (билд 381); Win32/Win64.

http://www.zas-comm.ru

Главное нововедение: ВИДЕО. В зависимости от скорости интернета, поддерживается три режима H.264 (64/128/256kbit) с соответственно различным качеством.

Прилагается инсталер, портабельные бинарники и исходники. Пользоваться просто: запустить программу, сгенерировать пароль и ключ, найти нужного абонента в DHT с помощью find. Опции конфигурации очевидны и устанавливаются галочками в GUI; конфигов править не требуется; все работает сразу по дефолту.

Программа представляет собой один портабельный файл zas.exe. Все библиотеки прилинкованы статически, конфиги, ключи и прочие файлы aвтоматически создаются в текущей директории.

Хеш функции теперь считаются в режиме wide pipe: размер состояния функции вдвое превышает выходной размер хеша. Это усилило криптографию, однако привело к несовместимости с предыдущими версиями ZAS. Рекомендуется clean install, т.к. файлы ключей, телефонной книги и пр. предыдущих версий несовместимы.

Почти сделана версия ZAS для Linux (на основе QT). Будет выложена в следующем релизе.

zas@zas-comm.ru

— gegel (19/11/2014 09:31, исправлен 19/11/2014 09:33)

Будет ли большой проблемой:
– предусмотреть возможность прямой p2p связи по указанному IP-порту (портам)?
– предусмотреть возможность полного отключения бутстрапа (например, указанием пустого домена сервера в конфиге; в этом случае программа не должна отправлять абсолютно никаких пакетов, кроме как в случае установки прямого соединения строго по указанному IP)?

DHT хороша для обычного пользователя, но иногда IP участников известны и порты заранее проброшены; в этом случае остальное можно рассматривать лишь как дополнительный источник отказов и уязвимостей.

Кроме того, я планирую реализовать прозрачный бридж (по типу ZFone) для защищенного/аутентифицированного проброса диапазона UDP-портов на заданный HS как универсальное решение, позволяющее различным медиа-коммуникаторам, поддерживающим p2p, устанавливать соединение через Tor: в этом случае возможность p2p на локалхост расширит область примемения ZAS-коммуникатора.

— ZAS (19/11/2014 17:45)

– предусмотреть возможность прямой p2p связи по указанному IP-порту (портам)?

Меню File -> Connect to.

– предусмотреть возможность полного отключения бутстрапа

Легко сделать.

DHT хороша для обычного пользователя, но иногда IP участников известны и порты заранее проброшены; в этом случае остальное можно рассматривать лишь как дополнительный источник отказов и уязвимостей.

Учтем. IP:port сохраняются в телефонной книге; тогда нужно сделать возможность редактирования.

Кроме того, я планирую реализовать прозрачный бридж (по типу ZFone) для защищенного/аутентифицированного проброса диапазона UDP-портов на заданный HS как универсальное решение, позволяющее различным медиа-коммуникаторам, поддерживающим p2p, устанавливать соединение через Tor: в этом случае возможность p2p на локалхост расширит область примемения ZAS-коммуникатора.

Интересная идея. Как в этом случае осуществляется адресация?

http://www.zas-comm.ru

— gegel (19/11/2014 20:11)

Как в этом случае осуществляется адресация?

В этом решении планирую осуществлять адресацию исключительно силами ониофона (по онион-адресу). Т.е. выбрасываю аудио, но оставляю метки времени и буферизацию. Получается демон с возможностью подключения к указанному онион-адресу. Он создает пару UDP-портов на локалхосте, прозрачно соединенных с удаленным демоном и его парой портов. Т.е. получается бридж с защищенным и аутентифицированным каналом (средствами онионфона).
Внешнее медиа-приложение c поддержкой p2p (например, ZAS) настраивается для соединения с 127.0.0.1:onionphone_port. Второе приложение слушает свой 127.0.0.1:defaultRTPport. Демон онионфона пакует полученные UDP-пакеты в TCP-поток, пересылает через Tor и на другом конце распаковывает и отсылает опять в виде UDP. Это решит проблему отсутствия поддержки UDP в Tor и даст возможность прозрачно пробросить RTP.
Приблизительно так же работает ZFone, перехватывая RTP-поток и пакуя его в ZRTP (шифруя предварительно p2p согласованным ключом), только без смарт-буферизации и преобразования в TCP и обратно.

— unknown (20/11/2014 09:29)

>Демон онионфона пакует полученные UDP-пакеты в TCP-поток

Onioncat^[link69]?

— gegel (20/11/2014 12:22)

Onioncat?

Типа да, но заточен под задачу: с соответствующими таймаутами, смарт-буферизацией, дублированием и сменой цепочек – вобщем, все из онионфона.

Дополнительный слой p2p независимого аутентифицированного шифрования. IPv4. "Из коробки" (два года назад пытался поднять Onioncat под Win32 – это было что-то...).

— ZAS (29/01/2015 19:01)
ZAS Communicator 2.1.0 (билд 403), Win32/64

http://www.zas-comm.ru

Из нововведений:

* Для передачи файлов используется библиотека UDT. Cкорость обмена файлов возросла cущественно; практически до скорости аплода.

* Работает, даже если нет UPnP или невозможно отфорвардить порты. По UDP регулярно посылаются keep-alive посылки, чтобы в роутерах не устаревала таблица роутинга пакетов.

* Можно выбирать рингтоны.

* DHT можно отключить. Работать только на прямое соединение и/или чтобы редиректить траффик в TOR, VPN и пр.

* Исправлено багов по мелочи.

— gegel (29/01/2015 19:59)

чтобы редиректить траффик в TOR

А медиатранспорт через TCP (rfc4571) возможен?
И, если да, то еще вопрос: сколько открытых TCP-портов реально потребуется для установки прямого TCP-соединения?

— ZAS (29/01/2015 20:19)

А медиатранспорт через TCP (rfc4571) возможен?
И, если да, то еще вопрос: сколько открытых TCP-портов реально потребуется для установки прямого TCP-соединения?

По простому – нет. Cейчас все работает по UDP через один порт.
Поясните, для каких применений может быть полезно RFC4571.

— gegel (30/01/2015 01:07, исправлен 30/01/2015 01:08)

Поясните, для каких применений может быть полезно RFC4571.

Проброс медиапотока через TCP может быть полезен в случае блокирования UDP-RTP-транспорта провайдером (случаи блокировки VOIP известны). Проблемой является проход NAT в TCP, но если ZAS поддерживает прямое соединение по IP/порту, то почему бы не дать возможность пробросить и аудио/видео через TCP.
Ну, и само собой, тогда решается вопрос со звонком через Tor.
По RFC4571, как и в UDP-RTP, RTP_control и RTP_data используют разные (обычно соседние четный и нечетный) порты, но можно объединить.

чтобы редиректить траффик в TOR

Интересно, как Вы собирались редиректить UDP-трафик в Tor...

— ZAS (30/01/2015 03:55)
ZAS использует свой протокол, не RTP. Траффик выглядит как рандомные пакеты рандомного размера по произвольному порту. Сейчас все работает полностью на UDP; и прямое соединение тоже. Не должно быть принципиальных проблем с тем чтобы уложить тот же поток в TCP. Почему именно в RFC4571 ?

Интересно, как Вы собирались редиректить UDP-трафик в Tor...

Насколько я Вас понял, вы хотели сделать универсальный роутер чтобы редиректить в Tor любые потоки ?

TOR для войса, увы, малопригоден; даже OnionPhone после установления контакта переводят на прямое UDP соединение.

— gegel (30/01/2015 09:19, исправлен 30/01/2015 09:21)

Почему именно в RFC4571

Я думал, что ZAS использует RTP. И, чтобы далее придерживаться стандартов, упомянул RFC4571 (RTP over TCP). Если у ВАс свой протокл, то задача упрощается. В Онионфоне, кстати, так же.

редиректить в Tor любые потоки

Это в идеале. Onioncat (VPN), но из коробки и с аутентифицированным p2p шифрованием + realtime оптимизация.

TOR для войса, увы, малопригоден

Не соглашусь с Вами. Латентность онионфона через Tor сейчас составляет 400-600mS, что сравнимо со спутниковой связью и вполне пригодно для делового общения. Переключение на прямое UDP – опция по желанию обоих сторон, это отдельная функция (Tor вместо SIP).

ПС: еще пару лет назад, во время моих экспериментов с Торфоном, я получал латентность 1000-3000 сек. За два года Tor стал значительно отзывчивее. Не знаю, хорошо это или плохо, но если такая тенденция сохраниться, то через пару лет выйдем на возможность голосового общения в пределах комфортных 300-400 мcек, не исключено, что и с видео.

— unknown (30/01/2015 11:16, исправлен 30/01/2015 11:16)

Какой-нибудь очередной тупой ботнет, управляемый через Tor, всегда сможет положить пропускную способность и увеличить латентность до неприемлемого уровня. И придёться снова ждать пару месяцев, пока его не изведут.

Ссылки

^[link1] ftp://ftp.pl.pgpi.org/pub/pgpi/pgpfone/manual/pgpfone10b7.pdf

^[link2] http://www.pgpru.com/comment19143

^[link3] http://www.zas-comm.ru/Sources_ZAS_Beta_0-1_240_9102013.zip

^[link4] http://www.pgpru.com/comment66315

^[link5] https://ru.wikipedia.org/wiki/Засекречивающая_аппаратура_связи

^[link6] http://www.pgpru.com/comment69790

^[link7] http://www.pgpru.com/comment71825

^[link8] http://www.pgpru.com/comment73707

^[link9] http://www.pgpru.com/forum/prakticheskajabezopasnostj/zascommunicator

^[link10] http://www.pgpru.com/comment73455

^[link11] http://www.pgpru.com/comment63307

^[link12] http://www.pgpru.com/comment63413

^[link13] http://www.pgpru.com/novosti/2014/lyranovajafunkcijapoluchenijakljuchaizparolja

^[link14] http://www.pgpru.com/novosti/2014/catenanovajafunkcijaobrabotkiparoljassoljjupercemichesnokom

^[link15] http://www.pgpru.com/comment75570

^[link16] http://eprint.iacr.org/2010/254

^[link17] http://eprint.iacr.org/2014/047

^[link18] http://www.pgpru.com/biblioteka/statji/hanaanskijjbaljzam

^[link19] http://www.pgpru.com/biblioteka/osnovy/vvedenievkripto/glava2/hanaanskijjbaljzam

^[link20] http://www.pgpru.com/faq/kriptografijaobschievoprosy#h37247-12

^[link21] http://www.pp-international.net/phpBB3/viewtopic.php?f=52&t=38539

^[link22] http://forum.pirate-party.ru/ob'yavleniya/proekt-zas-communicator/

^[link23] http://www.pgpru.com/comment76256

^[link24] http://www.pgpru.com/biblioteka/osnovy/fondzamechateljnyhcitat#fpts7

^[link25] http://www.dmi.unict.it/diraimondo/web/wp-content/uploads/papers/otr.pdf

^[link26] http://www.cypherpunks.ca/~iang/pubs/impauth.pdf

^[link27] ftp://ftp.pl.pgpi.org/pub/pgpi/pgpfone/win/PGPfone21-win.zip

^[link28] https://github.com/catid/calico

^[link29] https://github.com/catid/cymric/

^[link30] http://www.pgpru.com/comment70723

^[link31] http://www.pgpru.com/comment70570

^[link32] http://www.pgpru.com/novosti/2013/kaskadyizraznyhshifrovmogutbytjslabeesvoihsostavnyhchastejj

^[link33] http://www.pgpru.com/comment70493

^[link34] http://www.pgpru.com/comment70371

^[link35] http://www.pgpru.com/comment72068

^[link36] http://www.pgpru.com/comment72179

^[link37] http://www.pgpru.com/proekt/udalennye

^[link38] http://www.pgpru.com/comment77362

^[link39] http://events-tce.technion.ac.il/files/2012/10/KE-Hugo-Part2.pdf

^[link40] http://www.pgpru.com/comment63154

^[link41] http://www.pgpru.com/comment59788

^[link42] https://ru.wikipedia.org/wiki/Эффект_Даннинга_—_Крюгера

^[link43] http://www.cosic.esat.kuleuven.be/publications/article-314.pdf

^[link44] http://www.pgpru.com/biblioteka/statji/keccaksponge

^[link45] http://www.pgpru.com/biblioteka/statji/spongeencryption

^[link46] http://eprint.iacr.org/2011/499.pdf

^[link47] http://sponge.noekeon.org/SpongePRNG.pdf

^[link48] http://eprint.iacr.org/2007/472

^[link49] https://blake2.net/

^[link50] http://ru.wikipedia.org/wiki/Salsa20#ChaCha

^[link51] http://events-tce.technion.ac.il/files/2012/10/KE-Hugo-Part1.pdf

^[link52] https://otr.cypherpunks.ca/Protocol-v3-4.0.0.html

^[link53] https://whispersystems.org/blog/simplifying-otr-deniability/

^[link54] https://github.com/nightcracker/ed25519

^[link55] http://web.archive.org/web/20130524001754/http://www.rsa.com/rsalabs/node.asp?id=2325

^[link56] http://www.pgpru.com/comment73851

^[link57] http://cr.yp.to/ecdh/patents.html

^[link58] http://www.pgpru.com/comment75855

^[link59] http://www.pgpru.com/comment77396

^[link60] https://en.wikipedia.org/wiki/Akelarre_(cipher)

^[link61] https://en.wikipedia.org/wiki/Burden_of_proof

^[link62] http://www.pgpru.com/comment79981

^[link63] http://www.pgpru.com/comment79982

^[link64] http://www.pgpru.com/comment79983

^[link65] http://www.pgpru.com/comment80213

^[link66] http://www.pgpru.com/novosti/2013/proekttoxrazvivaetsvobodnujualjternativuskype

^[link67] http://www.pgpru.com/comment81340

^[link68] http://www.pgpru.com/comment81328

^[link69] https://www.onioncat.org/

openPGP в России

ZAS Communicator