LINUX.ORG.RU

Набор патчей для ускорения шифрования/дешифрования AES-GCM

 , , ,

Набор патчей для ускорения шифрования/дешифрования AES-GCM

2

3

2 июня Эрик Биггерс (инженер из Google) представил новые реализации AES-XTS для гораздо более высокой производительности процессоров Intel/AMD с помощью новых наборов кода AES-NI + AVX, VAES + AVX2, VAES + AVX10/256 и VAES + AVX10/512.

Код AES-NI GCM заменяет собой предыдущий, написанный Intel, и устраняет существующие выявленные проблемы:

«Этот набор обновлений добавляет в VAES и AVX512/AVX10 реализацию AES-GCM (режим Galois/Counter), что повышает производительность AES-GCM до 162%. Кроме того, он заменяет старый код AES-NI GCM от Intel на новый. код, который немного быстрее и исправляет ряд проблем, включая огромный размер двоичного файла, превышающий 250 КБ. Подробности см. В исправлениях.

Конечным состоянием ассемблерного кода x86_64 AES-GCM является то, что мы получаем два ассемблерных файла: один генерирует код AES-NI с AVX или без него, а другой генерирует код VAES с AVX512/AVX10 с 256-битными или 512-битными векторами. В нём отсутствует поддержка одиночного VAES (без AVX512/AVX10). Это немного отличается от того, что я сделал с AES-XTS, где один файл генерирует код AVX и AVX512/AVX10, включая код, использующий только VAES (без AVX512/AVX10), а другой файл генерирует только код, отличный от AVX. Однако, на данный момент это кажется правильным выбором для каждого конкретного алгоритма, учитывая то, что ограничение до 16 SIMD-регистров и 128-битных векторов привело к некоторым существенно отличающимся конструктивным решениям в AES-GCM, но не настолько для AES-ХТС. Процессоры, поставляемые только с VAES, также кажутся временным явлением, поэтому нам, возможно, не следует слишком стараться поддерживать эту комбинацию».

>>> Подробности в официальной рассылке разработчиков ядра

★★★★

Проверено: hobbit ()
Последнее исправление: hobbit (всего исправлений: 1)

Ответ на: комментарий от SakuraKun

Т.е. AES - решето, особенно аппаратное AES

Чувак, очнись - т.н. аппаратный AES это просто набор процессорных инструкций, которые выполняют заранее заданное преобразование в соответствии с заданными ключами, и оно ничем не отличается от программной реализации

no-dashi-v2 ★★
()
Ответ на: комментарий от Werenter

Зависит от страны. В ЕС только с 2021 разрешили декомпилировать. Да в РФ можно, но не всегда, с условиями, обычно только для целей устранения работоспособности (исправления багов) или взаимодействия с другим ПО и только тех частей ПО для которых это необходимо.

fuggy
()
Ответ на: комментарий от fuggy

Какие такие исходники ты будешь смотреть в закрытых бинарных блобах

Что ты имеешь ввиду? программное шифрование необязательно должно сидеть в блобе

Скидывай тогда исходники Intel ME

Intel ME - это программноаппаратный бэкдор, соответственно все исходники закрыты

SakuraKun ★★★★★
()
Ответ на: комментарий от no-dashi-v2

У тебя ведь нет исходников аппаратной реализации шифрования? А она - как и программный алгоритм - может иметь случайный или специальный «недостаток», да и просто втихаря сотрудничать с тем же Intel ME

SakuraKun ★★★★★
()
Ответ на: комментарий от mumpster

у Intel ME ещё и жирный блоб есть. Парадокс - но если бы Intel ME работал без блоба, то железо с этим бэкдором (разумеется при отсутствии других блобов) в теории могло бы удовлетворять сертификации «Respects Your Freedom» от Free Software Foundation, хорошо что они добавили критерий «No spying or back doors » : https://ryf.fsf.org/about/criteria

SakuraKun ★★★★★
()
Ответ на: комментарий от vromanov

нет. тут речь идёт о том, что дескать вы должны пользоваться нашими замками, но вскрывать их для проверки нельзя - вы же типа верите нам на слово?

mumpster ★★★★★
()
Ответ на: комментарий от praseodim

а никто и не говорит про «упрощён». в NT4 никто ничего не упрощал по этой части. там просто сразу вшиты были ключи с говорящими именами NSA_ . бгг

mumpster ★★★★★
()
Ответ на: комментарий от Hilbert

да, только в железе ты проверить сам алгоритм и отсутствие ддоп. спц. ключей - не смодешь. от слова «никак».

mumpster ★★★★★
()
Ответ на: комментарий от SakuraKun

От вопроса ты тихо уходишь. В чём может даже теоретически заключаться дыра в реализации алгоритма шифрования? Если результат не соответствует спецификации, то дешифровка будет провалена. А если алгоритм позволяет зашифровать так, что можно будет расшифровать не тем ключом, что использовался при шифровании — это уже проблема алгоритма, а не реализации.

Werenter ★★★
()
Ответ на: комментарий от SakuraKun

Аппаратное шифрование несекурно

Если уж взялся быть криптопараноиком, то матчасть надо знать назубок.

В новости речь про аппаратное ускорение, а не аппаратное шифрование, так что дальше ты споришь с соломенным чучелом.

