Ответ 1

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

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

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

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

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

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

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

Ответ 2

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

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

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

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

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

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

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

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

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

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

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

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

• Режимы, которые требуют заполнения. Как и в примере, заполнение может быть опасным, поскольку оно открывает возможность дополнить атаки оракулом. Самая простая защита - аутентифицировать каждое сообщение перед расшифровкой. Увидеть ниже.
  • ECB шифрует каждый блок данных независимо, и один и тот же блок открытого текста приводит к тому же блоку зашифрованного текста. Взгляните на зашифрованный образ Tux ECB на странице ECB Wikipedia, чтобы понять, почему это серьезная проблема. Я не знаю ни одного случая использования, где бы ЕЦБ был приемлемым.
  • CBC имеет IV и, следовательно, нуждается в случайности каждый раз, когда сообщение зашифровано, изменение части сообщения требует повторного шифрования всего после изменения, ошибки передачи в одном блоке зашифрованного текста полностью разрушают открытый текст и изменяют дешифрование следующего блока, дешифрование может быть распараллелено/шифрование не может, открытый текст в некоторой степени податлив - это может быть проблемой.
• Режимы потокового шифра: эти режимы генерируют псевдослучайный поток данных, которые могут зависеть или не зависеть от открытого текста. Как и в случае потоковых шифров в целом, генерируемый псевдослучайный поток подвергается операции XOR с открытым текстом для генерации зашифрованного текста. Поскольку вы можете использовать столько битов случайного потока, сколько вам нужно, вам не нужно заполнять их вообще. Недостаток этой простоты является то, что шифрование является полностью податливым, а это означает, что расшифровка может быть изменена злоумышленником в любом случае он любит, как и для открытого текста p1, шифртекст c1 и псевдослучайного поток г и злоумышленника может выбрать такую разность 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.

Ответ 3

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

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

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

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

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

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

Теперь к хорошему материалу от профессора Рогавей:

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

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

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

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

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

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

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, режим доказуемо безопасен (до дня рождения) в качестве PRF (VIL) PRF (предполагая, что базовый блок-код является хорошим PRP). По существу минимальные накладные расходы для схемы на основе CBCMAC. Вследствие последовательной природы проблема в некоторых доменах приложений и использование с 64-битным блочным шифром потребовали бы случайного повторного ввода ключей. Чище, чем сборка MAC-адресов ISO 9797-1.

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

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

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

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

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

Ответ 4

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

Ответ 5

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

Ответ 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

Ответ 7

Прочитайте другие ответы, рекомендации против ЕЦБ касаются безопасности (большинство из них не упоминают причины), и как легко это сломается.

Если вы выбираете CBC, CFB или OFB, вам нужно будет отправить по вашим данным вектор инициализации (IV), который в основном является чем-то случайным (каждый раз, когда вы шифруете в этих режимах, зашифрованный результат выглядит иначе). Вы можете только расшифровать данные, если у вас есть IV.

Если отправка IV вдоль неудобна, невозможна (ограничения протокола, уже код места или wtvr) или ECB является единственным доступным режимом AES, чтобы сделать ECB более безопасным, введите начальную строку для шифрования данных со случайными байтами (необязательно переменную длину, основанную на значении первого байта, а не случайную клавиатуру, но случайную при каждом нажатии). GZip или иным образом сжимать данные с помощью того, что у вас есть. Шифрование.

После дешифрования и распаковки просто удалите заполнение перед использованием данных.

Примечание: ECB будет зашифровывать последующие блоки NOT на основе того, как предыдущий был зашифрован (независимо от того, сколько данных вы должны зашифровать, заполнение случайными байтами в начале НЕ будет изменять все блоки, только первые или те, которые вы заполняли). Это облегчается с помощью алгоритма случайного дополнения + сжатия (однако он не всегда работает - возможно, вы можете шифровать с помощью случайного пароля, хранящегося в начале, до шифрования с помощью ECB).

Ответ 8

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

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