Как выбрать режим шифрования AES (CBC ECB CTR OCB CFB)?

Question

Какие из них предпочтительнее при каких обстоятельствах?

Я хотел бы увидеть список критериев оценки для различных режимов и, возможно, обсуждение применимости каждого критерия.

Например, Я думаю, что одним из критериев является «размер кода» для шифрования и дешифрования, что важно для встроенных систем микрокода, таких как сетевые адаптеры 802.11. Если код, необходимый для реализации CBC, намного меньше, чем тот, который требуется для CTR (я не знаю, это правда, это всего лишь пример), тогда я мог бы понять, почему предпочтителен режим с меньшим кодом. Но если я пишу приложение, которое работает на сервере, а библиотека AES, которую я использую, в любом случае реализует CBC и CTR, тогда этот критерий не имеет значения.

Видите, что я имею в виду под «списком критериев оценки и применимости каждого критерия» ??

Это не связано с программированием, но связано с алгоритмом.

Answer 1

Пожалуйста, подумайте долго и усердно, если вы не можете обойтись без собственной криптографии

Уродливая правда в том, что если вы зададите этот вопрос, вы, вероятно, не сможете разработать и внедрить защищенную систему.

Позвольте мне проиллюстрировать мою мысль: представьте, что вы создаете веб-приложение, и вам необходимо сохранить некоторые данные сеанса. Можно назначить каждому пользователю идентификатор сеанса и сохранить данные сеанса на сервере в виде идентификатора сеанса, отображающего хеш-карту, в данные сеанса. Но тогда вам придется иметь дело с этим неприятным состоянием на сервере, и если в какой-то момент вам понадобится более одного сервера, все станет грязно. Таким образом, вместо этого у вас есть идея сохранить данные сеанса в файле cookie на стороне клиента. Вы, конечно, зашифруете его, чтобы пользователь не мог читать и манипулировать данными. Так какой режим вы должны использовать? Приходя сюда, вы читаете верхний ответ (извините, что выделил вас в myforwik). Первый из них - ECB - не для вас, вы хотите зашифровать более одного блока, следующий - CBC - звучит хорошо, и вам не нужен параллелизм CTR, вам не нужен произвольный доступ, поэтому нет XTS и патенты являются PITA, поэтому нет OCB. Используя свою криптографическую библиотеку, вы понимаете, что вам нужны некоторые отступы, потому что вы можете только зашифровать кратные блоки размера. Вы выбираете PKCS7 , потому что это было определено в некоторых серьезных стандартах криптографии. После прочтения где-то, что CBC является доказуемо безопасным , если используется со случайным IV и защищенным блочным шифром, вы будете спокойны, даже если вы храните ваши конфиденциальные данные на стороне клиента.

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

Это не гипотетический сценарий: У Microsoft был именно такой недостаток в ASP.NET еще несколько лет назад.

Проблема в том, что с криптографией связано много подводных камней, и чрезвычайно легко создать систему, которая выглядит безопасной для неспециалистов, но легко разбирается для знающего злоумышленника.

Что делать, если вам нужно зашифровать данные

Для активных соединений используйте TLS (обязательно проверьте имя хоста сертификата и цепочку эмитента). Если вы не можете использовать TLS, найдите API самого высокого уровня, который ваша система может предложить для вашей задачи, и убедитесь, что вы понимаете гарантии, которые она предлагает, и, что более важно, то, что она не гарантирует. Для приведенного выше примера структура, подобная Play , предлагает средства хранения на стороне клиента , однако через некоторое время она не делает недействительными сохраненные данные, и если вы изменили состояние на стороне клиента, злоумышленник может восстановить предыдущее состояние без вашего ведома.

Если высокоуровневая абстракция недоступна, используйте криптографическую библиотеку высокого уровня. Ярким примером является NaCl , а переносимая реализация с множеством языковых привязок - Sodium . Используя такую ​​библиотеку, вам не нужно заботиться о режимах шифрования и т. Д., Но вы должны быть еще более внимательны к деталям использования, чем с абстракцией более высокого уровня, как никогда не используйте одноразовый номер дважды.

