Comments 47
Заранее извиняюсь за, возможно, тупой вопрос. Я не специалист по криптографии. Но меня волнует вопрос — чем этот алгоритм лучше существующих мировых аналогов?
Сложно что-то сказать о криптостойкости алгоритма по сравнению с зарубежными аналогами, шифр сравнительно новый и пока мало исследован. На мой взгляд, он во многом похож на AES, выглядит очень крепко, очевидных слабых мест в нем нет.
В России более важными вопросами являются вопросы сертификации средств защиты информации; и с средствами, использующими зарубежную криптографию, вы попросту не пройдете сертификацию в органах. Поэтому здесь выбора особо и нет.
Если для работы, то эти алгоритмы по ГОСТУ нужны, например, для работы, образно говоря, с секретными документами (банковская сфера, финансовая, военка и т.д. и т.п.).
Если для поиграться, то есть, например, такой подход: житель России используй AES (или другой зарубежный шифр), житель США — используй какой-нибудь ГОСТ.
Если для поиграться, то есть, например, такой подход: житель России используй AES (или другой зарубежный шифр), житель США — используй какой-нибудь ГОСТ.
А меня вот другое интересует.
Разработка средств шифрования — в России это лицензируемый вид деятельности.
Стоимость лицензий от 350 тыс. рублей.
Но не знаю, что это значит. Если как вы говорите «поиграться» и я вставляю всем известный алгоритм (хоть ГОСТ, хоть AES/RC5/RC6) в свою программу — это я нарушаю какие-то законы или нет?
Или не нарушаю никаких законов то того момента пока государство не купит мою программу? Или как?
А если программа просто использует протокол https — это требует лицензии?
Может конечно глупый вопрос…
Разработка средств шифрования — в России это лицензируемый вид деятельности.
Стоимость лицензий от 350 тыс. рублей.
Но не знаю, что это значит. Если как вы говорите «поиграться» и я вставляю всем известный алгоритм (хоть ГОСТ, хоть AES/RC5/RC6) в свою программу — это я нарушаю какие-то законы или нет?
Или не нарушаю никаких законов то того момента пока государство не купит мою программу? Или как?
А если программа просто использует протокол https — это требует лицензии?
Может конечно глупый вопрос…
100% не нарушаете, если у вас длина ключа менее 56бит.
Ну а вообще — разработка и применение готового алгоритма это разные вещи.
Если начнёте продавать программу/устройства — как минимум вам светит статья «незаконное предпринимательство».
Ну и из опыта — любые операции с информацией, не представляющей гостайну, оказанные в рамках «для собственных нужд», допускаются к использованию на предприятии. Например я могу сам установить криптопро на предприятии, для этого не нужна лицензия ФСБ.
немного почитать
Ну а вообще — разработка и применение готового алгоритма это разные вещи.
Если начнёте продавать программу/устройства — как минимум вам светит статья «незаконное предпринимательство».
Ну и из опыта — любые операции с информацией, не представляющей гостайну, оказанные в рамках «для собственных нужд», допускаются к использованию на предприятии. Например я могу сам установить криптопро на предприятии, для этого не нужна лицензия ФСБ.
немного почитать
А если программа просто использует протокол https — это требует лицензии?
В любом случае, лучше занять очередь в пятницу, что бы по раньше освободится в субботу!
по оплате, насколько я понял из доклада Вартана Хачатурова (ссылка ниже) — оплачивать нужно только если сам занимаешься лицензируемым видом деятельности. ГОСТ можно хоть куда вставлять, это опенсорс в чистом виде.
Или не нарушаю никаких законов то того момента пока государство не купит мою программу? Или как?Не знаю как сейчас, но 10 лет назад, когда я последний раз с этим сталкивался можно было использовать хоть чёрта лысого если не произносить запрещённых слов.
В частности в системе, которую использовали на выборах (уж куда государственнее?) использовался GnuPGP с некоторыми изменениями в названиях сигнатур (без измнения алгоритмов, конечно). В документация вся эта хрень с ключами на 4096 бит и прочим проходила как «фирменный модуль повышения надёжности передачи данных и обнаружения несанцкионированных изменений» (или что-то в этом духе, точное название сейчас не скажу).
Главное — не заявлять что вы что-то там шифруете и что-то там гарантируете. Как только вы это заявили — всё, требуются сертификаты и прочее. При работе с госструктурами иногда такие заявления нужны, иногда — нет.
Лицензируется коммерческая разработка средств шифрования, здесь все слова важные.
Если вы для себя пилите (и не только поиграться, но и реально использовать в рамках своей организации) — это не лицензируется.
Если вы пилите продукт, но он опенсорс или вы просто (пока) его не продаёте в РФ — лицензия не нужна.
Лицензируется именно разработка продукта (программ и возможно железок). Алгоритмы тут как бы сбоку, пока вы не выходите на продажи в госсектор — вы можете брать любые.
Если ваш продукт нигде не называется «средством шифрования» и ничего такого не обещает — лицензия не нужна.
Ну и наконец вопрос с получением лицензии не в деньгах, точнее не в сумме 350 тыс. Во-первых, там с документами тот ещё геморрой, вы на картриджи для ксерокса, нотариуса и затраты времени гендиректора, который будет по этим нотариусам с банками бегать два месяца, потратите не сильно меньше. А во-вторых, у вас в штате (именно в штате, всё в белую) должно быть как минимум 2 инженера с высшим (возможно, вторым высшим) конкретно по специальности ИБ, причём никакие смежные специальности не допускаются. Та же кафедра ИУ8 в Бауманке очень неплохо зарабатывает именно на получающих второе высшее по данной теме. И ваши расходы на их содержание в штате по-белому превысят те 350 тысяч за то время, пока оформляется лицензия.
Если вы для себя пилите (и не только поиграться, но и реально использовать в рамках своей организации) — это не лицензируется.
Если вы пилите продукт, но он опенсорс или вы просто (пока) его не продаёте в РФ — лицензия не нужна.
Лицензируется именно разработка продукта (программ и возможно железок). Алгоритмы тут как бы сбоку, пока вы не выходите на продажи в госсектор — вы можете брать любые.
Если ваш продукт нигде не называется «средством шифрования» и ничего такого не обещает — лицензия не нужна.
Ну и наконец вопрос с получением лицензии не в деньгах, точнее не в сумме 350 тыс. Во-первых, там с документами тот ещё геморрой, вы на картриджи для ксерокса, нотариуса и затраты времени гендиректора, который будет по этим нотариусам с банками бегать два месяца, потратите не сильно меньше. А во-вторых, у вас в штате (именно в штате, всё в белую) должно быть как минимум 2 инженера с высшим (возможно, вторым высшим) конкретно по специальности ИБ, причём никакие смежные специальности не допускаются. Та же кафедра ИУ8 в Бауманке очень неплохо зарабатывает именно на получающих второе высшее по данной теме. И ваши расходы на их содержание в штате по-белому превысят те 350 тысяч за то время, пока оформляется лицензия.
Это вообще скользкая тема, год назад интересовался. Смотрим пункт 3 постановления РФ от 16 апреля 2012 г. № 313, там перечень в каких случаях не распространяется.
Если вы используете программу для «внутренних или личных нужд», то использовать можно что угодно. Если же вы эту программу продаете, то попадает под перечень лицензируемых видов деятельности. Конкретно: «Разработка защищенных с использованием шифровальных (криптографических) средств информационных систем».
Ну и у отдельных типов финансовых учреждений уже свои правила на этот счет.
Для себя выделил несколько вариантов, когда изучал как вставить ЭЦП на борту криптотокена в коммерческую систему:
1) Самостоятельное получение лицензии ФСБ со всеми вытекающими последствиями;
2) Само приложение поставлять без криптозащиты. Ее подключать в виде отдельного модуля с помощью пользователя и/или посредника. При этом модуль в таком случае должен разрабатываться и распространяться отдельно посредником, имеющим лицензию. Поставлять модуль необходимо отдельно от основного приложения. Другими словами: использовать услуги другой стороны;
3) Использовать простую подпись без криптографии, например усиленную смс-подтверждением. При этом нужно формировать соглашение между сторонами обмена о том, что такая подпись признается юридически значимой. А в суде факт формирования такой подписи осуществляется проверкой логов сервера и др. согласно условиям соглашения.
4) Использовать средства СКЗИ встроенные в ОС. (под закон не попадает)
5) Осуществлять подпись не на территории РФ. (Электронные подписи, созданные в соответствии с нормами права иностранного государства и международными стандартами признаются юридически значимыми согласно законодательству РФ)
6) Не использовать криптографию и ЭЦП вовсе.
Самое смешное, что чтобы просто передать систему с критотокеном клиенту, курьер должен пройти курсы повышения квалификации.
Нет, https не требует лицензирования.
Поправьте если не прав, не юрист
Если вы используете программу для «внутренних или личных нужд», то использовать можно что угодно. Если же вы эту программу продаете, то попадает под перечень лицензируемых видов деятельности. Конкретно: «Разработка защищенных с использованием шифровальных (криптографических) средств информационных систем».
Ну и у отдельных типов финансовых учреждений уже свои правила на этот счет.
Для себя выделил несколько вариантов, когда изучал как вставить ЭЦП на борту криптотокена в коммерческую систему:
1) Самостоятельное получение лицензии ФСБ со всеми вытекающими последствиями;
2) Само приложение поставлять без криптозащиты. Ее подключать в виде отдельного модуля с помощью пользователя и/или посредника. При этом модуль в таком случае должен разрабатываться и распространяться отдельно посредником, имеющим лицензию. Поставлять модуль необходимо отдельно от основного приложения. Другими словами: использовать услуги другой стороны;
3) Использовать простую подпись без криптографии, например усиленную смс-подтверждением. При этом нужно формировать соглашение между сторонами обмена о том, что такая подпись признается юридически значимой. А в суде факт формирования такой подписи осуществляется проверкой логов сервера и др. согласно условиям соглашения.
4) Использовать средства СКЗИ встроенные в ОС. (под закон не попадает)
5) Осуществлять подпись не на территории РФ. (Электронные подписи, созданные в соответствии с нормами права иностранного государства и международными стандартами признаются юридически значимыми согласно законодательству РФ)
6) Не использовать криптографию и ЭЦП вовсе.
Самое смешное, что чтобы просто передать систему с критотокеном клиенту, курьер должен пройти курсы повышения квалификации.
Нет, https не требует лицензирования.
Поправьте если не прав, не юрист
Да я тоже не юрист.
Но мне как-то странно, что вот строится целая законодательная глыба по лицензированию, криптографии, все строго и серьезно и тот вдруг раз «https» — можно. Хотя тот же https — это серьезное шифрование с серьезными целями и т.д.
Строгость российских законов компенсируется необязательностью их исполнения.
Но мне как-то странно, что вот строится целая законодательная глыба по лицензированию, криптографии, все строго и серьезно и тот вдруг раз «https» — можно. Хотя тот же https — это серьезное шифрование с серьезными целями и т.д.
Строгость российских законов компенсируется необязательностью их исполнения.
Могу и обмануть, это только моё мнение:
Вся эта глыба документов применяется только в тот момент, когда вы говорите, что реализовали криптографию и гарантируете это.
Т. е. если информация относится к защищаемой согласно закону, например, персональные данные, то требуется доказуемая с точки зрения органов гарантия.
Для этого и есть лицензирование, сертификация и прочие радости, предназначенные для подтверждения этих гарантий.
Если же это не требуется, то всё использование алгоритмов шифрования и подписей — это просто меры, направленные на безопасность, но не гарантирующие её (с точки зрения органов).
TL;DR: Использовать криптографию можно, нельзя говорить, что она есть и что-то гарантирует.
Здесь сначала нужно определиться, что такое «лучше» для алгоритма шифрования, и относительно интересов кого это «лучше» отсчитывается.
И вот для системных (=используемых на уровне государства и выше) шифров единственное разумное «лучше» — это пуленепробиваемая стойкость.
Ну, представьте, что некто взломал шифр, которым банки подписывают сообщения о переводе денег. И теперь может лепить поддельные сообщения на тему «ооо ромашка переводит ооо вектор сто тыщь миллионов». Хотя у «ромашки», возможно, таких денег отродясь не было, сообщение подписано банком ромашки и будет исполнено. Представили? Это мгновенный крах банковской системы и моментальная остановка экономики страны, потому как другого способа перевода крупных сумм, кроме как через банки, сегодня нет.
Потенциальные векторы угроз стойкости шифров можно разделить на три больших класса:
1. Баги реализации в конкретной библиотеке. Ну, из недавно нашумевшего — история с хартблидом в либе OpenSSL. Поскольку либа популярная, пострадали очень многие. Такие ситуации неприятны, но лечатся относительно легко: патчем либы либо переходом на более другую библиотеку. Сам стандарт тут не при чём и его не трогают.
2. Баги в алгоритме, которые делают возможным взлом шифра на обычном ПК или хотя бы на мощном суперкомпьютере. Пример: первые алгоритмы шифрования в сетях GSM. Лечится очень тяжело: нужно менять алгоритм, нужно внедрять новый алгоритм вообще везде, а это очень много времени и денег. Современные смартфоны, например, всё ещё несут на борту старые алгоритмы шифрования на случай, если где-то ещё встречаются старые базовые станции, и наоборот. Если удастся взломать одно или другое, можно вынудить вторую, невзломанную железку перейти на старый шифр, после чего перехват разговора становится делом техники.
Для защиты от подобных атак, кстати, помогает тактика неуловимого Джо. При прочих равных лучше иметь свой алгоритм, просто потому что он не самый распространённый в мире, и его будут тупо реже пытаться взламывать.
3. Сознательно внесённые в шифр бэкдоры. Есть обоснованное мнение, что все вот эти якобы случайные таблицы коэффициентов — нифига не случайны, и к ним есть «мастер ключ», резко снижающий стоимость вскрытия перебором. То есть хакер Вася или там Джон обламает зубы на ультрасложном матане и нехватке вычислительных мощностей, но вот заказчики бэкдора в погонах смогут при необходимости прочитать или подделать нужное сообщение. Точно не все подряд сообщения в потоке, но как минимум нужные им для конкретной злодейской задачи.
Звучит как теория заговора, но здесь можно много всего вспомнить, от наездов федералов на pgp до откровений Сноудена и продуктов жизнедеятельности Яровой.
И защита от таких бэкдоров на уровне государства может быть только одна — свои алгоритмы со своими православными бэкдорами.
И вот для системных (=используемых на уровне государства и выше) шифров единственное разумное «лучше» — это пуленепробиваемая стойкость.
Ну, представьте, что некто взломал шифр, которым банки подписывают сообщения о переводе денег. И теперь может лепить поддельные сообщения на тему «ооо ромашка переводит ооо вектор сто тыщь миллионов». Хотя у «ромашки», возможно, таких денег отродясь не было, сообщение подписано банком ромашки и будет исполнено. Представили? Это мгновенный крах банковской системы и моментальная остановка экономики страны, потому как другого способа перевода крупных сумм, кроме как через банки, сегодня нет.
Потенциальные векторы угроз стойкости шифров можно разделить на три больших класса:
1. Баги реализации в конкретной библиотеке. Ну, из недавно нашумевшего — история с хартблидом в либе OpenSSL. Поскольку либа популярная, пострадали очень многие. Такие ситуации неприятны, но лечатся относительно легко: патчем либы либо переходом на более другую библиотеку. Сам стандарт тут не при чём и его не трогают.
2. Баги в алгоритме, которые делают возможным взлом шифра на обычном ПК или хотя бы на мощном суперкомпьютере. Пример: первые алгоритмы шифрования в сетях GSM. Лечится очень тяжело: нужно менять алгоритм, нужно внедрять новый алгоритм вообще везде, а это очень много времени и денег. Современные смартфоны, например, всё ещё несут на борту старые алгоритмы шифрования на случай, если где-то ещё встречаются старые базовые станции, и наоборот. Если удастся взломать одно или другое, можно вынудить вторую, невзломанную железку перейти на старый шифр, после чего перехват разговора становится делом техники.
Для защиты от подобных атак, кстати, помогает тактика неуловимого Джо. При прочих равных лучше иметь свой алгоритм, просто потому что он не самый распространённый в мире, и его будут тупо реже пытаться взламывать.
3. Сознательно внесённые в шифр бэкдоры. Есть обоснованное мнение, что все вот эти якобы случайные таблицы коэффициентов — нифига не случайны, и к ним есть «мастер ключ», резко снижающий стоимость вскрытия перебором. То есть хакер Вася или там Джон обламает зубы на ультрасложном матане и нехватке вычислительных мощностей, но вот заказчики бэкдора в погонах смогут при необходимости прочитать или подделать нужное сообщение. Точно не все подряд сообщения в потоке, но как минимум нужные им для конкретной злодейской задачи.
Звучит как теория заговора, но здесь можно много всего вспомнить, от наездов федералов на pgp до откровений Сноудена и продуктов жизнедеятельности Яровой.
И защита от таких бэкдоров на уровне государства может быть только одна — свои алгоритмы со своими православными бэкдорами.
Звучит как теория заговора, но здесь можно много всего вспомнить, от наездов федералов на pgp до откровений Сноудена и продуктов жизнедеятельности Яровой.А не проще вспомнить реальную историю?
Звучит как теория заговора, но здесь можно много всего вспомнить, от наездов федералов на pgp
А вот GnuPG на ГОСТ-ах:
Сказание о Клеопатре и о российской криптографии
Есть хорошее свежее видео " для непосвященных" про алгоритмы ГОСТ — доклад Вартана Хачатурова, OSSDEVCONF-2016. Автор — сборщик дебиана, криптоэнтузиаст и чиновник минкомсвязи :-)
Там вопрос мировых аналогов, закладок и всяческих мифов разобран довольно подробно.
https://vimeo.com/185219716
Там вопрос мировых аналогов, закладок и всяческих мифов разобран довольно подробно.
https://vimeo.com/185219716
Надо спрашивать — чем он лучше предыдущего ГОСТа.
В свете сведений, опубликованных Сноуденом (о том, как NSA пропихивает для использования заведомо слабые алгоритмы) вопрос про мировые аналоги лучше не задавать.
Он лучше предыдущего ГОСТа (не говоря уж о DES) как минимум тем, что длина ключа намного длиннее, и «подслушать» этот ключ становится намного сложнее (по «колебаниям мирового эфира»). При сертификации аппаратных средств шифрования это один из самых сложных тестов.
В свете сведений, опубликованных Сноуденом (о том, как NSA пропихивает для использования заведомо слабые алгоритмы) вопрос про мировые аналоги лучше не задавать.
Он лучше предыдущего ГОСТа (не говоря уж о DES) как минимум тем, что длина ключа намного длиннее, и «подслушать» этот ключ становится намного сложнее (по «колебаниям мирового эфира»). При сертификации аппаратных средств шифрования это один из самых сложных тестов.
UFO just landed and posted this here
Сначала для «пешеходов» наверное будет полезно про кузнечик от юного, но уже внятного поколения криптографов, экспертов ТК26 — «ГОСТ Р 34.12–2015: чего ожидать от нового стандарта?» — http://www.itsec.ru/articles2/crypto/gost-r-chego-ozhidat-ot-novogo-standarta/
Пару слов про качество СТРИБОГа. На семинаре в Bristol Univ однажды была дискуссия по TUAK,
который исходно прописан под KECCAK (SHA-3). Было также краткое обсуждение об инкапсуляции 34.11-2012 в конструкции TUAK = {TOPc; f1; f1*; f2; f3; f4; f5; f5*}, на что Teng Wu (Waterloo) классно заметил, что и SHA-3 и GOST примерно одинаково неидеальны, ну типа mert (fr), но вполне пригодны:-)
Пару слов про качество СТРИБОГа. На семинаре в Bristol Univ однажды была дискуссия по TUAK,
который исходно прописан под KECCAK (SHA-3). Было также краткое обсуждение об инкапсуляции 34.11-2012 в конструкции TUAK = {TOPc; f1; f1*; f2; f3; f4; f5; f5*}, на что Teng Wu (Waterloo) классно заметил, что и SHA-3 и GOST примерно одинаково неидеальны, ну типа mert (fr), но вполне пригодны:-)
Всё стою на камне, —
Дай-ка брошусь в море.
Что пошлёт судьба мне,
Радость или горе?
Может, озадачит…
Может, не обидит…
Ведь кузнечик скачет,
А куда — не видит.
Козьма Прутков. Пред морем житейским.
UFO just landed and posted this here
Попробовал собрать проект под Visual Studio 12 2013 (MSVC 18.0.40629.0), собралось с двумя незначительными правками. В benchmark.cpp добавил:
Без него компилятор ругался на std::generate_n… а в optimised.c добавил:
Может быть есть и более «красивое» решение для сборки под MSVC…
#ifdef _MSC_VER
#include <algorithm>
#endif
Без него компилятор ругался на std::generate_n… а в optimised.c добавил:
#ifdef _MSC_VER
#define restrict __restrict
#endif
Может быть есть и более «красивое» решение для сборки под MSVC…
Первое исправление надо добавлять независимо от компилятора, потому что функция std::generate_n и правда находится в <algorithm>
@Decker, mayorovp Спасибо, ошибку с <algorithm> исправил.
UFO just landed and posted this here
Скорость всё равно печальная.
У госта 89 чуточку лучше: http://www.securitylab.ru/analytics/480357.php
Автор этой статьи, Андрей Луценко, обладает рядом патентов на скоростную реализацию ГОСТ 28147 '89, ему экономически выгодно пиарить прежний стандарт шифрования.
Если же объективно говорить о производительности скоростных версий шифров на одной и той же платформе, то результаты оказались примерно следующие: ~170 МБ/с на поток для Магмы и ~150 МБ/с на поток для Кузнечика.
Ещё лучше хотя бы опционально использовать _mm_stream_load_si128() из SSSE3 для загрузки блока данных
За наводку на _mm_stream_load_si128 спасибо, попробую.
Рекорд скорости для Кузнечика сейчас — чуть более 330 МБ/с, но это проприетарные решения от вендоров и рассказывать, как это сделано, «они конечно не будут»(с). Так что автору просто мегареспектище за статью. Надеюсь будут еще.
@ru_crypt, уточните, 330 МБ/с в одном потоке? Какой процессор? Какой режим? Какой набор инструкций?
Не могу представить себе способа еще почти втрое алгоритмически ускорить базовое преобразование. Думаю, что такие скорости достижимы при
- мощном процессоре с высокой тактовой частотой,
- наличии кэша первого уровня в 64 КБ (тогда в него вся таблица войдет),
- использовании более длинных регистров и конвейерном шифровании.
Информация была представлена на CTCrypt, презентация выложена здесь: https://www.slideshare.net/secret/8AC2FSDNCZiyZv
О скоростях слайды начинаются с 45-го (из 55).
Подробности, полагаю, вполне можно запросить у авторов презентации.
О скоростях слайды начинаются с 45-го (из 55).
Подробности, полагаю, вполне можно запросить у авторов презентации.
Режим гаммирования, в одном потоке. Core i5-6500, AVX.
Частота 3.2 GHz, ничего необычного.
64 KB в кэш первого уровня заведомо не войдет.
А насчет длинных регистров и конвейеров — тут уж точно нужно к авторам презентации обратиться за комментариями…
Частота 3.2 GHz, ничего необычного.
64 KB в кэш первого уровня заведомо не войдет.
А насчет длинных регистров и конвейеров — тут уж точно нужно к авторам презентации обратиться за комментариями…
«гост89 типа вне закона с 1 января этого года,»
Отмечу, что ГОСТ 28147-89 никто не выводил (и пока не собирается) из действия, несмотря на ввод ГОСТ Р 34.12-2015.
Отмечу, что ГОСТ 28147-89 никто не выводил (и пока не собирается) из действия, несмотря на ввод ГОСТ Р 34.12-2015.
Как дела обстоят с закладками в шифре? надеялся увидеть этот пункт есть они или нет.
@shifttstas Если они есть, мы об этом не узнаем ;)
https://eprint.iacr.org/2015/812.pdf
@AleksGRV Не осилили пост? В ней про структуру узлов замены написан целый раздел, даже ссылка на более полную работу представлена.
Но даже известное устройство узлов замены не могу назвать закладкой шифра, ведь полученные таким способом узлы обладают действительно хорошими криптографическими свойствами, и очевидным образом использовать эту структуру для дешифрования шифртекста или определения цикловых ключей я не вижу.
Со всеми оптимизациями скорости хотелось бы услышать что-нибудь про тайминг-атаки.
Полагаю, что можно устроить атаки, аналогичные описанным здесь; время загрузки очередного слагаемого Xi на очередном цикле шифрования прямо зависит от значения соответствующего байта промежуточного текста.
По ссылке, как я понял, авторы утверждают, что косяк в самом алгоритме AES, а не в какой-то его конкретной реализации. Мой вопрос относился именно к проблемам, которые всплывают из-за оптимизации/ускорения работы алгоритма.
Я вам ответил именно на ваш вопрос ;) ГОСТ во многом похож на AES; можно устроить очень похожие атаки на время загрузки векторов из таблиц, оно прямо зависит от значений байт промежуточного текста. Таблицы появляются только в оптимизированной версии шифра. В теории, при известном открытом тексте и точном способе измерять это время, можно попробовать определить байты первых двух цикловых ключей (половин секретного ключа). Но это тема отдельной статьи.
Не очень понятно, зачем было оптимизировать полную схему преобразования на «полноформатном» процессоре, когда давно уже известна оптимизация (от какого-то горячего финского парня, исходники бродят по сети), позволяющая свести операцию к небольшому количеству операций исключающее-или с константами из относительно небольшого массива (64к для шифрования и 192к для дешифрования, если мне не изменяет память).
В таком варианте переложение алгоритма на SSE инструкции дают порядка >200Mb/s на каком-то core i5, на котором я пробовал. Да и то, думаю, скорость упирается в скорость обмена с памятью, сама скорость выполнения операции XOR на порядки выше.
Впрочем, это имеет определённый смысл как упражнение в программировании, а также как тренировку перед имплементацией алгоритма для более слабых процессоров, у которых 256к таблиц не влезает в кэш.
В таком варианте переложение алгоритма на SSE инструкции дают порядка >200Mb/s на каком-то core i5, на котором я пробовал. Да и то, думаю, скорость упирается в скорость обмена с памятью, сама скорость выполнения операции XOR на порядки выше.
Впрочем, это имеет определённый смысл как упражнение в программировании, а также как тренировку перед имплементацией алгоритма для более слабых процессоров, у которых 256к таблиц не влезает в кэш.
Не утрудитесь ссылочкой на оптимизацию, о которой вы говорите? Ведь в посте полный цикл как раз сводится к небольшому количеству (15) операций исключающее ИЛИ (XOR) с константами из небольшого массива (64 КБ для шифрования и 64 КБ для расшифрования).
Не дочитал Вашу статью до конца, уж извините. Дошёл до формул и подумал что дальше Вы по ними оптимизацию на SSE делаете :)
Вот исходники, аж от 14го года
https://github.com/mjosaarinen/kuznechik
Насчёт 192к я соврал, это суммарный размер таблицы для шифрования и дешифрования.
Таблицы дешифрования занимают 128к (две таблицы по 64к), таблицы шифрования занимают 64к.
Шифрование несколько медленнее (но не в два раза, как можно было бы подумать :))
Если при дешифровании Вы сумели обойтись всего одной таблицой в 64к, тогда Ваша статья заслуживает более глубокого изучения :)
Вот исходники, аж от 14го года
https://github.com/mjosaarinen/kuznechik
Насчёт 192к я соврал, это суммарный размер таблицы для шифрования и дешифрования.
Таблицы дешифрования занимают 128к (две таблицы по 64к), таблицы шифрования занимают 64к.
Шифрование несколько медленнее (но не в два раза, как можно было бы подумать :))
Если при дешифровании Вы сумели обойтись всего одной таблицой в 64к, тогда Ваша статья заслуживает более глубокого изучения :)
Кстати, подумалось, что «секретная» структура узла замены на самом деле просто реверс-инжиниринг формулы самопального генератора псевдослучайных последовательностей, которой воспользовались авторы алгоритма для генерации узла замены :)
Sign up to leave a comment.
ГОСТ Р 34.12 '15 на SSE2, или Не так уж и плох Кузнечик