Комментарии 32
НЛО прилетело и опубликовало эту надпись здесь
1. Возможны, но при условии, что злоумышленник имеет доступ к машине. При эксплуатации шифратора предполагается, что такой возможности нет
.
2. Согласен.
3. Давайте разберемся.
Для корректного сравнения скорости, необходимо учитывать частоту процессора (Xeon E5-2697 v3 @ 2,6 ГГц vs Core Duo E8500 @ 3,1 ГГц), а также позаботится об отключении технологий Intel — SpeedStep и Turbo Boost (нет в Core Duo E8500). Более-менее универсальной мерой производительности шифрования/сжатия является единица измерения «такт на байт» для одного ядра ЦП — эти данные для различных реализаций ГОСТ приведены в статье. Необходимо также учитывать, что скорость одного и того же кода на разных микроархитектурах ЦП может быть различна. Численные данные, приведённые в статье, характеризуют максимальную пропускную способность платформы с включённой технологией Intel Hyper-threading. Еще раз повторюсь, что эта технология «позволяет увеличить суммарную скорость платформы на 30 % при 50%-ном снижении скорости на один поток».
Касательно приведённых Вами данных, в частности относительно алгоритма AES — у вас либо ошибка или опечатка, и вот почему. В стандарте AES количество раундов при обработке блока данных зависит от длины ключа: 10 раундов для ключа 128 бит, 12 раундов для ключа 192 бит и 14 раундов для ключа 256 бит. Какой бы ни был у Вас процессор, при переходе от 128 бит к 256 бит необходимо будет выполнить на 40 % больше операций, что вызовет падение в скорости на 40%. Ваши данный для AES-xxx xxx 128 быстрее всего на 20% относительно AES-xxx xxx 256.
Да, ГОСТ отстает от AES-256 при реализации с помощью таблиц, но не намного – это я покажу далее.
4. Да.
В любом случаи, был бы Вам признателен, если вы проведете тестирование ГОСТ на своем процессоре (например реализации из OpenSSL) и выложите свои результаты здесь.
.
2. Согласен.
3. Давайте разберемся.
Для корректного сравнения скорости, необходимо учитывать частоту процессора (Xeon E5-2697 v3 @ 2,6 ГГц vs Core Duo E8500 @ 3,1 ГГц), а также позаботится об отключении технологий Intel — SpeedStep и Turbo Boost (нет в Core Duo E8500). Более-менее универсальной мерой производительности шифрования/сжатия является единица измерения «такт на байт» для одного ядра ЦП — эти данные для различных реализаций ГОСТ приведены в статье. Необходимо также учитывать, что скорость одного и того же кода на разных микроархитектурах ЦП может быть различна. Численные данные, приведённые в статье, характеризуют максимальную пропускную способность платформы с включённой технологией Intel Hyper-threading. Еще раз повторюсь, что эта технология «позволяет увеличить суммарную скорость платформы на 30 % при 50%-ном снижении скорости на один поток».
Касательно приведённых Вами данных, в частности относительно алгоритма AES — у вас либо ошибка или опечатка, и вот почему. В стандарте AES количество раундов при обработке блока данных зависит от длины ключа: 10 раундов для ключа 128 бит, 12 раундов для ключа 192 бит и 14 раундов для ключа 256 бит. Какой бы ни был у Вас процессор, при переходе от 128 бит к 256 бит необходимо будет выполнить на 40 % больше операций, что вызовет падение в скорости на 40%. Ваши данный для AES-xxx xxx 128 быстрее всего на 20% относительно AES-xxx xxx 256.
Да, ГОСТ отстает от AES-256 при реализации с помощью таблиц, но не намного – это я покажу далее.
4. Да.
В любом случаи, был бы Вам признателен, если вы проведете тестирование ГОСТ на своем процессоре (например реализации из OpenSSL) и выложите свои результаты здесь.
Увеличение скорости шифрования может также подразумевать увеличение скорости дешифрования. Как по-вашему, этот алгоритм еще не устарел? Если еще у него запас по стойкости, связанной с увеличением скорости?
НЛО прилетело и опубликовало эту надпись здесь
Я-то как раз слышал, что ГОСТ во многом привлекателен именно из-за скорости (по сравнению с конкурирующими шифрами). Что по этой причине его предпочитают некоторые буржуи. Ошибался? AES оптимизируется лучше?
НЛО прилетело и опубликовало эту надпись здесь
Есть такое, подробно об этом изложил инициатор проекта GostCrypt Eric Filiol в своем докладе на Рускрипто’2014
Все просто: в том же трукрипте по сравнению с каскадом типа «serpent-twofish» (или любых иных относительно экзотических блочных алгоритмов) ГОСТ действительно быстр, а чистый AES всех уделывает исключительно благодаря аппаратной поддержке aes-ni, которая сейчас встроена почти повсюду. По крайней мере, ни thinkpad, ни макбук без AES NI вот уже несколько лет купить очень затруднительно.
Вообще, к моему сожалению, на Хабре удивительно мало толковых статей про ГОСТ, а ведь учитывая политические события последних лет (я имею в виду конфронтацию России и США) алгоритм получается весьма перспективный, особенно если вы живете и ведете экономическую деятельность не в России.
Спасибо автору статьи за побужденный интерес — завтра же спрошу у нашего безопасника пару глупых вопросов, типа, какой рекомендуется размер ключа для шифрования документов «совершенно секретно» и какие алгоритмы ассиметричного шифрования применяются, например, в дипломатических миссиях РФ.
Вообще, к моему сожалению, на Хабре удивительно мало толковых статей про ГОСТ, а ведь учитывая политические события последних лет (я имею в виду конфронтацию России и США) алгоритм получается весьма перспективный, особенно если вы живете и ведете экономическую деятельность не в России.
Спасибо автору статьи за побужденный интерес — завтра же спрошу у нашего безопасника пару глупых вопросов, типа, какой рекомендуется размер ключа для шифрования документов «совершенно секретно» и какие алгоритмы ассиметричного шифрования применяются, например, в дипломатических миссиях РФ.
НЛО прилетело и опубликовало эту надпись здесь
и какие алгоритмы ассиметричного шифрования применяются, например, в дипломатических миссиях РФ.
А почему вы думаете, что там ассиметричное? Для больших данных симметричное упомянутым ГОСТ-ом; а вот ключи для него уже генерируются ассиметричными алгоритмами и схемами на эллиптических кривых над полем Галуа. Все ГОСТы, кроме упомянутого 28147-89, как раз под это обновили к 2012-му. К тому же надо разделять то, что информация может идти от дипломатов в центр, а может выдаваться центром дипломатам в зависимости от их доступа. Вот ко второй задаче ещё спаривание Вейля (Weil pairing) или что-то подобное должно подходить. Впрочем, вряд ли это вам кто подробно расскажет.
Нет, AES не лучше оптимизируется. Просто за последние 10 лет AES получил аппаратную поддержку в различных микропроцессорах и стал стандартом де-факто для мира. Если подробно рассмотреть набор инструкций Intel AES-NI, окажется что для получения скорости шифрования >1 ГБ на ядро используется мультиблочная техника.
Посчитаем насколько ГОСТ 28147-89 медленней AES-256. Будем исходить из того, что оба алгоритма реализованы с помощью таблиц (T-table). При такой реализации алгоритмов, самой медленной операцией будет обращение в память. ГОСТ обрабатывает данные блоками по 64 бит, а AES по 128 бит. Кол-во раундов при обработке одного блока данных с помощью ГОСТ равно 32-м, а для AES-256 – 14-и. ГОСТ в 1 раунде 4 раза обращается к таблице, AES – 16. Посчитаем сколько обращений к памяти необходимо ГОСТ для обработки 128 бит информации: 2 блока x (32 раунда x 4 выборки из таблицы) = 256 обращений к памяти. Тоже самое рассчитаем для AES-256: 1 блок x (14 раундов x 16 выборок из таблицы) = 224 обращений к памяти. Получается, что AES-256 требует на 15% меньше обращений к памяти, чем ГОСТ 28147-89.
Вы совершенно правы – для ГОСТ 28147-89 скорость шифрования и дешифрования одинаковы. Устарел, но запас прочности еще остался. И именно поэтому этот алгоритм включён в проект нового стандарта «ГОСТ Блочные Шифры». Подробности на сайте ТК 26.
С реализацией шифрования ГОСТа на FPGA, случайно, не сравнивали? По скорости/энергопотреблению?
Нет, не сравнивал, но скоро такая возможность появится – наша компания работаем в данном направлении. К сожалению, очень мало практических публикаций по реализации ГОСТ на FPGA. Или я что-то упустил? Если да – поделитесь информацией.
По энергопотреблению однозначно FPGA лучше. По скорости не все так однозначно. Частота FPGA ~1 ГГц. Через какую шину она будет взаимодействовать с ЦП? или будет все сама обрабатывать?
По энергопотреблению однозначно FPGA лучше. По скорости не все так однозначно. Частота FPGA ~1 ГГц. Через какую шину она будет взаимодействовать с ЦП? или будет все сама обрабатывать?
Зависит от того, как сделать. :)
Можно, например, с процом взаимодействовать через PCIe (как и GPU): заливать туда обьемы данных, FPGA шифрует и отдает обратно.
Если хочется Ethernet шифровать сразу, то можно Ethernet завести на FPGA и сразу пакетики шифровать/дешифровать. Либо даже совместить это и сделать свою 10G/40G сетевую карточку на FPGA [либо купить готовый кит, и написать под нее софт] с шифрованием.
На opencores.org есть две корки ГОСТа, можно их собрать под топовые чипы и посмотреть производительность. И если не устроить, то писать их самим :)
Можно, например, с процом взаимодействовать через PCIe (как и GPU): заливать туда обьемы данных, FPGA шифрует и отдает обратно.
Если хочется Ethernet шифровать сразу, то можно Ethernet завести на FPGA и сразу пакетики шифровать/дешифровать. Либо даже совместить это и сделать свою 10G/40G сетевую карточку на FPGA [либо купить готовый кит, и написать под нее софт] с шифрованием.
На opencores.org есть две корки ГОСТа, можно их собрать под топовые чипы и посмотреть производительность. И если не устроить, то писать их самим :)
Раз у Вас целая компания этим занимается, то может быть вы в курсе, почему никто из отечественных лидеров индустрии не занимается стандартизацией ГОСТов в TLS? По крайней мере об этом в TLS WG нет ни слова за последние годы.
Стандартизацией ГОСТ-ов в TLS занимается Технический Комитет №26 (ТК26). В этот комитет входят лидеры индустрии ИБ – «ИнфоТеКС», «Крипто-Про», «Код Безопасности». На сайте комитета можно найти методические документы для использования российских криптографических алгоритмов в протоколе TLS.
Стандартизацией TLS занимается TLS WG. ТК-26 стандартизует какой-то свой TLS с ГОСТом, блэкджеком и дамами, потому что в TLS WG об этом ни слуху, ни духу. А именно отсутствием работы c TLS WG объясняется полное отсутствие поддержи ГОСТов в известных реализациях TLS, отсутствия поддержки в браузерах и существование таких вот уродов. И использование ГОСТа никогда не станет массовым, пока его поддержка не будет прозрачной.
Не в прозрачности дело – стандарты и методические рекомендации открыты. Для включения российских алгоритмов в TLS, ТК26 взаимодействует с IANA, которая взаимодействует с IETF. Другое дело, почему ГОСТ алгоритмы для TLS не были внесены в реестр «TLS Cipher Suite». Скорее всего, это связанно с неудачной попыткой сертификации старых алгоритмов (ГОСТ 28147-89, ГОСТ 34.11-94, ГОСТ 34.10-2001) в ISO. Но ситуация может измениться с принятием нового стандарта на шифрование в дополнение к уже действующим стандартам ГОСТ 34.11-2012 и ГОСТ 34.10-2012.
> Не в прозрачности дело
Под прозрачностью я имел ввиду прозрачность для юзера: чтобы для работы с ГОСТом не требовалось специальным образом собранных браузеров, целой тьмы плагинов и так далее. Именно так это выглядит сейчас. Сейчас юзеры Хрома начнут верещать, что у них перестали работать эти плагины, т.к. в 42-й версии гугл отключил по-умолчанию поддержку плагинов через API Mozilla. А скоро выпилит её совсем.
> методические рекомендации открыты
Ну на сайте ТК-26 они только на русском. Это не серьезно.
> ТК26 взаимодействует с IANA, которая взаимодействует с IETF
Черновику им. Чудова уже седьмой год. С тех пор никаких подвижек и даже попыток.
> ситуация может измениться с принятием нового стандарта на шифрование
Пока это даже у нас не стандарт.
На носу принятие нового браузерного API www.w3.org/TR/WebCryptoAPI. Про ГОСТ там тоже ничего не слышно. Хотя, казалось бы, это отличное решение для того, чтобы похоронить эту бешенную армию плагинов.
Под прозрачностью я имел ввиду прозрачность для юзера: чтобы для работы с ГОСТом не требовалось специальным образом собранных браузеров, целой тьмы плагинов и так далее. Именно так это выглядит сейчас. Сейчас юзеры Хрома начнут верещать, что у них перестали работать эти плагины, т.к. в 42-й версии гугл отключил по-умолчанию поддержку плагинов через API Mozilla. А скоро выпилит её совсем.
> методические рекомендации открыты
Ну на сайте ТК-26 они только на русском. Это не серьезно.
> ТК26 взаимодействует с IANA, которая взаимодействует с IETF
Черновику им. Чудова уже седьмой год. С тех пор никаких подвижек и даже попыток.
> ситуация может измениться с принятием нового стандарта на шифрование
Пока это даже у нас не стандарт.
На носу принятие нового браузерного API www.w3.org/TR/WebCryptoAPI. Про ГОСТ там тоже ничего не слышно. Хотя, казалось бы, это отличное решение для того, чтобы похоронить эту бешенную армию плагинов.
А какие вам практические публикации нужны? как s-box маппить на LUTы? Или может как арифметическое сложение либо XOR вручную в базисе И-НЕ описать? Отдайте это дело на откуп синтезатору и не страдайте ерундой — он уже давно научился использовать ресурсы конкретного семейства ПЛИС, под которую вы проводите синтез. Единственное правило, которое надо помнить — стиль кодирования на Verilog, который допустит синтезатор на оптимизацию вашего RTL-описания при компиляции исходников. Плюс надо определиться на начальном этапе что вы хотите получить — максимум производительности или минимум потребления/площади (во втором случае конвейерную структуру необходимо свернуть в цикл — использовать один раун (каскад) с простейшей FSM).
Это была преамбула, далее — сама «практическая публикация», так сказать: OpenSource HDL Implementation of GOST 28147-89
Лицензия — BSD, пользуйтесь на здоровье, даже в свой ASIC или SoC можете запихать.
Из фич:
— Проверенный на FPGA синтезируемый и верифицированный дизайн
— Выбор режима (шифрование/дешифрование) осуществляется налету при работе блока
— Раунды свёрнуты в цикл — IP-ядро оптимизировано по потреблению/занимаемой площади (полный цикл шифрования занимает 32 тактовых сигнала)
— Поддержка двух наборов S-блоков ГОСТ Р34.11-94 и RFC5830, можно синтезировать с поддержкой одновременно двух и переключением из налету
Из дальнейших планов:
— Прикручивание процессорной шины (Intel/Motorola либо Wishbone, возможно ARM AMBA)
— Реализация оставшихся режимов поточного шифрования: CBC, CFB, OFB, CTR (в соответствии с NIST SP 800-38A)
— Рефакторинг верификационной среды: использование библиотеки Botan в качестве Golden Model и тестирование RTL-кода через DPI интерфейс SystemVerilog'a
Это была преамбула, далее — сама «практическая публикация», так сказать: OpenSource HDL Implementation of GOST 28147-89
Лицензия — BSD, пользуйтесь на здоровье, даже в свой ASIC или SoC можете запихать.
Из фич:
— Проверенный на FPGA синтезируемый и верифицированный дизайн
— Выбор режима (шифрование/дешифрование) осуществляется налету при работе блока
— Раунды свёрнуты в цикл — IP-ядро оптимизировано по потреблению/занимаемой площади (полный цикл шифрования занимает 32 тактовых сигнала)
— Поддержка двух наборов S-блоков ГОСТ Р34.11-94 и RFC5830, можно синтезировать с поддержкой одновременно двух и переключением из налету
Из дальнейших планов:
— Прикручивание процессорной шины (Intel/Motorola либо Wishbone, возможно ARM AMBA)
— Реализация оставшихся режимов поточного шифрования: CBC, CFB, OFB, CTR (в соответствии с NIST SP 800-38A)
— Рефакторинг верификационной среды: использование библиотеки Botan в качестве Golden Model и тестирование RTL-кода через DPI интерфейс SystemVerilog'a
НЛО прилетело и опубликовало эту надпись здесь
Мне кажется на 750 видеокарте не поддерживается двунаправленная загрузка / выгрузка. Соответственно схема не подходит для все ГПУ =)
И я думаю вряд ли производительность ГПУ линейно масштабируется, там очень много факторов.
У самого есть возможность прогнать алгоритм на GTX Titan и Xeon E5 v2, если код конечно не секретен =) а еще интересно посмотреть на оптимальность кода на ГПУ
И я думаю вряд ли производительность ГПУ линейно масштабируется, там очень много факторов.
У самого есть возможность прогнать алгоритм на GTX Titan и Xeon E5 v2, если код конечно не секретен =) а еще интересно посмотреть на оптимальность кода на ГПУ
Вы правы. В представленных «дешёвых» GPU от AMD и NVidia есть только один канал DMA. Эти GPU предназначены в первую очередь для отображения 3D картинки на мониторе, а с этой задачей прекрасно справляется и один канал DMA. По этому, предложенная схема на них не работает (соответственно и результаты ниже).
Но наличие двух каналов DMA еще не гарантирует успех – необходима поддержка со стороны драйверов. Тот же Intel HD 2500 использует шину Ring Bus, к которой подключаются все ядра CPU, но выигрыша в производительности это не дает. Скорее всего, в этом случаи виноваты драйвера.
Код является «коммерческой тайной».
Но наличие двух каналов DMA еще не гарантирует успех – необходима поддержка со стороны драйверов. Тот же Intel HD 2500 использует шину Ring Bus, к которой подключаются все ядра CPU, но выигрыша в производительности это не дает. Скорее всего, в этом случаи виноваты драйвера.
Код является «коммерческой тайной».
самый новый драйвер от NVIDIA и CUDA 7.0 поддерживает данный механизм. Другое дело — что быстрее: вычисление или передача. Скорее всего вычисления пролетают быстро, тем самым алгоритм в хорошем случае должен сводиться к копированию и выгрузке данных. Еще хотел добавить:
если алгоритм использует мало данных или вообще сохраняет их только для выгрузки/загрузки, то можно вообще не использовать глобальную память, загружая данные прямо с ЦПУ через L2 в ядро. Также можно делать и с выгрузкой. Этот механизм называется UMA или как то так. В общем передаете указатель на память ЦПУ и обращаетесь к нему как к массиву в ядре. Тогда эти ваши стадии скорее всего не понадобятся.
если алгоритм использует мало данных или вообще сохраняет их только для выгрузки/загрузки, то можно вообще не использовать глобальную память, загружая данные прямо с ЦПУ через L2 в ядро. Также можно делать и с выгрузкой. Этот механизм называется UMA или как то так. В общем передаете указатель на память ЦПУ и обращаетесь к нему как к массиву в ядре. Тогда эти ваши стадии скорее всего не понадобятся.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Шифрование ГОСТ 28147-89 на х86- и GPU-процессорах