Если по какой-то причине вы не можете использовать высокоуровневую криптобиблиотеку, например, из-за того, что вам нужно определенным образом взаимодействовать с существующей системой, нет никакого способа тщательно обучиться. Я рекомендую прочитать Криптографическая инженерия Фергюсона, Коно и Шнайера . Пожалуйста, не обманывайте себя, полагая, что вы можете создать безопасную систему без необходимой подготовки. Криптография чрезвычайно тонка, и почти невозможно проверить безопасность системы.

Сравнение режимов

Только шифрование:

• Режимы, требующие заполнения :Как и в примере, заполнение может быть опасным, поскольку оно открывает возможность дополнения оракулом. Самая простая защита - аутентифицировать каждое сообщение перед расшифровкой. Увидеть ниже.
  • ECB шифрует каждый блок данных независимо, и один и тот же блок открытого текста приводит к тому же блоку зашифрованного текста. Взгляните на зашифрованный образ ECB Tux на странице ECB Wikipedia , чтобы понять, почему это серьезная проблема. Я не знаю ни одного случая использования, где бы ЕЦБ был приемлемым.
  • CBC имеет IV и, следовательно, нуждается в случайности каждый раз, когда сообщение зашифровано, изменение части сообщения требует повторного шифрования всего после изменения, ошибки передачи в одном блоке зашифрованного текста полностью уничтожают открытый текст и изменить дешифрование следующего блока, дешифрование может быть распараллелено / шифрование невозможно, открытый текст в некоторой степени податлив - это может быть проблемой .
• Режимы потокового шифра : Эти режимы генерируют псевдослучайный поток данных, которые могут зависеть или не зависеть от открытого текста. Как и в случае потоковых шифров в целом, генерируемый псевдослучайный поток подвергается операции XOR с открытым текстом для генерации зашифрованного текста. Поскольку вы можете использовать столько битов случайного потока, сколько вам нужно, вам не нужно заполнять их вообще. Недостатком этой простоты является то, что шифрование полностью изменчиво , что означает, что злоумышленник может изменить расшифровку любым способом, который ему нравится, как для открытого текста p1, зашифрованного текста c1 и псевдослучайного потока r и атакующего. можно выбрать разность d такую, что дешифрование зашифрованного текста c2 = c1⊕d будет p2 = p1⊕d, так как p2 = c2⊕r = (c1 ⊕ d) ⊕ r = d ⊕ (c1 ⊕ r). Также один и тот же псевдослучайный поток никогда не должен использоваться дважды, как для двух зашифрованных текстов c1 = p1⊕r и c2 = p2⊕r, злоумышленник может вычислить xor двух открытых текстов как c1⊕c2 = p1⊕r⊕p2⊕r = p1⊕p2. Это также означает, что изменение сообщения требует полного повторного шифрования, если исходное сообщение могло быть получено злоумышленником. Все следующие режимы парового шифрования требуют только операции шифрования блочного шифра, поэтому в зависимости от шифра это может сэкономить некоторое пространство (кремниевый или машинный код) в крайне ограниченных средах.
  • CTR прост, он создает псевдослучайный поток, который не зависит от открытого текста, различные псевдослучайные потоки получаются путем подсчета из разных одноразовых номеров / IV, которые умножаются на максимальную длину сообщения, так что перекрытие предотвращено, использование одноразового шифрования сообщений возможно без случайности каждого сообщения, дешифрование и шифрование завершаются распараллеливанием, ошибки передачи влияют только на неправильные биты и ничего более
  • OFB также создает псевдослучайный поток, независимый от открытого текста, разные псевдослучайные потоки получают, начиная с другого одноразового номера или случайного IV для каждого сообщения, ни шифрование, ни дешифрование не распараллеливаются, как в случае CTR Использование одноразового шифрования сообщений возможно без случайности каждого сообщения, так как ошибки передачи CTR влияют только на неправильные биты и ничего более
  • Псевдослучайный поток * CFB зависит от открытого текста, для каждого сообщения требуется различный одноразовый или случайный IV, как в случае CTR и OFB возможно использование шифрования сообщений одноразового использования без случайности каждого сообщения, расшифровка Распараллеливаемости / шифрования нет, ошибки передачи полностью разрушают следующий блок, но влияют только на неправильные биты в текущем блоке
