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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Режимы, которые требуют заполнения . Как и в примере, заполнение может быть опасным, поскольку оно открывает возможность дополнить атаки оракулом. Самая простая защита - аутентифицировать каждое сообщение перед расшифровкой. См. ниже.
  • ECB шифрует каждый блок данных независимо, и тот же блок открытого текста приводит к тому же блоку зашифрованного текста. Взгляните на зашифрованный образ Tux ECB на странице 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 возможно использование шифрования сообщений одноразового номера без случайности каждого сообщения, дешифрование распараллеливается / нет, шифрование полностью отсутствует уничтожить следующий блок, но повлиять только на неправильные биты в текущем блоке
• Режимы шифрования диска : эти режимы предназначены для шифрования данных ниже абстракции файловой системы. Из соображений эффективности изменение некоторых данных на диске требует только перезаписи не более одного блока диска (512 байт или 4 КБ). Они выходят за рамки этого ответа, так как имеют совершенно разные сценарии использования, чем другие. Не используйте их ни для чего, кроме блочного шифрования диска . Некоторые участники: XEX, XTS, LRW.

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

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

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

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

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

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

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

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

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

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

Я не осведомлен о проблемах ИС.

Теперь о хороших вещах от профессора Рогэвея:

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

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

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

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

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

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

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

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

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

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

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

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