С другой стороны (американской), появился AES-256, который показывал гораздо лучшие скоростные параметры при той же степени криптостойкости.
В этой ситуации 8 центр ФСБ начал работы над новым блочным шифром, который получил в последствии название «Кузнечик» от начальных букв фамилий авторов.
Изначально это была бесперспективная затея, поскольку повторялась логика шифра AES, но если тот был ускорен аппаратно в процессорах Интел и АМД, то у Кузнечика такого аппаратного ускорения на этих процессорах конечно быть не могло.
Так что Кузнечик, это классический пример выброшенных на ветер бюджетных денег и не малых…
Но был и другой вариант ускорения криптографических операций, он к сожалению не получил официальной поддержки в силу специфических причин. Этот вариант предполагал разработку алгоритмов реализации ГОСТ 28147-89 для многопоточности и доработку самого стандарта под требования многопоточности.
Многопоточность базируется на трех новых методах реализации ГОСТ 28147-89 в процессорах архитектуры х86-64.
Первый это конвейерная работа процессора в режиме шифрования. Второй это реализации блока замен на SSE/AVX командах процессора. Третий это использование специализированных регистров XMM/YMM/ZMM, имеющих разрядность 16/32/64 байта.
Эти новые методы в сумме позволили поднять быстродействие шифрования по ГОСТ 28147-89 как минимум на порядок и обеспечивать скоростные параметры шифрования ничуть не хуже американского AES-256, который использует специальный криптоускоритель в процессорах Интел/АМД.
Но, как говорится, бог шельму метит, а время расставляет все по своим законным местам.
В настоящее время шифр «Кузнечик» воспринимается как экзотика и не имеет практического применения из-за низкой скорости преобразований и сомнительной репутации, вместо него производители стали использовать многопоточное шифрование по ГОСТ 28147-89. Но об этом они стараются не говорить, поскольку знают, что нарушают авторские права.
Методы ускорения шифрования запатентованы.
Во многом из-за этого не было честных тестов на быстродействие разных систем шифрования, а в сетевых изданиях и на форумах гуляли всякие сказочные и абсолютно голословные цифры, ничего не имеющие общего с реальностью.
Поэтому и сложился устойчивый миф о превосходстве AES-256 над ГОСТ 28147-89 по скоростным параметрам чуть ли не в десяток раз…
Настало время провести честное тестирование.
Честные тесты
В статьях, посвященных криптографическим преобразованиям, приводятся разные «фантастические» данные по скорости работы криптофункции, очень много в этих цифрах лукавства. Мы же будем честными, никаких «синтетических» тестов, все «по-настоящему».
Шифрование по сути это служебный фоновый процесс. Криптопроцедура работает в фоне гораздо более важных задач и ситуация со 100% загрузкой процессора шифрованием это экзотика. Поэтому не будем ускорять криптофункцию за счет увеличения приоритета и числа используемых процессорных ядер, ограничим максимальную загрузку процессора криптофункцией уровнем в 15%.
В демонстрационной версии программы FastSecurityBoxs (собственная поделка, заинтересовавшимся просьба написать в комментарии) создание дампов дисков с шифрованием проводилось на четырех ядерном процессоре Skylake с частотой 2,6гГерца, гипертрейдинг активирован (всего 8 логических ядер). Криптопроцедура работает на одном логическом ядре (из 8 имеющихся), соответственно загрузка ЦП создаваемая им не превышает 12-15 процентов, что соответствует реальной работе фоновой задачи. Для копирования использовалось два SSD диска, скорость чтения/записи на них в режиме файловой системы составляет примерно 450-500Мбайт/сек. на очищенном устройстве, после выполнения TRIM.
Вот чистое копирование без криптографии:
Чтение секторов диска (ProjectFK.exe) занимают 5%, запись в файл (System) занимает 2% процессорного времени на скорости 449мбайт/сек. Запомним эти цифры, когда включим криптографию к ним будут добавляться затраты на криптопреобразования, соответственно можно будет оценить затраты на само криптопреобразование процессорной нагрузки.
Теперь, создавая дамп, включим криптографию. Сначала шифрование в 8 потоков по ГОСТ 28147-89:
Скриншот создания резервной копии дисков с использованием криптопреобразования строго по ГОСТ в 8 потоков.
Скорость реально создаваемого криптографического дампа 190мбайт/сек. Скорость ограничена криптопреобразованием, поскольку загрузка ЦП создаваемая программой ProjectFK.ехе составляет 12%, в нашем случае это предел по загрузке логического ядра процессора. SSD диски могут работать гораздо быстрее, но их тормозит ограничение на использование в криптопроцедуре только «половинки» одного физического ядра процессора.
На криптопреобразование в программе ProjectFK тратится 7% загрузки процессора.
Теперь шифрование в 16потоков по ГОСТ 28147-89:
Скриншот создания резервной копии дисков с использованием криптопреобразования строго по ГОСТ в 16 потоков. Этот режим работает эффективно только на процессорах Интел поколения Skylake и выше, но об этом будет сказано позже.
Скорость выросла до 334мБайт/сек. Загрузка ЦП 10,5%, здесь еще ограничение создает криптопреобразование, но загрузка на логическое процессорное ядро снижается.
На криптопреобразование в программе ProjectFK тратится 5.5% загрузки процессора.
Ну а что же может обеспечить американское шифрование AES? Возьмем самое продвинутое решение использующее этот шифр,- Битлокер. Функция шифрования встроена у него в ядро ОС и максимально оптимизирована, это вам не пользовательское приложение как FastSecurityBoxs, так что фора у него есть значительная…
Вот что дает Битлокер (AES-128 на 10 раундах ) когда идет создание дампа на зашифрованном диске:
Здесь программа ProjectFK.exe только создает дамп, этот дамп шифруется битлокером непосредственно в процессе System который записывает его на диск, соответственно нужно суммировать нагрузки процессора создаваемую обоими этими процессами. Нагрузка составляет 12,5 процентов процессорного времени на скорости создания шифрованного дампа 392Мбайт/сек.
На криптопреобразование в процессе System тратится 5% загрузки процессора.
Совсем не плохо, только нужно учитывать, что AES-128 не ровня ГОСТ 28147-89, они из разных весовых категорий криптостойкости.
«Сухой остаток» тестов
Шифрование по ГОСТ 28147-89 в фоновом режиме (5-7% загрузки ЦП), на скорости 200мбайт/сек., уже фантастика, эти параметры в реальных приложениях ни одна система, с аппаратно ускоренной AES-256 криптографией на 14 раундах обеспечить не в состоянии.
В режиме AES-128 на 10 раундах удается работать чуть быстрее, но криптостойкость этого алгоритма значительно ниже криптостойкости ГОСТ 28147-89 из-за вдвое меньшего размера ключа.
Констатируем очевидное. Криптографическая процедура по строгому ГОСТ 28147-89 в многопоточном варианте способна выполняться в фоновом режиме на скоростях 200-400мбайт/сек., загружая процессор всего на 5-7 процентов. Но ничто не мешает поднять скорости и выше, увеличив загрузку процессора.
Сертифицированное ФСБ средство криптографии по строгому ГОСТ 28147-89 может в многопоточном режиме обеспечивать фоновую шифрацию современных SSD и HDD дисков на интерфейсе SATA с загрузкой процессора этой операцией не более 7%. Это позволяет использовать ГОСТ 28147-89 в программах типа Битлокер даже более эффективно чем применяемый сейчас американский стандарт AES-128, но с гораздо более «сильной» криптографической защитой…
Для дисков на интерфейсе NVMe уже сейчас работающих на скоростях 2-3Гбайта/сек. и для сетей 10G/10G+ нужно увеличить скорость еще как минимум в два раза.
Тут есть два пути. Первый, пассивный путь уже опробован, когда переходили с 8 потоков на 16 потоков при реализации ГОСТ 28147-89. Можно подождать внедрения в процессора набора команд AVX-512. Эти команды оперируют с регистрами размером в 64 байта и могут обеспечить многопоточное выполнение по строгому ГОСТ 28147-89 сразу в 32 потоках. Что автоматически удвоит производительность криптофункции.
Здесь есть маленькое «но», процессора с поддержкой AVX-512 появятся только в следующем году, и команды AVX-512 будут сначала эмулироваться микропрограмно, а значит выполняться они будут очень медленно. Так медленно, что использование их в реальных программах бессмысленно.
Это мы уже видели на примере внедрения команд AVX2, между появлением этого набора команд и переводом его выполнением на аппаратный цикл прошло 3года. Только в 2016году Интел ввела аппаратную поддержку AVX2 команд на процессорах поколения Skylake.
Ждать когда Интел переведет AVX-512 на аппаратную реализацию нужно будет еще примерно 3 года…
Второй путь активный, он заключается в разработке нового алгоритма шифрования, изначально заточенного на многопоточность, ведь сейчас используется только малая часть потенциала параллельных вычислений.
Вот этим и займемся далее, не ждать же 3 года… Так что ожидайте в скором будущем третьего пришествия ГОСТ 28147-89.
Комментарии (5)
lorc
29.12.2016 17:54+4Извините, но ваше тестирование просто сравнивает ProjectFK с Bitlocker в конфигурации по умолчанию, ничего более.
Например, неизвестно каким криптопровайдером пользуется Bitlocker. Возможно он использует аппаратные средства по ускорению, а возможно и нет. Возможно он работает в 16 потоков, а возможно в 1.
Шифрование по ГОСТ 28147-89 в фоновом режиме (5-7% загрузки ЦП), на скорости 200мбайт/сек., уже фантастика, эти параметры в реальных приложениях ни одна система, с аппаратно ускоренной AES-256 криптографией на 14 раундах обеспечить не в состоянии.
Вы ошибаетесь. Я запустилlorc:libxc/ (4.8-demo?) $ openssl speed -evp aes-256-cbc
И вот что я вижу:
Вывод opensslDoing aes-256-cbc for 3s on 16 size blocks: 150827312 aes-256-cbc's in 3.00s
Doing aes-256-cbc for 3s on 64 size blocks: 41549881 aes-256-cbc's in 3.00s
Doing aes-256-cbc for 3s on 256 size blocks: 10406514 aes-256-cbc's in 3.00s
Doing aes-256-cbc for 3s on 1024 size blocks: 2625105 aes-256-cbc's in 3.00s
Doing aes-256-cbc for 3s on 8192 size blocks: 326447 aes-256-cbc's in 3.00s
OpenSSL 1.0.2g 1 Mar 2016
built on: reproducible build, date unspecified
options:bn(64,64) rc4(16x,int) des(idx,cisc,16,int) aes(partial) blowfish(idx)
compiler: cc -I. -I… -I../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wl,-Bsymbolic-functions -Wl,-z,relro -Wa,--noexecstack -Wall -DMD32_REG_T=int -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM
The 'numbers' are in 1000s of bytes per second processed.
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
aes-256-cbc 804412.33k 886397.46k 888022.53k 896035.84k 891417.94k
openssl speed -evp aes-256-cbc 15,00s user 0,00s system 99% cpu 15,009 total
Rend
30.12.2016 01:28производители стали использовать многопоточное шифрование по ГОСТ 28147-89. Но об этом они стараются не говорить, поскольку знают, что нарушают авторские права
Методы ускорения шифрования запатентованы.
Вы сказали «А», так скажите «Б». Вы обладатель патента? На какой-то конкретный метод? Интернет даёт предположить, что идёт разговор об этом алгоритме: Журнал «Хакер», 19.10.2013 (автор там не указан).
Но откуда вы взяли, что «производители» (непонятно, какие) используют данный конкретный алгоритм? Если он действительно является оригинальным, запатентованным, его незаконно скопировали и используют в коммерческих продуктах — подавайте в суд, закон на вашей стороне.
Или нарушение авторских прав — только предположение?
Ivan_83
30.12.2016 03:09+4Опять пьяное НЛО притащило какую то каку из песочницы, ах да, это же второе пришествие Крипто ГОСТ троля.
«Около десяти лет тому назад симметричная криптография, основанная на ГОСТ 28147-89, перестала удовлетворять потребностям аппаратных платформ по скоростным параметрам.» — Хз кого там что перестало удовлетворять 10 лет назад, ибо ГОСТ89 в то время был мало кому нужен.
«С другой стороны (американской), появился AES-256, который показывал гораздо лучшие скоростные параметры при той же степени криптостойкости.» — Одна бабка сказала, да?
«Изначально это была бесперспективная затея, поскольку повторялась логика шифра AES, но если тот был ускорен аппаратно в процессорах Интел и АМД, то у Кузнечика такого аппаратного ускорения на этих процессорах конечно быть не могло.»
Да, только вот AES-NI появился даже не 10 лет назад, а гораздо меньше.
При этом, всем кому было нужно по работе — могли купить аппаратный ускоритель крипты, хоть для aes хоть для госта.
«Многопоточность базируется на трех новых методах реализации ГОСТ 28147-89 в процессорах архитектуры х86-64.
Первый это конвейерная работа процессора в режиме шифрования.
Второй это реализации блока замен на SSE/AVX командах процессора.
Третий это использование специализированных регистров XMM/YMM/ZMM, имеющих разрядность 16/32/64 байта.»
Кусок бреда.
1. Многопоточность и конвеерная обработка с использованием векторных инструкций (SIMD) очень разные вещи.
2. Расчленить SIMD аж на два это сильно.
3. Далеко не во всех режимах работы(шифрования) можно разбить работу по потокам.
«Эти новые методы в сумме позволили поднять быстродействие шифрования по ГОСТ 28147-89 как минимум на порядок и обеспечивать скоростные параметры шифрования ничуть не хуже американского AES-256, который использует специальный криптоускоритель в процессорах Интел/АМД.»
Понятно.
Это «вольный» пересказ винрарной работы: http://www.securitylab.ru/analytics/480357.php
Даже название от туда.
«В настоящее время шифр «Кузнечик» воспринимается как экзотика и не имеет практического применения из-за низкой скорости преобразований и сомнительной репутации, вместо него производители стали использовать многопоточное шифрование по ГОСТ 28147-89. Но об этом они стараются не говорить, поскольку знают, что нарушают авторские права.»
А может потому что всего год назад он стал стандартом?
За это время нужно было имплементировать, протестить, и сдать на сертификацию, пройти сертификацию, выкатиь в продакшин, настрочить инструкций по применению…
«Честные тесты» — Это же неадекват полнейший.
С таким же успехом ты мог использовать токовые клещи для измерения того насколько энергоэффективен алгоритм.
Чтобы сравнить хотя бы немного правдоподобно скорость работы двух и более алгоритмов нужно:
1. Взять реализации этих алгоритмов в исходниках
2. Выделить большой кусок памяти, чтобы он точно в кеш не влез, скажем 1-2 гига, забить его случайными данными
3. Научится относительно точно замерять процессорное время, сделать это хотя бы с помощью всяких АПИ типа GetProccessTimes (или как их там), вызвать до и вызвать после прогонки алгоритма и посчитать разницу.
Но и это далеко не идеальный метод, тут, на швабре, была 1-2 публикации с сотнями коментов срача по поводу как же правильно это делать.
4. Покрутить крутилки: количество прогонов, опции компеляции…
5. Попытаться сделать выводы.
Более академические работы сравнивают количество тактов проца необходимое для обработки одного блока.
В ещё более академических работах используются всякие интеловые профайлеры, которые помогают правильно организовать поток выполнения чтобы по максимуму загрузить конвеер и избегать пенальти.
Но даже после всего этого такие результаты всё равно относительны, ибо на другом проце оно может быть совсем не так.
«Возьмем самое продвинутое решение использующее этот шифр,- Битлокер.» — Что!?!!!
Продвинутое откуда? Кем? Куда?
Серьёзно?
Даже если предположить что битлокер реально использует AES для шифрования данных (а не так как некоторые харды: с помощью AES шифруют блок, а этим блоком потом XOR~ят все сектора), то он вполне может работать в XTS режиме, что накладывает ощутимые дополнительные расходы.
Те это по сути кот в мешке, ровно как и твоя программа собранная невесть как, и вот эти два мешка ты в тёмной комнате пытаешься сравнивать. Тёмной — потому что не учитывается дохренище ненужных факторов которые тоже влияют. А хотя бы твоя прога подиж пажет с обычным приоритетом, а битлокер по любому с реалтайм или около того. Не считая ненужной записи на диски, невнятных средств измерения и прочего треша.
Это тебе на закуску: https://geektimes.ru/company/icover/blog/271706/
гост89 в железе.
UncleAndy
30.12.2016 13:56А почему не сравнивали с AES-256 раз они получаются одного уровня криптостойкости?
ErmIg
Что вы имеет в виду, когда говорите про эмуляцию команд AVX2 в процессорах интел младше Skylake? На сколько я помню, эмулировались лишь gather-инструкции.