• Шифрование дискаРежимы ption : Эти режимы предназначены для шифрования данных ниже абстракции файловой системы. Из соображений эффективности изменение некоторых данных на диске требует только перезаписи не более одного блока диска (512 байт или 4 КБ). Они выходят за рамки этого ответа, так как имеют совершенно разные сценарии использования, чем другие. Не используйте их ни для чего, кроме шифрования диска на уровне блоков . Некоторые члены: XEX, XTS, LRW.

Аутентифицированное шифрование:

Чтобы предотвратить атаки оракула-дополнения и изменения в зашифрованном тексте, можно вычислить код аутентификации сообщения *1096* (MAC) на зашифрованном тексте и расшифровать его, только если он не был подделан. Это называется encrypt-then-mac, и должно быть предпочтительнее любого другого порядка . За исключением очень немногих случаев использования аутентичность так же важна, как и конфиденциальность (последняя из которых является целью шифрования). Схемы шифрования с аутентификацией (со связанными данными (AEAD)) объединяют процесс шифрования и аутентификации, состоящий из двух частей, в один блочный режим шифрования, который также создает тег аутентификации в процессе. В большинстве случаев это приводит к улучшению скорости.

• CCM - это простая комбинация режима CTR и CBC-MAC. Использование двухблочного шифрования на блок очень медленное.
• OCB быстрее, но обременен патентами. Для свободного (как и в случае свободы) или невоенного программного обеспечения владелец патента предоставил бесплатную лицензию , однако.
• GCM - это очень быстрая, но, возможно, сложная комбинация режима CTR и GHASH, MAC над полем Галуа с 2 ^ 128 элементами. Его широкое использование в важных сетевых стандартах, таких как TLS 1.2, отражено в специальной инструкции , которую Intel представила для ускорения расчета GHASH.

Рекомендация:

Учитывая важность аутентификации, я бы порекомендовал следующие два режима блочного шифрования для большинства случаев использования (за исключением целей шифрования диска): если данные аутентифицируются асимметричной подписью, используйте CBC, в противном случае используйте GCM.

Answer 2

• ECB не следует использовать при шифровании более одного блока данных одним и тем же ключом.

• CBC, OFB и CFB аналогичны, однако OFB / CFB лучше, потому что вам нужно только шифрование, а не дешифрование, что может сэкономить место на коде.

• CTR используется, если вы хотите хорошее распараллеливание (т.е. скорость), вместо CBC / OFB / CFB.

• Режим XTS наиболее распространен, если вы кодируете произвольно доступные данные (например, жесткий диск или ОЗУ).

• OCB - безусловно лучший режим, поскольку он позволяет шифровать и аутентифицировать за один проход. Однако в США на него есть патенты.

Единственное, что вам действительно нужно знать, это то, что ECB не должен использоваться, если вы не шифруете только 1 блок. XTS следует использовать, если вы шифруете данные с произвольным доступом, а не поток.

• Вы должны ВСЕГДА использовать уникальные IV при каждом шифровании, и они должны быть случайными . Если вы не можете гарантировать, что они случайные , используйте OCB, так как для этого требуется только nonce , а не IV , и существует явная разница. nonce не снижает безопасность, если люди могут догадаться о следующем, IV может вызвать эту проблему.

Answer 3

Формальный анализ был проведен Филом Рогавеем в 2011 году, здесь . В разделе 1.6 приводится краткое изложение, которое я здесь переписываю, добавляя свой собственный акцент на полужирном шрифте (если вы нетерпеливы, тогда его рекомендация - использовать режим CTR, но я предлагаю вам прочитать мои параграфы о целостности сообщений и шифровании ниже).

