Спасибо большое за очень дельный комментарий! О возможности шифровать элементы группы мы написать хотели, но, признаться, не хватило времени.
С шифрованием g^a есть важная проблема. Если вы возьмете «боевую» используемую для практике группу – группу точек эллиптической кривой – то каждый элемент (точка кривой) будет иметь вид (x,y), где x и y связаны уравнением кривой. Если вы зашифруете данную точку на ключе, выведенном из пароля, то возможно будет, перебирая пароли оффлайн, найти те, для которых результат расшифрования является корректной точкой кривой. Если не вводить дополнительной компрессии (писать x и один бит, соответствующий «знаку» y, что возможно для ряда кривых), то пароль по E(g^a) можно будет за одно наблюдение восстановить мгновенно и однозначно. Если применять, то критерии для отбраковки все равно останутся (пусть и более слабые) и по наблюдению за одной пересылкой (в каждой сессии протокола их будет минимум две) можно будет получать отбраковку части парольного множества. 10-15 наблюдений за протоколом – и пароль угадан.
Поэтому в случае шифрования будет принципиально важно использование высокоэнтропийных секретов, а не паролей, а в нашем случае как раз приходится «замешивать» пароль в той же группе, что и основные преобразования.
Ответил кратко, так что если получилось не вполне ясно, буду рад внести любые пояснения и уточнения.
Конечно, аргументированно ответить на подобные обвинения и обосновать, что «не верблюд», невозможно, но повторимся, что обоснования стойкости в статье по ссылке приводятся в абсолютном случае, без дополнительных предположений (которые можно было бы истолковать как «если нет закладок»).
Из конкретики – предлагаю Вам обратить внимание на часть данной заметки, посвященную важности выбора порождающих элементов с заведомо неизвестными друг относительно друга логарифмами. Более удобного и правильного места для внедрения закладок, чем формирование элемента h с известным дискретным логарифмом, в протоколе нет – в этом случае как раз только авторы разработки смогли бы получать (при некоторых моделях нарушителя) доступ к ключу, что было бы весьма правильной «закладкой». Мы специально останавливаемся на этом месте (а в документе ТК 26 и в драфте RFC отдельно приводятся прообразы хэшей порождающих элементов), так как подобные Вашему намеки о возможных закладках, увы, были ожидаемы.
Как организован процесс рецензирования трудов? Есть ли возможность слепого рецензирования? Рассылка докладов по рецензентам?
Выставление рейтинговых оценок? Ранжирование работ по поставленным оценкам? Рассылка рецензий докладчикам? Как в iChair или EasyChair? Это самое главное в системе управления конференцией.
Именно что Магма как базовое преобразование — это в точности ГОСТ 28147-89. Суть проблемы с пониманием тут ровно в том, что базовое преобразование шифра и его режимы работы (а для прикладника эти вещи в принципе не особо разделимы) — все же разные вещи. Простой тезис: в режиме ECB Магма в точности эквивалентна ГОСТ 28147-89 с узлами замены ТК 26 Z.
Во-первых, просьба сменить тон общения на более спокойный, не нужно нервничать.
Во-вторых, никто ни разу не говорил, что от старого ГОСТа были унаследованы режимы работы. Хоть ГОСТ Р 34.12-2015 и совпадает с ГОСТ 28147-89 в версии «Магма», но режим имитовставки в ГОСТ Р 34.13-2015 введен другой. Кроме того, другой в ГОСТ Р 34.13-2015 используется и режим гаммирования.
В-третьих, насчет реализации на сайте ТК 26, все же давайте не путать стандарты и тестовые реализации. Если видите ошибку, так потратьте чуток времени, напишите авторам. Поверьте, никто ошибочную реализацию отстаивать не будет, если ошибки и впрямь есть.
По поводу RFC, авторы всех российских проектов всегда будут рады критике. Навскидку, сейчас по линии IETF у российских коллег идет работа по двум проектам RFC: по сопутствующим алгоритмам и по протоколу SESPAKE. Присоединяйтесь, пишите авторам на почту, критикуйте, предлагайте коррективы – участвуйте.
1) HMAC на базе ГОСТ Р 34.11-94 описан в RFC 4357, в документе ТК 26 описывается исключительно HMAC на основе ГОСТ Р 34.11-2012. Уточните, пожалуйста, где была ошибка и в чем заключалась.
2) Вы правы в том, что в настоящий момент процесс избыточно закрыт. Но полную открытость обеспечивать тоже вредно – сотни школьников в комментариях утопили не одно благое дело с обсуждениями документов. А если Вы работаете в сфере ИБ и есть желание подключиться к процессу – это нетрудно сделать через секретариат ТК 26.
3) Вы в чем-то, конечно, правы, учитывая количество ошибочных из-за переворота байтов реализаций — даже крупные компании (не будем называть конкретно) предварительные релизы своих продуктов выпускали с подобными ошибками. Но, как я прокомментировал ниже, оба варианта указания данных имеют проблемы.
1) Про тестовые примеры. Есть ошибочные контрольные примеры в ТК26TLS, изменения в документе с исправленными примерами должны быть утверждены на весеннем заседании ТК 26. Вы где-то еще ошибки находили?
2) Не могли бы Вы уточнить по поводу «корявости» документов? Практика создания документов «патчей» к стандартам (как ТК26TLS) себя изживает, новые документы ТК 26 создаются самодостаточными (ТК26АЛГ, ТК26ECC, ТК26SESPAKE). Какие есть предложения?
3) Магма, как неоднократно озвучивалось, это ГОСТ 28147-89 с фиксированными узлами замены из ТК26УЗ.
Все тестовые данные в новых стандартах, действительно, приведены «с переворотом байтов». Ошибкой (с формальной точки зрения) это не является, так как в начале стандарта в обозначениях это явно указано. Удобно это или нет? Для реализации, разумеется, нет (приходится переворачивать все входы и выходы), для формальной корректности стандарта и упрощения описания – в чем-то удобно. Разумеется, Магма в точности совпадает с ГОСТ 28147-89 с узлами замены ТК26-Z из соответствующих Рекомендаций ТК-26.
Весьма много разработчиков первые реализации новых ГОСТов выкатывают ошибочные, с переворотом байтов. Так что определенная проблема, действительно, есть, но рекомендация тут только одна — внимательно читать стандарт.
В документах ТК 26, замечу, все данные в основном приведены в little-endian, без переворотов. Но из-за этого в тексте иногда встречаются неочевидные обозначения.
Да ну вы что. От формы записи результат не меняется. Там в начале стандарта написано как и что читать. Алгоритм тот же самый, только подстановки другие.
По поводу контрольных примеров погуглите про little и big endian.Магма отличается только фиксированным набором подстановок. В новом стандарте просто развернули порядок байтов в описании для 'унификации' с международными стандартами.
Написал так потому, что и 2001й и 2012й ГОСТы это по сути одна и та же схема. Например в ISO/IEC 14888-3 наша ЭЦП описана безотносительно к размерам (хотя есть численные примеры есть для 256 и для 512). Но формально вы правы.
Добавьте в обзор последние результаты по анализу протокола MTProto: eprint.iacr.org/2015/1177.pdf. В этой работе показано, что данный протокол не является стойким в модели IND-CCA, т.е. возможно любой шифртекст преобразовать в некоторый другой шифртекст, который может быть расшифрован в исходный открытый текст. Несмотря на то, что атака теоретическая, авторы рекомендуют все-таки не использовать самопальные решения, а реализовывать хорошо проверенные конструкции, ну и предлагают изменить протокол, чтобы атака не проходила.
Можно ответить просто, но без раскрытия сути: вырабатывается так, чтобы представлять реализацию равномерно распределенной на соответствующем множестве случайной величины.
Но суть здесь все же другая. Шифр не может использоваться «в вакууме» – процедура выработки ключа шифрования решается на более высоком уровне – уровне криптографических протоколов.
В открытом доступе таких требований ФСБ, конечно, нет.
Четкость требований в таких вопросах в принципе невозможна – как и четкость формулировок свыше общих «стойкость к атакам по побочным каналам».
Я говорил о том, что сертифицировать криптосредство, время операции с ключом в котором будет давать существенную информацию о ключе, вы не сможете. Надеюсь, и не захотите.
Но и здесь от размытости формулировок («существенную») не уйти.
«А в остальном, большая дилемма: сделать чтобы код выполнялся за 0,001 секунды но вот с такими тайминг особенностями или сделать чтобы он выполнялся за постоянное время, пусть даже 1 секунду.»
Во-первых, боюсь, Вы все же существенно преувеличиваете. Как Вы понимаете, аспекты реализации ГОСТ Р 34.10-2001/ГОСТ Р 34.10-2012 и ECDSA практически не отличаются, а вопросы быстродействия в обоих случаях сводятся, в первую очередь, к грамотному выбору методов вычисления кратной точки.
Так вот я не могу привести пример адекватного метода защиты от атак по побочному каналу по времени, которые бы замедляли время работы в тысячу раз. Вопросы построения безопасных реализаций российских криптоалгоритмов регулярно обсуждаются на РусКрипто и CTCrypt, о разнице в три десятичных порядка, к счастью, речь никогда не заходит.
Если Вам подобные методы известны, будем благодарны, если расскажете.
Во-вторых, описанная Вами дилемма может возникать исключительно в двух случаях: написания криптобиблиотечки «для себя»/студентом для сдачи практикума либо в случае написания специальной реализации криптографии для специфичной задачи внутри закрытой со всех сторон системы. В случае же, когда криптографические механизмы планируется применять в широком спектре реальных систем (для которых нельзя раз и навсегда дать гарантии отсутствия нарушителя, имеющего доступ к информации о времени работы), пренебрегать побочкой по времени совершенно недопустимо. И я говорю даже не о сертификации криптосредств (не суть важно по чему — по требованиям ФСБ или по FIPS), а об элементарной ответственности за свой код.
«Про атаки на RSA в деталях не читал, думаю там тоже была заранее известная реализация (те исследователи знали как она шумит и как это интерпретировать) и контроль на входные данные.»
Разумеется, всё противодействие атакам по побочным каналам обязано производиться в предположении, что код реализации нарушителю известен.
Спасибо большое за очень дельный комментарий! О возможности шифровать элементы группы мы написать хотели, но, признаться, не хватило времени.
С шифрованием g^a есть важная проблема. Если вы возьмете «боевую» используемую для практике группу – группу точек эллиптической кривой – то каждый элемент (точка кривой) будет иметь вид (x,y), где x и y связаны уравнением кривой. Если вы зашифруете данную точку на ключе, выведенном из пароля, то возможно будет, перебирая пароли оффлайн, найти те, для которых результат расшифрования является корректной точкой кривой. Если не вводить дополнительной компрессии (писать x и один бит, соответствующий «знаку» y, что возможно для ряда кривых), то пароль по E(g^a) можно будет за одно наблюдение восстановить мгновенно и однозначно. Если применять, то критерии для отбраковки все равно останутся (пусть и более слабые) и по наблюдению за одной пересылкой (в каждой сессии протокола их будет минимум две) можно будет получать отбраковку части парольного множества. 10-15 наблюдений за протоколом – и пароль угадан.
Поэтому в случае шифрования будет принципиально важно использование высокоэнтропийных секретов, а не паролей, а в нашем случае как раз приходится «замешивать» пароль в той же группе, что и основные преобразования.
Ответил кратко, так что если получилось не вполне ясно, буду рад внести любые пояснения и уточнения.
Конечно, аргументированно ответить на подобные обвинения и обосновать, что «не верблюд», невозможно, но повторимся, что обоснования стойкости в статье по ссылке приводятся в абсолютном случае, без дополнительных предположений (которые можно было бы истолковать как «если нет закладок»).
Из конкретики – предлагаю Вам обратить внимание на часть данной заметки, посвященную важности выбора порождающих элементов с заведомо неизвестными друг относительно друга логарифмами. Более удобного и правильного места для внедрения закладок, чем формирование элемента h с известным дискретным логарифмом, в протоколе нет – в этом случае как раз только авторы разработки смогли бы получать (при некоторых моделях нарушителя) доступ к ключу, что было бы весьма правильной «закладкой». Мы специально останавливаемся на этом месте (а в документе ТК 26 и в драфте RFC отдельно приводятся прообразы хэшей порождающих элементов), так как подобные Вашему намеки о возможных закладках, увы, были ожидаемы.
Выставление рейтинговых оценок? Ранжирование работ по поставленным оценкам? Рассылка рецензий докладчикам? Как в iChair или EasyChair? Это самое главное в системе управления конференцией.
Писать по стандартам ГОСТ Р 34.1х-2015 можно на находящийся в ведении ИнфоТеКСа секретариат ТК 26 (лучше сразу попросить перенаправить на конкретных авторов), по документам по сопутствующим алгоритмам и SESPAKE – например, напрямую Станиславу Смышляеву из КРИПТО-ПРО (кстати, утвержденные российские версии документов по алгоритмам и по SESPAKE ТК 26 выложило на своем сайте).
Во-вторых, никто ни разу не говорил, что от старого ГОСТа были унаследованы режимы работы. Хоть ГОСТ Р 34.12-2015 и совпадает с ГОСТ 28147-89 в версии «Магма», но режим имитовставки в ГОСТ Р 34.13-2015 введен другой. Кроме того, другой в ГОСТ Р 34.13-2015 используется и режим гаммирования.
В-третьих, насчет реализации на сайте ТК 26, все же давайте не путать стандарты и тестовые реализации. Если видите ошибку, так потратьте чуток времени, напишите авторам. Поверьте, никто ошибочную реализацию отстаивать не будет, если ошибки и впрямь есть.
По поводу RFC, авторы всех российских проектов всегда будут рады критике. Навскидку, сейчас по линии IETF у российских коллег идет работа по двум проектам RFC: по сопутствующим алгоритмам и по протоколу SESPAKE. Присоединяйтесь, пишите авторам на почту, критикуйте, предлагайте коррективы – участвуйте.
2) Вы правы в том, что в настоящий момент процесс избыточно закрыт. Но полную открытость обеспечивать тоже вредно – сотни школьников в комментариях утопили не одно благое дело с обсуждениями документов. А если Вы работаете в сфере ИБ и есть желание подключиться к процессу – это нетрудно сделать через секретариат ТК 26.
3) Вы в чем-то, конечно, правы, учитывая количество ошибочных из-за переворота байтов реализаций — даже крупные компании (не будем называть конкретно) предварительные релизы своих продуктов выпускали с подобными ошибками. Но, как я прокомментировал ниже, оба варианта указания данных имеют проблемы.
1) Про тестовые примеры. Есть ошибочные контрольные примеры в ТК26TLS, изменения в документе с исправленными примерами должны быть утверждены на весеннем заседании ТК 26. Вы где-то еще ошибки находили?
2) Не могли бы Вы уточнить по поводу «корявости» документов? Практика создания документов «патчей» к стандартам (как ТК26TLS) себя изживает, новые документы ТК 26 создаются самодостаточными (ТК26АЛГ, ТК26ECC, ТК26SESPAKE). Какие есть предложения?
3) Магма, как неоднократно озвучивалось, это ГОСТ 28147-89 с фиксированными узлами замены из ТК26УЗ.
Все тестовые данные в новых стандартах, действительно, приведены «с переворотом байтов». Ошибкой (с формальной точки зрения) это не является, так как в начале стандарта в обозначениях это явно указано. Удобно это или нет? Для реализации, разумеется, нет (приходится переворачивать все входы и выходы), для формальной корректности стандарта и упрощения описания – в чем-то удобно. Разумеется, Магма в точности совпадает с ГОСТ 28147-89 с узлами замены ТК26-Z из соответствующих Рекомендаций ТК-26.
Весьма много разработчиков первые реализации новых ГОСТов выкатывают ошибочные, с переворотом байтов. Так что определенная проблема, действительно, есть, но рекомендация тут только одна — внимательно читать стандарт.
В документах ТК 26, замечу, все данные в основном приведены в little-endian, без переворотов. Но из-за этого в тексте иногда встречаются неочевидные обозначения.
Но суть здесь все же другая. Шифр не может использоваться «в вакууме» – процедура выработки ключа шифрования решается на более высоком уровне – уровне криптографических протоколов.
Довольно много на эту тему было сказано на недавней конференции в Яндексе по вопросам использования российской криптографии.
Четкость требований в таких вопросах в принципе невозможна – как и четкость формулировок свыше общих «стойкость к атакам по побочным каналам».
Я говорил о том, что сертифицировать криптосредство, время операции с ключом в котором будет давать существенную информацию о ключе, вы не сможете. Надеюсь, и не захотите.
Но и здесь от размытости формулировок («существенную») не уйти.
«А в остальном, большая дилемма: сделать чтобы код выполнялся за 0,001 секунды но вот с такими тайминг особенностями или сделать чтобы он выполнялся за постоянное время, пусть даже 1 секунду.»
Во-первых, боюсь, Вы все же существенно преувеличиваете. Как Вы понимаете, аспекты реализации ГОСТ Р 34.10-2001/ГОСТ Р 34.10-2012 и ECDSA практически не отличаются, а вопросы быстродействия в обоих случаях сводятся, в первую очередь, к грамотному выбору методов вычисления кратной точки.
Так вот я не могу привести пример адекватного метода защиты от атак по побочному каналу по времени, которые бы замедляли время работы в тысячу раз. Вопросы построения безопасных реализаций российских криптоалгоритмов регулярно обсуждаются на РусКрипто и CTCrypt, о разнице в три десятичных порядка, к счастью, речь никогда не заходит.
Если Вам подобные методы известны, будем благодарны, если расскажете.
Во-вторых, описанная Вами дилемма может возникать исключительно в двух случаях: написания криптобиблиотечки «для себя»/студентом для сдачи практикума либо в случае написания специальной реализации криптографии для специфичной задачи внутри закрытой со всех сторон системы. В случае же, когда криптографические механизмы планируется применять в широком спектре реальных систем (для которых нельзя раз и навсегда дать гарантии отсутствия нарушителя, имеющего доступ к информации о времени работы), пренебрегать побочкой по времени совершенно недопустимо. И я говорю даже не о сертификации криптосредств (не суть важно по чему — по требованиям ФСБ или по FIPS), а об элементарной ответственности за свой код.
«Про атаки на RSA в деталях не читал, думаю там тоже была заранее известная реализация (те исследователи знали как она шумит и как это интерпретировать) и контроль на входные данные.»
Разумеется, всё противодействие атакам по побочным каналам обязано производиться в предположении, что код реализации нарушителю известен.