ZAS Communicator

Blake2/Salsa20

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

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

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

Нет.

Все же Blake – финалист SHA3, точно так же, как и недавно Keccack.

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

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

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

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

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

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

ZAS Communicator: версия 1.5 (278)

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

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

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

zas@zas-comm.ru

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

Ну, раз уж пошла такая байда, то осмелюсь предложить заменить обычную 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