Обратите внимание, что для большинства из них требуется, чтобы IV был случайным, что означает непредсказуемость и, следовательно, должно генерироваться с криптографической безопасностью. Однако для некоторых требуется только одноразовый номер, который не требует этого свойства, а вместо этого требует, чтобы оно не использовалось повторно. Поэтому проекты, которые полагаются на одноразовый номер, менее подвержены ошибкам, чем проекты, которые этого не делают (и поверьте мне, я видел много случаев, когда CBC не реализован при правильном выборе IV). Таким образом, вы увидите, что я добавил жирный шрифт, когда Рогавей говорит что-то вроде «конфиденциальность не достигается, когда IV - это одноразовый номер», это означает, что если вы выберете свой IV криптографически безопасный (непредсказуемый), то проблем не будет. Но если вы этого не сделаете, то вы потеряете хорошие свойства безопасности. Никогда не используйте IV повторно для любого из этих режимов.

Также важно понимать разницу между целостностью сообщений и шифрованием. Шифрование скрывает данные, но злоумышленник может изменить зашифрованные данные, и результаты могут быть приняты вашим программным обеспечением, если вы не проверите целостность сообщения. Хотя разработчик скажет «но измененные данные вернутся как мусор после дешифрования», хороший инженер по безопасности обнаружит вероятность того, что мусор вызовет нежелательное поведение в программном обеспечении, а затем превратит этот анализ в настоящую атаку. Я видел много случаев, когда использовалось шифрование, но целостность сообщения была действительно нужна больше, чем шифрование. Поймите, что вам нужно.

Я должен сказать, что, хотя GCM обладает как шифрованием, так и целостностью сообщений, это очень хрупкая конструкция: если вы повторно используете IV, вы облажались - злоумышленник может восстановить ваш ключ. Другие конструкции менее хрупки, поэтому я лично боюсь рекомендовать GCM, исходя из количества плохого кода шифрования, которое я видел на практике.

Если вам нужны и целостность сообщения, и шифрование, вы можете объединить два алгоритма: обычно мы видим CBC с HMAC, но нет причин связывать себя с CBC. Важно знать, что сначала шифруется , а затем MAC зашифрованный контент , а не наоборот. Кроме того, IV должен быть частью вычисления MAC.

Мне не известны проблемы с IP.

Теперь к хорошему от профессора Рогэвея:

Режимы блочных шифров, шифрование, но не целостность сообщений

ECB : блочный шифр, режим шифрует сообщения, кратные n битам, путем отдельного шифрования каждого n-битного фрагмента. Слабые свойства безопасности , метод утечки равенства блоков по позициям блоков и времени. Имеет значительную унаследованную ценность и ценность как строительный блок для других схем, но режим не достигает какой-либо вообще желаемой цели безопасности сам по себе и должен использоваться со значительной осторожностью; ЕЦБ не следует рассматривать как режим общей конфиденциальности .

CBC : Схема шифрования на основе IV, режим безопасен как схема вероятностного шифрования, обеспечивая неразличимость от случайных битов, принимая случайный IV. Конфиденциальность не достигается, если IV является просто одноразовым номером , или если это одноразовый номер, зашифрованный под тем же ключом, который используется схемой, как это неверно предлагается в стандарте. Ciphertexts очень податливы. Нет выбранной защиты от зашифрованного текста (CCA). Конфиденциальность утрачивается при наличии правильного дополнения оракула для многих методов заполнения. Шифрование неэффективно из-за его серийности. Широко используемые свойства безопасности режима только для конфиденциальности приводят к частому неправильному использованию. Может использоваться как строительный блок для алгоритмов CBC-MAC. Я не вижу важных преимуществ по сравнению с режимом CTR.

