Pull to refresh
39
0
Send message
отовсюду прогнали ссаными тряпками

Ну, вообще говоря, ни кого особо не прогнали:
Simon
Speck

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

Ну в части России как-то малосодержательно и неполно, хотя информации в интернете достаточно

До 17.07 можно направить отзыв на проект стандарта. Вся информация есть на сайте ТК 194.

В проекте стандарта взаимодействия в узкополосном спектре (NB-FI) уже успели найти ряд уязвимостей https://ctcrypt.ru/files/files/2018/Rump/R02_Nozdrunov.pdf


Надо бы поработать над вопросами ИБ в стандарте. Для интернета вещей это критично.

Спасибо большое :)
Как у Ильи Ильфа: «Решено было не допустить ни одной ошибки. Держали двадцать корректур, и всё равно на титульном листе было напечатано: «Британская энциклопудия».»
Нет, вопрос только в обозначениях и записи.
Открытый текст и шифртекст такие, а вот ключ в примере (приложение А.2, с.16 на https://tc26.ru/standard/gost/GOST_R_3412-2015.pdf) указан другой.

K = ffeeddccbbaa99887766554433221100f0f1f2f3f4f5f6f7f8f9fafbfcfdfeff.

То есть, массив байт для ключа следующий:
{0xff, 0xfe, 0xfd, ..., 0xee, 0xff}
Поправил, спасибо.
В общем, надо брать простые числа только из надёжных источников.


Ну рецепт стар как мир: надо использовать то, что называется 'доказуемая псевдослучайность', например выработка параметров с использованием криптографических функций хэширования с известными входными значениями. Вместе с параметрами публикуете алгоритм выработки и его начальные значения.
«гост89 типа вне закона с 1 января этого года,»

Отмечу, что ГОСТ 28147-89 никто не выводил (и пока не собирается) из действия, несмотря на ввод ГОСТ Р 34.12-2015.
Режим гаммирования, в одном потоке. Core i5-6500, AVX.

Частота 3.2 GHz, ничего необычного.
64 KB в кэш первого уровня заведомо не войдет.
А насчет длинных регистров и конвейеров — тут уж точно нужно к авторам презентации обратиться за комментариями…
Информация была представлена на CTCrypt, презентация выложена здесь: https://www.slideshare.net/secret/8AC2FSDNCZiyZv

О скоростях слайды начинаются с 45-го (из 55).

Подробности, полагаю, вполне можно запросить у авторов презентации.
Рекорд скорости для Кузнечика сейчас — чуть более 330 МБ/с, но это проприетарные решения от вендоров и рассказывать, как это сделано, «они конечно не будут»(с). Так что автору просто мегареспектище за статью. Надеюсь будут еще.
Круто! Спасибо за подробный анализ характеристик. Добавил ссылку
Прошу прощения за такую задержку с ответом. Вы правы, для добавления augmented нужно будет существенно менять этап выработки ключа — это будет уже другой протокол (учитывая изменения в этапе выработки, этап подтверждения также изменится, т.к. под HMAC нужно будет засовывать другие данные). Пока в разработке такого протокола потребности нет.
А что так наши алгоритмы однобоко представлены? Только один ГОСТ 28147-89, а Стрибог с Кузнечиком и подпись?
Спасибо! Сейчас добавим
С праздником!
На самом деле информации очень много. Например, есть целая монография Татьяны Соболевой «История шифровального дела в России», Бабаш и Шанкин «История криптографии», Бабаш «История защиты информации в России», очень много тематических статей Ларина, Шанкина и Столпакова в журналах Инсайд и BIS Journal и т.д. и т.п.

Ну и если строго говорить, то сегодняшняя дата знаменует рождение современной советской/российской криптографии, а самое давнее упоминание об официальном использовании шифров — это 18 августа (по новому стилю) 1633 года, когда патриарх Филарет издал указ об обязательном шифровании дипломатической переписки. Так что, корни российской криптографии уходят глубоко в древность :)
http://www.journal.ib-bank.ru/post/176
Чтобы прийти к общему знаменателю, я немного расширенно опишу, что такое 'augmented' для протоколов семейства PAKE. Суть augmented не в том, что сторона, пусть B, не знает пароль (в SESPAKE сторона B, строго говоря, тоже не знает пароль), а в том, что если противник взламывает B, то есть получает хранящееся там значение, то он не может с помощью этого значения аутентифицироваться на B от имени A.

