Search
Write a publication
Pull to refresh

Comments 32

UFO landed and left these words here
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) и выложите свои результаты здесь.
UFO landed and left these words here
Увеличение скорости шифрования может также подразумевать увеличение скорости дешифрования. Как по-вашему, этот алгоритм еще не устарел? Если еще у него запас по стойкости, связанной с увеличением скорости?
UFO landed and left these words here
Я-то как раз слышал, что ГОСТ во многом привлекателен именно из-за скорости (по сравнению с конкурирующими шифрами). Что по этой причине его предпочитают некоторые буржуи. Ошибался? AES оптимизируется лучше?
UFO landed and left these words here
Есть такое, подробно об этом изложил инициатор проекта GostCrypt Eric Filiol в своем докладе на Рускрипто’2014
Все просто: в том же трукрипте по сравнению с каскадом типа «serpent-twofish» (или любых иных относительно экзотических блочных алгоритмов) ГОСТ действительно быстр, а чистый AES всех уделывает исключительно благодаря аппаратной поддержке aes-ni, которая сейчас встроена почти повсюду. По крайней мере, ни thinkpad, ни макбук без AES NI вот уже несколько лет купить очень затруднительно.

Вообще, к моему сожалению, на Хабре удивительно мало толковых статей про ГОСТ, а ведь учитывая политические события последних лет (я имею в виду конфронтацию России и США) алгоритм получается весьма перспективный, особенно если вы живете и ведете экономическую деятельность не в России.

Спасибо автору статьи за побужденный интерес — завтра же спрошу у нашего безопасника пару глупых вопросов, типа, какой рекомендуется размер ключа для шифрования документов «совершенно секретно» и какие алгоритмы ассиметричного шифрования применяются, например, в дипломатических миссиях РФ.
UFO landed and left these words here
Каскадное шифрование – не всегда это хорошо. Яркий тому пример – 3DES.
и какие алгоритмы ассиметричного шифрования применяются, например, в дипломатических миссиях РФ.


А почему вы думаете, что там ассиметричное? Для больших данных симметричное упомянутым ГОСТ-ом; а вот ключи для него уже генерируются ассиметричными алгоритмами и схемами на эллиптических кривых над полем Галуа. Все ГОСТы, кроме упомянутого 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.
Сравнение нелепое. Считать количество обращений к памяти и не учитывать кеш/специфику работы RAM == тыкать пальцем в потолок.
Вы совершенно правы – для ГОСТ 28147-89 скорость шифрования и дешифрования одинаковы. Устарел, но запас прочности еще остался. И именно поэтому этот алгоритм включён в проект нового стандарта «ГОСТ Блочные Шифры». Подробности на сайте ТК 26.
С реализацией шифрования ГОСТа на FPGA, случайно, не сравнивали? По скорости/энергопотреблению?
Нет, не сравнивал, но скоро такая возможность появится – наша компания работаем в данном направлении. К сожалению, очень мало практических публикаций по реализации ГОСТ на FPGA. Или я что-то упустил? Если да – поделитесь информацией.
По энергопотреблению однозначно FPGA лучше. По скорости не все так однозначно. Частота FPGA ~1 ГГц. Через какую шину она будет взаимодействовать с ЦП? или будет все сама обрабатывать?
Зависит от того, как сделать. :)
Можно, например, с процом взаимодействовать через PCIe (как и GPU): заливать туда обьемы данных, FPGA шифрует и отдает обратно.
Если хочется Ethernet шифровать сразу, то можно Ethernet завести на FPGA и сразу пакетики шифровать/дешифровать. Либо даже совместить это и сделать свою 10G/40G сетевую карточку на FPGA [либо купить готовый кит, и написать под нее софт] с шифрованием.

На opencores.org есть две корки ГОСТа, можно их собрать под топовые чипы и посмотреть производительность. И если не устроить, то писать их самим :)
UFO landed and left these words here
Раз у Вас целая компания этим занимается, то может быть вы в курсе, почему никто из отечественных лидеров индустрии не занимается стандартизацией ГОСТов в 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. Про ГОСТ там тоже ничего не слышно. Хотя, казалось бы, это отличное решение для того, чтобы похоронить эту бешенную армию плагинов.
А какие вам практические публикации нужны? как 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
UFO landed and left these words here
Мне кажется на 750 видеокарте не поддерживается двунаправленная загрузка / выгрузка. Соответственно схема не подходит для все ГПУ =)
И я думаю вряд ли производительность ГПУ линейно масштабируется, там очень много факторов.

У самого есть возможность прогнать алгоритм на GTX Titan и Xeon E5 v2, если код конечно не секретен =) а еще интересно посмотреть на оптимальность кода на ГПУ
Вы правы. В представленных «дешёвых» GPU от AMD и NVidia есть только один канал DMA. Эти GPU предназначены в первую очередь для отображения 3D картинки на мониторе, а с этой задачей прекрасно справляется и один канал DMA. По этому, предложенная схема на них не работает (соответственно и результаты ниже).

Но наличие двух каналов DMA еще не гарантирует успех – необходима поддержка со стороны драйверов. Тот же Intel HD 2500 использует шину Ring Bus, к которой подключаются все ядра CPU, но выигрыша в производительности это не дает. Скорее всего, в этом случаи виноваты драйвера.

Код является «коммерческой тайной».
самый новый драйвер от NVIDIA и CUDA 7.0 поддерживает данный механизм. Другое дело — что быстрее: вычисление или передача. Скорее всего вычисления пролетают быстро, тем самым алгоритм в хорошем случае должен сводиться к копированию и выгрузке данных. Еще хотел добавить:
если алгоритм использует мало данных или вообще сохраняет их только для выгрузки/загрузки, то можно вообще не использовать глобальную память, загружая данные прямо с ЦПУ через L2 в ядро. Также можно делать и с выгрузкой. Этот механизм называется UMA или как то так. В общем передаете указатель на память ЦПУ и обращаетесь к нему как к массиву в ядре. Тогда эти ваши стадии скорее всего не понадобятся.
Sign up to leave a comment.