CFB : Схема шифрования на основе IV, режим безопасен как вероятностная схема шифрования, достигая неразличимости от случайных битов, принимая случайный IV. Конфиденциальность не достигается, если IV является предсказуемым , или если он сделан одноразовым номером, зашифрованным под тем же ключом, который используется схемой, как стандарт предлагает сделать неправильно. Шифротексты податливы. Нет CCA-безопасности. Шифрование неэффективно из-за его серийности. Схема зависит от параметра s, 1 ≤ s ≤ n, обычно s = 1 или s = 8. Неэффективно для того, чтобы потребовался один вызов блочного шифра для обработки только s битов. Режим обеспечивает интересное свойство «самосинхронизации»; вставка или удаление любого количества s-битных символов в зашифрованный текст только временно нарушает правильное дешифрование.

OFB : Схема шифрования на основе IV, режим безопасен как вероятностная схема шифрования, достигая неразличимости от случайных битов, принимая случайный IV. Конфиденциальность не достигается, если IV - это одноразовый номер, хотя фиксированная последовательность IV (например, счетчик) работает нормально. Ciphertexts очень податливы. Нет CCA безопасности. Шифрование и дешифрование неэффективны из-за того, что по своей сути являются последовательными. Нативно шифрует строки любой битовой длины (заполнение не требуется). Я не могу определить никаких важных преимуществ по сравнению с режимом CTR.

CTR : Схема шифрования на основе IV, режим обеспечивает неразличимость от случайных битов, предполагая одноразовый IV. В качестве безопасной схемы, основанной на одноразовом использовании, режим также может использоваться в качестве вероятностной схемы шифрования со случайным IV. Полный сбой конфиденциальности, если одноразовый номер повторно используется при шифровании или дешифровании. Распараллеливаемость режима часто делает его быстрее, в некоторых настройках, намного быстрее, чем другие режимы конфиденциальности. Важный строительный блок для схем аутентифицированного шифрования. В целом, обычно это лучший и самый современный способ шифрования только для конфиденциальности.

XTS : схема шифрования на основе IV, режим работает путем применения настраиваемого блочного шифра (защищенного как сильный PRP) к каждому n-битному фрагменту. Для сообщений, длина которых не делится на n, последние два блока обрабатываются специально. Единственное разрешенное использование режима - для шифрования данных на устройстве с блочной структурой. Узкая ширина основного PRP и плохая обработка дробных конечных блоков являются проблемами. Более эффективный, но менее желательный, чем (широко-блочный) PRP-защищенный блочный шифр.

MAC (целостность сообщения, но не шифрование)

ALG1–6 : набор MAC, все они основаны на CBC-MAC. Слишком много схем. Некоторые из них надежно защищены как VIL PRF, некоторые - FIL PRF, а некоторые не имеют доказуемой безопасности. Некоторые схемы допускают разрушительные атаки. Некоторые из режимов устарели. Разделение клавиш недостаточно подходит для режимов, которые его имеют. Не должны приниматься в массовом порядке, но выборочный выбор «лучших» схем возможен. Также было бы хорошо принять ни один из этих режимов в пользу CMAC. Некоторые из MAC ISO 9797-1 широко стандартизированы и используются, особенно в банковской сфере. Скоро будет выпущена пересмотренная версия стандарта (ISO / IEC FDIS 9797-1: 2010) [93].

CMAC : MAC, основанный на CBC-MAC, режим гарантированно безопасен (до границы дня рождения) в виде (VIL) PRF (при условии, что базовый блочный шифр является хорошим PRP). По существу минимальные издержки для схемы на основе CBCMAC. По своей природе последовательная природа является проблемой в некоторых прикладных областях, и использование с 64-битным блочным шифром потребовало бы случайного повторного ввода ключей. Более чистый, чем набор MAC 9797-1 ISO.

HMAC : MAC на основе криптографической хеш-функции, а не блочного шифра (хотя большинство криптографических хеш-функций сами основаны на блочных шифрах). Механизм имеет прочные границы доказуемой безопасности, хотя и не из предпочтительных предположений. Множество тесно связанных между собой вариантов в литературе усложняют понимание того, что известно. Никаких разрушительных атак не было предложено. Широко стандартизирован и используется.

