Comments 23
Еще важную страницу можно добавить — en.wikipedia.org/wiki/AES_instruction_set — на ней же и список библиотек, которые используют эти инструкции. OpenSSL, например.
А как программно определить есть эти инструкции или нет? Или только разные билды под разный набор инструкций?
Проверить, пустой ли вывод
grep aes /proc/cpuinfo?
Before an application attempts to use AESNI instructions or PCLMULQDQ, the application should follow the steps illustrated in Section 11.6.2, “Checking for SSE/SSE2 Support.” Next, use the additional step provided below:
Check that the processor supports AESNI (if CPUID.01H:ECX.AESNI[bit 25] = 1);
(Intel® 64 and IA-32 Architectures Software Developer’s Manual)
Check that the processor supports AESNI (if CPUID.01H:ECX.AESNI[bit 25] = 1);
(Intel® 64 and IA-32 Architectures Software Developer’s Manual)
Можно еще упомянуть о другом, схожем AES расширении для x86, предложенным компанией VIA Technologies — PadLock engine, которое между прочим появилось раньше, чем AESNI.
*параноик мод он* Это чтобы АНБ легче работалось?
И где же на процессоре энергонезависимая память, куда он будет сохранять ваши ключи?
Это как раз вариант для параноиков, шифруем с использованием ассемблерных инструкций, не используя никакие библиотеки или API. То есть доверяем только железу и asm компилятору.
Это как раз вариант для параноиков, шифруем с использованием ассемблерных инструкций, не используя никакие библиотеки или API. То есть доверяем только железу и asm компилятору.
А в алгоритме закладочки нет? А то тут вон пару дней назад была темка… :)
Шнайер, вроде, сказал, что нет.
Атаки на сам алгоритм существуют, а вот бекдоров быть не должно.
Но вы можете поискать в нем, AES так же как и RSA был сертифицирован NIST.
Но вы можете поискать в нем, AES так же как и RSA был сертифицирован NIST.
При чем тут ключи? В железных реализациях криптоалгоритмов, можно сделать такую закладку, что ее никакой «Шнайер» не заметит, так как будет анализировать программную часть. А уязвимость зароют в каком-нибудь флаге регистра, который не участвуя в вычислениях сам по себе, будет так влиять на результат, что зная об этотм можно будет снижать сложность криптоанализа на порядки. Я как раз про ваше — «доверяем железу».
А причем тут реализация? Тут речь о самом алгоритме, для вскрытия кода нужны ключи. Результат работы AES от выбранного подхода не зависит.
Данные зашифрованные AES должны расшифровываться любой реализацией этого алгоритма. Помимо ассемблерных инструкций процессора, это могут быть как специализированные микросхемы, так и обычный программный код(без ускоряющих инструкций). Можно даже на листе бумаги вручную проверить его работу — сам алгоритм опубликован.
Так, что ваш комментарий о железных реализациях совсем не в тему. Если сложность снижена, значит алгоритм изменен и на выходе будет совсем другой результат, тогда другая реализация алгоритма с тем же самым ключем шифротекст не откроет(и наоборот).
Данные зашифрованные AES должны расшифровываться любой реализацией этого алгоритма. Помимо ассемблерных инструкций процессора, это могут быть как специализированные микросхемы, так и обычный программный код(без ускоряющих инструкций). Можно даже на листе бумаги вручную проверить его работу — сам алгоритм опубликован.
Так, что ваш комментарий о железных реализациях совсем не в тему. Если сложность снижена, значит алгоритм изменен и на выходе будет совсем другой результат, тогда другая реализация алгоритма с тем же самым ключем шифротекст не откроет(и наоборот).
Ну-ну. Читать-то умеем? Я не про сложность алгоритма, а про сложность криптоанализа, на которую влияют такие ньюансы, что не специалист не поверит. Но можно и на алгоритм повлиять. Предположим, аппаратная закладка переодически переводит алгоритм из основного режима CBC переводится в ECB. Результат — сообщения шифруются штатно — принимающая сторона все расшифровывает — вроде бы все ок. Но в шифртекстах становится очень много информации для вскрытия ключа. После того как статистика накапливается — ключ вскрывается. Да и в конце-концов что мешает аппаратной закладке после пытаться подмешивать ключ шифрования в служебную информацию, скажем сетевых пакетов? И вообще, чем железная реализация в процессоре отличается от программной, кроме быстродействия? Тем что ее проверить намного сложнее, обратный инжиниринг интеловских процессоров могут себе позволить очень немногие. Так что, параноикам стоит продолжать пользоваться софтовыми реализациями алгоритма.
Но можно и на алгоритм повлиять. Предположим, аппаратная закладка переодически переводит алгоритм из основного режима CBC переводится в ECB. Результат — сообщения шифруются штатно — принимающая сторона все расшифровывает — вроде бы все ок. Но в шифртекстах становится очень много информации для вскрытия ключа.
Прочитайте хотя бы на википедии, про режимы шифрования ECB и CBC. Информации в шифротексте для взлома ключа больше не станет, из-за смены режима шифрования. И если сменить режим, на принимающей стороне получится мусор, а не открытое сообщение.
Да и в конце-концов что мешает аппаратной закладке после пытаться подмешивать ключ шифрования в служебную информацию, скажем сетевых пакетов?
Слишком заметная закладка, для процессоров серийного производства.
Прочитайте хотя бы на википедии, про режимы шифрования ECB и CBC
Лучше сами почитайте и желательно не википедию. Я прекрасно знаю. И как реализуются криптоалгоритмы тоже почитайте. Вы думаете что стороны заранее все ньюансы(касательно смены режимов, например) обговаривают?
Информации в шифротексте для взлома ключа больше не станет, из-за смены режима шифрования.Мне нравится ваша безаппеляционность. А позвольте узнать чем эти режимы отличаются? Как раз тем что в шифртексте появляется сохраняется статистика открытого текста, что и позволяет, зная специфику сообщений, гораздо успешнее проводить криптоанализ.
Слишком заметная закладка, для процессоров серийного производства.С какого перепугу она заметная? Кому она заметная? Тем кто будет реверсить процессор?
Вы думаете что стороны заранее все ньюансы(касательно смены режимов, например) обговаривают?
Да
Мне нравится ваша безаппеляционность. А позвольте узнать чем эти режимы отличаются? Как раз тем что в шифртексте появляется сохраняется статистика открытого текста, что и позволяет, зная специфику сообщений, гораздо успешнее проводить криптоанализ.
Изначально вы говорили что режимы влияют на стойкость ключа. А не на поиск одинаковых блоков в открытом тексте.
С какого перепугу она заметная? Кому она заметная? Тем кто будет реверсить процессор?
firewall, IPS/IDS системы
Да
Обычно в криптопротоколах, соединение устанавливается во время работы, и на этапе рукопожатия устанавливаются режимы, версии алгоритма и тд. То есть если режим сменится, то пользователь может и не узнать об этом.
Изначально вы говорили что режимы влияют на стойкость ключа. А не на поиск одинаковых блоков в открытом тексте.ЭЭЭ? Извините вы криптоанализом занимались? Если режим предназначенный для коротких сообщений используется на длинных, и в шифртекст попадает статистика открытого текста, то это позволяет со временем вскрыть сообщения. Для симметричных шифров это означает вскрытие ключа. И это не о стойкости шифра или ключа. Это о неправильном использовании алгоритма.
firewall, IPS/IDS системы
Я говорил не об крупных изменениях сетевых пакетоа, а о минимальных изменениях в служебных заголовках в пределах тонкости реализации сетевого протокола, причем количество этой информации может быть очень мелким за один раз — вплоть до 1 байта. 1 байт в служебных заголовках не обнаружт ни одна высокоуровневая система, там не будет сигнатур атаки. Опять же менятся могут скажем не tcp/up пакеты, а например ethernet, если сниффер внедрен в локалку. И это был простейший пример про сетевые пакеты. Вариантов то миллион. Попытаться передать значимую для криптоанализа информацию можно множеством способов — поиграть мощностью wi-fi, лишнюю точку при печати на принтере поставить на полях, монитором померцать, щелчком в динамике и тд. Если противник наблюдает и знает что искать — он эту информацию
получит и использует в криптоанализе.
Криптопротокол и шифрование — это разные вещи.
AES — это алгоритм блочного шифрования. Есть важный момент, при шифровании объем данных не изменяется(выравнивание последнего блока не в счёт), а о моменте смены режима стороны тоже должны договориться. Например, можно зашифровать файл, а через месяц его расшифровать на другом ПК другой реализацией алгоритма. Теперь вопрос: как вторая сторона узнает, что посреди процесса шифрования внезапно изменился режим?
AES — это алгоритм блочного шифрования. Есть важный момент, при шифровании объем данных не изменяется(выравнивание последнего блока не в счёт), а о моменте смены режима стороны тоже должны договориться. Например, можно зашифровать файл, а через месяц его расшифровать на другом ПК другой реализацией алгоритма. Теперь вопрос: как вторая сторона узнает, что посреди процесса шифрования внезапно изменился режим?
Ребят, вы чего? Я вам что всем прямо сейчас должен прямо конкретную атаку на алгоритм выложить? Моя точка зрения — аппаратная реализация в коммерческом процессоре компании, вынужденной соблюдать законы США, заслуживает гораздо меньшего доверия чем софтовая, потому что для проверки аппаратной реализации нужен реверс инжиниринг всего процессора, а софтовую реазилацию проверить вполне реально даже собственными силами. Итого имеем — плюс аппаратной реализации — быстродействие, минус — огромную трудоемкость проверки. Если за вами АНБ не следит — пользуйтесь пжалста. Потом на тюремном курорте будет считать сэкономленные секунды. :)
мимо
Sign up to leave a comment.
Аппаратная поддержка алгоритма AES современными процессорами