В SESPAKE это условие не выполняется — противник просто пропустит этап вычисления Q_PW^A, а будет использовать значение Q_PW, полученное при взломе B (хотя, если противнику нужно аутентифицироваться с использование именно заданного интерфейса, например, терминала, то ему все-таки придется вынуть пароль PW из Q_PW^A). Поэтому, как Вы правильно заметили, SESPAKE в строгом смысле не является augmented. В некотором смысле его можно назвать nearly-augmented.

Примером augmented-протокола является протокол AugPAKE, который наряду с SESPAKE рассматривается в группе CFRG. В нем сторона B хранит g^PW, а стороне A необходимо знание именно PW для аутентификации на B. Поэтому, если противник узнает g^PW, вскрыв сервер, то он не сможет аутентифицироваться на B, т.к. для этого нужно знать строго именно PW.

Казалось бы, замечательное свойство, почему бы не делать все протоколы augmented?! Если вдуматься, то дополнительная защита, которую дает augmented, именно в случае протоколов семейства PAKE крайне слаба. Изначальный посыл PAKE протоколов состоит в том, что общий секрет малоэнтропийный, т.е. его легко перебрать. Поэтому в таких условиях кажется странным говорить о том, что в случае взлома стороны B и выведывания g^PW, противник не получает PW — он его просто подберет, что он может сделать, т.к. мы находимся в условиях PAKE-протокола. Поэтому в случае, например, AugPAKE данное свойство реально что-то дает, если после взлома сервера противнику необходимо немедленно на него аутентифицироваться — в этом случае у него просто не будет времени на перебор. Однако такой случай выглядит странно и не очевидно, что стоит создавать что-то специальное для того, чтобы обеспечить защиту в таком случае.

При спорных плюсах свойство augmented имеет следующие недостатки, которые покажем на примере AugPAKE:
1) Стороны A и B не симметричны — действия A и B существенно отличаются, что может стать негативным фактором при реализации.
2) AugPAKE требует большего количества вычислений на кривой, чем SESPAKE, именно из-за поддержки augmented. Если B — карточка, то трудоемкость действий B крайне важна.

Ответ на вопрос, можно ли добавить в SESPAKE свойство augmented, таков: 'добавить' augmented нельзя, т.к. нужно будет существенно менять протокол в той части, где вырабатывается ключ. То есть это будет уже не 'добавить', а 'сделать новый'.

По поводу использования усилений. В SESPAKE они уже используются — обратите внимание на то, что сторона A использует не сам PW, а F(PW,salt,2000). На самом деле, F — это и есть PBKDF2. salt передается от B к A именно так, как Вы написали. Нет никаких проблем в использовании не явно PW, а какой-то функции от PW. Однако это имеет какой-то смысл лишь в случае, когда необходимо учитывать угрозу взлома сервера. В этом случае 2000 итераций, заложенных в PBKDF2, позволят несколько усложнить противнику перебор. Использование salt защищает от методов типа rainbow-table, но не увеличивает перебор экспоненциально, т.к. salt известен противнику.
Здравствуйте!

Спасибо большое за комментарий, в будущих статьях постараемся. Что же касается текущей – если интересен псевдокод/код по самому SESPAKE, Вам всегда помогут авторы документа ТК26/драфта RFC — адреса указаны в драфте.

Information

Rating
Does not participate
Registered
Activity