GMAC : MAC на основе одноразового номера, который является частным случаем GCM. Наследует многие хорошие и плохие характеристики GCM. Но необязательное требование не является обязательным для MAC, и здесь оно приносит мало пользы. Практические атаки, если теги усекаются до ≤ 64 бит и степень дешифрования не отслеживается и не сокращается. Полный сбой при одноразовом повторном использовании. Использование в любом случае подразумевается, если GCM принят. Не рекомендуется для отдельной стандартизации.

аутентифицированное шифрование (как шифрование, так и целостность сообщения)

CCM : AEAD-схема на основе одноразового номера, которая сочетает в себе шифрование в режиме CTR и необработанный CBC-MAC. По своей сути серийный, ограничивающий скорость в некоторых контекстах. Надежно защищенный, с хорошими границами, предполагая, что базовый блочный шифр является хорошим PRP. Неловкая конструкция, которая наглядно делает свою работу. Проще реализовать, чем GCM. Может использоваться как одноразовый MAC. Широко стандартизирован и используется.

GCM : AEAD-схема на основе одноразового номера, которая сочетает в себе шифрование в режиме CTR и универсальную хэш-функцию на основе GF (2128). Хорошие характеристики эффективности для некоторых сред реализации. Хорошие доказуемо-безопасные результаты при минимальном усечении тега. Атаки и слабые границы доказуемой безопасности при наличии существенного усечения тега. Может использоваться как одноразовый MAC-адрес, который затем называется GMAC. Сомнительный выбор, чтобы разрешить одноразовые номера кроме 96-битных. Рекомендуется ограничить одноразовые номера до 96 битов, а теги - не менее 96 бит. Широко стандартизирован и используется.

Answer 4

1. Все, кроме ЕЦБ.
2. При использовании CTR крайне важно, чтобы вы использовали разные IV для каждого сообщения, в противном случае вы получите злоумышленнику возможность получить два зашифрованных текста и получить комбинированный незашифрованный открытый текст. Причина в том, что режим CTR по существу превращает блочный шифр в потоковый шифр, и первое правило потоковых шифров - никогда не использовать один и тот же ключ + IV дважды.
3. На самом деле нет особой разницы в том, насколько сложны эти режимы. Некоторые режимы требуют только блочного шифра для работы в направлении шифрования. Однако большинство блочных шифров, включая AES, не требуют гораздо больше кода для реализации дешифрования.
4. Для всех режимов шифрования важно использовать разные IV для каждого сообщения, если ваши сообщения могут быть идентичными в первых нескольких байтах, и вы не хотите, чтобы злоумышленник знал об этом.

Answer 5

Вы начали с чтения информации об этом в Википедии - Режимы работы блочного шифра ? Затем перейдите по ссылке в Википедии на NIST: Рекомендация для режимов работы блочного шифра .

Answer 6

Вы можете выбрать на основе того, что широко доступно. У меня был тот же вопрос, и вот результаты моего ограниченного исследования.

Аппаратные ограничения

STM32L (low energy ARM cores) from ST Micro support ECB, CBC,CTR GCM
CC2541 (Bluetooth Low Energy) from TI supports ECB, CBC, CFB, OFB, CTR, and CBC-MAC

Ограничения на открытый исходный код

Original rijndael-api source  - ECB, CBC, CFB1
OpenSSL - command line CBC, CFB, CFB1, CFB8, ECB, OFB
OpenSSL - C/C++ API    CBC, CFB, CFB1, CFB8, ECB, OFB and CTR
EFAES lib [1] - ECB, CBC, PCBC, OFB, CFB, CRT ([sic] CTR mispelled)  
OpenAES [2] - ECB, CBC 

[1] http://www.codeproject.com/Articles/57478/A-Fast-and-Easy-to-Use-AES-Library

[2] https://openaes.googlecode.com/files/OpenAES-0.8.0.zip

Answer 7

Мне известен один аспект: хотя CBC обеспечивает лучшую безопасность, изменяя IV для каждого блока, он не применим к зашифрованному контенту с произвольным доступом (например, зашифрованному жесткому диску).

Итак, используйте CBC (и другие последовательные режимы) для последовательных потоков и ECB для произвольного доступа.