Аппаратное шифрование это, например, когда ты даешь накопителю пароль, а он возвращает тебе расшифрованные данные. Тогда да, ты не можешь знать, вдруг там ключ, которым зашифрованы данные, никак не связан с пароле, который ты даешь накопителю. Так было у Crucial: данные зашифрованы стойким ключом, который сгенерировал контроллер, этот стойкий ключ лежит открытым текстом во флеше, контроллер принимает твой пароль, сверяет с сохранённым и при совпадении берёт ключ и расшифровывает данные. Атакующий может вскрыть накопитель, считать ключ и получить доступ к данным, поскольку ключ шифрования не был зашифрован паролем пользователя.

А в новости речь лишь про то, что CPU быстрее выполняет отдельные инструкции. Ты можешь проверить, правильно ли он это делает - просто возьми и выполни те же инструкции программно, без ускорения. Результат сойдётся.

MozillaFirefox ★★★★★
()
Последнее исправление: MozillaFirefox (всего исправлений: 5)
Ответ на: комментарий от SakuraKun

Эта реализация - детерминированный алгоритм (по сути просто перемножение матриц и векторов). В регистрах задаются адреса фрагмента ключа, блока данных, таблицы замен и всё - дальше обычная математика.

Сам алгоритм может быть умышленно ослаблен какими-нибудь параметрами типа таблиц перестановок или прочего, но это никак не относится к реализации, а уже свойство алгоритма/стандарта и такой уязвимости подвержена любая реализация, как программная, так и софтовая.

no-dashi-v2 ★★
()

Прошу прощения, а нельзя таблицу менее вырвиглазной палитрой сделать?

rumgot ★★★★★
()
Ответ на: комментарий от mumpster

да, только в железе ты проверить сам алгоритм и отсутствие ддоп. спц. ключей - не смодешь. от слова «никак».

Все ровно как там в железе реализовано я беру набор данных, набор ключей, шифрую своим софтварным алгоритмом, шифрую аппаратным, результаты должны быть одинаковыми, если различные то это значит баг либо в моем софтверном алгоритме, либо баг/закладка в аппаратном. То есть нет смысла именно там делать закладки это ловиться очень быстро.

Hilbert
()
Ответ на: комментарий от SakuraKun

Ты пользуешся опенсорсным замком и опенсорсной симкартой? Или сдался противной проприетарщине?

vromanov ★★★
()
Ответ на: комментарий от no-dashi-v2

Нет, часто это это ускоритель намертво встроенный в процессор. Никакого кода (ну кроме VHDL).

vromanov ★★★
()
Ответ на: комментарий от seiken

подсунуть нам ослабленную аппаратную реализацию».

Я не думаю что так грубо действует закладка.Можно же специально сравнить результаты под разными платформами и в том числе и софтовыми вариантами.Скандалы Интелу и АНБ не к чему.А вот при получении по вайфаю или сетевой специального сигнала,и затем вычислять упрощённый
вариант,вполне возможно.

maximnik0 ★★
()
Последнее исправление: maximnik0 (всего исправлений: 1)
Ответ на: комментарий от maximnik0

затем вычислять упрощённый вариант

что значит «упрощённый»?

шифрование/дешифрование — это строго детерминированная последовательность математических операций, если вы внесёте какие-то изменения в алгоритм шифрования, то при попытке дешифрования получите просто белиберду.

edo
()
Ответ на: комментарий от maxcom

Интересно, а AES в ядре в каких случаях используется?

Для всех ядерных VPN, включая IPsec и Wireguard.

ivlad ★★★★★
()
Ответ на: комментарий от Hilbert

не совсем так. вспоминая историю с выбором констант для ГОСТовского.

mumpster ★★★★★
()
Ответ на: комментарий от edo

Ну это мы в рамках возможного бэкдора теории строим- я же доказываю что с известным алгоритмом трудно сделать аппаратный бэкдор.Но допустим алгоритм химичит с пробелами в тексте и букву ё не применяет.
Вон энигму с устранением ошибки аж до 90х годов Швейцария применяла- а основная ошибка кроме 3-5 колесиковых версий ( слабый ключ) это то что никогда исходная буква на то же место по сле шифрование не печатались. Т.е криптограф мог проверить на совпадение теоретический текст,что приводило к взлому ключа.

maximnik0 ★★
()
Ответ на: комментарий от mumpster

а никто и не говорит про «упрощён». в NT4 никто ничего не упрощал по этой части. там просто сразу вшиты были ключи с говорящими именами NSA_ . бгг

Выше seiken говорил про упрощение.

Но вообще ты понимаешь, что аппаратное ускорение - это просто инструкции процессора, специфичные для алгоритма AES и не более того? Куда там всовывать NSA_ ???? Любое всовывание вызовет несовместимость открытой программной и аппаратной реализации и такая штука очень быстро обнаружится.

Так что я бы не парился насчет аппаратных ускорений, закрытые они там или нет.

Повторюсь, если в AES и есть NSA-ные бекдоры, то они скорее всего на уровне самого алгоритма и/или конкретных реализаций готовых систем (а не инструкций процессора), по типу давнего эпичного бага в дебиан.

praseodim ★★★★★
()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.