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

480

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

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

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

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

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

Cheeso
источник
22
«Это на самом деле не связано с программированием, но связано с алгоритмом». ∵ алгоритмы могут быть представлены математикой. ∵ компьютерное программирование может быть представлено математикой. ∴ ваш вопрос о компьютерном программировании.
Тайлер Джиллис
41
«Это на самом деле не связано с программированием, но связано с алгоритмом». ∵ алгоритмы могут быть представлены математикой, а фондовые рынки могут быть представлены математикой, ваш вопрос о фондовых рынках. / извините за сарказм, но в то время как заключение было очень очевидно , верно, аргумент был очень явно неправильно
Шиен
Зависит от понимания отношений, на которые вы подписаны. Что-то не обязательно должно быть связано только с тем или иным понятием.
Брайан Грейс

Ответы:

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

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

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

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

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

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

  • Вы должны ВСЕГДА использовать уникальные IV каждый раз, когда вы шифруете, и они должны быть случайными . Если вы не можете гарантировать, что они случайные , используйте OCB, так как для этого требуется только одноразовый номер , а не IV , и существует явная разница. Одноразовое значение не уронить безопасности , если люди могут угадать следующий, IV может вызвать эту проблему.
myforwik
источник
65
CBC, OFB и CFB далеко не идентичны.
Джонатан Леффлер
22
CTR поддается распараллеливанию, потому что вы можете разбить сообщение на куски, каждый из которых имеет диапазон значений счетчиков, связанных с ним, и зашифровать (или расшифровать) каждый кусок независимо. Напротив, CFB полагается на выход из предыдущего блока в качестве одного из входов следующего, поэтому он строго последовательный и по своей сути не распараллеливаемый. Аналогично для других упомянутых режимов.
Джонатан Леффлер
9
Даже если вы шифруете только один блок, ECB не следует использовать, если вы будете шифровать этот один блок более одного раза (возможно, более одного раза) одним и тем же ключом.
yfeldblum
23
... как ответ, который говорит, что "CBC, OFB и CFB идентичны" не имеет единого отрицательного голоса?
Майкл Мрозек
30
GCM очень похож на OCB (производительность и другие свойства), но не обременен никакими патентами, поэтому это лучший выбор. Единственным недостатком является тот факт, что реализация очень сложна - но вам не нужно беспокоиться об этом, если вы используете библиотеку.
ntoskrnl
409

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

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

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

Персеиды
источник
214
«Если вам нужно задать этот вопрос, вы, вероятно, недостаточно знаете о криптографии для реализации защищенной системы». - Вы правы, но понимаете, что задавать вопросы - это то, как люди учатся? Так что, может быть, немного расслабиться.
Роберт Маклин
70
@RobertMacLean Верно, но, в отличие от многих других областей ИТ, вы не сможете обеспечить безопасность путем проб и ошибок. В то время как с веб-дизайном, масштабируемостью приложений и т. Д. Вы можете активно проверять свои требования, тестирование аспектов безопасности варьируется от сложного до невозможного. К сожалению, этот урок редко преподается. В большинстве ресурсов рассказывается о том, как работает криптография, а не о бесчисленных способах ее провала на практике без вашего ведома. Единственный выход - узнать много о предмете. И это моральный дух поста:
Персеиды
8
Либо потратьте достаточно времени, чтобы полностью изучить криптографию, либо избегайте ее насколько это возможно и используйте сильные абстракции. И в теме изучения того, как криптография ломается, первый абзац гораздо больше по теме, чем описание режимов.
Персеиды
33
Минус один: начальный заголовок неверен; он должен сказать: «Если вы задаете этот вопрос, вы идете в правильном направлении, продолжайте в том же духе, и вы преуспеете!»
Хенрик
11
@FerminSilva: Да, но другой аспект аргумента заключается в том, что зачастую проще использовать проверенные и проверенные решения, чем копировать и вставлять криптографический код. Например, когда все, что вам нужно сделать, это поговорить со своим сервером из приложения для смартфона, гораздо проще настроить обратный прокси-сервер Apache с сертификатом Let's Encrypt TLS и писать https://your.serverвезде в своем приложении, чем придумывать какой-либо протокол обмена ключами и заставить библиотеки криптографии с обеих сторон работать гладко.
Персеиды
36

Формальный анализ был сделан Филом Рогэвеем в 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 бит. Широко стандартизирован и используется.

TheGreatContini
источник
1
Режим GCM: Учитывая, что большинство в SO практически не знают о шифровании, не будут правильно использовать какой-либо режим, обычно не используют аутентификацию и часто используют режим ECB. Режим GCM, вероятно, является лучшим выбором здесь . К сожалению, отсутствие реализаций платформы, в некоторых случаях (iOS) отсутствие поддержки со стороны поставщика, плохая проверка, во многих случаях отсутствие аппаратной поддержки, в настоящее время проблематично. В противном случае это хорошо для непосвященного в шифровании, поскольку оно имеет встроенную аутентификацию и кажется будущим.
Zaph
3
Режим CTR: я не согласен с режимом CTR как лучшим выбором из-за большого количества сбоев на практике, в основном повторного использования IV. Даже Microsoft облажалась по крайней мере пару раз.
zaph
1
Режим CBC: Вероятно, наиболее распространенный режим и наиболее используемый режим на SO, ECB (который не должен использоваться) исключен. Основные недостатки использования - неслучайный IV, но мы видим более правильное использование с CSPRNG. Оракулы дополнения, хотя и являются проблемой, легко исправить, просто игнорируя и не возвращая ошибки дополнения. Некоторые реализации (например, Common Crypto) не сообщают об ошибках заполнения, по существу, успешно избегая их на уровне API.
Zaph
1
IMO CTR хуже, потому что это простой xor, где CBC имеет распространение от блока к блоку, как и несколько других режимов. Это может показаться простым, но в коде массового рынка произошли серьезные сбои.
zaph
1
Из прочтения связанной статьи кажется, что получен только ключ аутентификации, а не ключ шифрования от повторного использования одноразового номера. Это не похоже на утверждение в комментариях, что ключ шифрования получен. Хотя получение ключа аутентификации позволяет изменить сообщение, оно не позволяет восстановить сообщение. Пожалуйста, укажите, где я могу ошибаться.
Zaph
30
  1. Все, кроме ЕЦБ.
  2. При использовании CTR обязательно, чтобы вы использовали разные IV для каждого сообщения, в противном случае вы получите злоумышленнику возможность получить два зашифрованных текста и получить комбинированный незашифрованный открытый текст. Причина в том, что режим CTR по существу превращает блочный шифр в потоковый шифр, и первое правило потоковых шифров - никогда не использовать один и тот же ключ + IV дважды.
  3. На самом деле нет большой разницы в том, насколько сложны эти режимы. Некоторые режимы требуют только блочного шифра для работы в направлении шифрования. Тем не менее, большинство блочных шифров, включая AES, не требуют намного больше кода для реализации дешифрования.
  4. Для всех режимов шифрования важно использовать разные IV для каждого сообщения, если ваши сообщения могут быть идентичными в первых нескольких байтах, и вы не хотите, чтобы злоумышленник знал об этом.
Theran
источник
Чтобы поддержать вашу точку 1 (+1 за это, между прочим): codinghorror.com/blog/archives/001267.html
Майкл
1
Вы не должны начинать CTR со случайного числа, поскольку у него есть небольшая, но увеличивающаяся вероятность столкновения с частью предыдущего сообщения. Вместо этого монотонно увеличивайте его (это может означать, что вы помните, где находитесь в постоянном хранилище), и повторно введите ключ, если (когда) у вас закончится счетчик.
Кафе
@ Theran - точка 2 - другое случайное число для каждого сообщения? Нет, я думаю, что это не правильно. У меня сложилось впечатление, что запуск счетчика всегда с нуля - это нормально. @caf, я думаю, что когда Теран говорит «сообщение», он не означает «блок». Конечно, счетчик увеличивается для каждого блока определенного сообщения, которое проходит через шифр. Кажется, Теран говорит, что каждое сообщение должно начинаться с другого начального значения счетчика. И я думаю, что это не правильно.
Cheeso
1
в отношении пункта 3: я прочитал статьи, в которых, например, говорится, что режим CTR меньше для реализации, потому что дешифрование - это то же преобразование, что и шифрование. Поэтому половина кода. Но, как я уже сказал, не относится к машине серверного класса.
Cheeso
Да, я оговорился. Это IV / nonce, который должен измениться для режима CTR, но он объединяется со счетчиком перед шифрованием, поэтому я склонен думать о нем как о случайной начальной точке для счетчика. Поскольку для шифрования в направлении шифрования необходимо использовать только шифр, для многих шифров необходимо только перевернуть подключи для дешифрования. AES немного громоздкий для расшифровки, но это не так, как если бы вы в любом случае реализовали его на компьютере с 128 байтами оперативной памяти. Подключи занимают больше оперативной памяти, чем это!
Theran
13

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

КТС
источник
6
Этот ответ не соответствует стандартам качества Stackoverflow: примите, пожалуйста, в своем ответе, что все внешние ссылки устарели, и суммируйте - если не прямо скопируйте - соответствующую информацию, в идеале так, чтобы наилучшим образом ответить на исходный вопрос.
Мирабилось
5
@mirabilos Прошло почти 5 лет, ссылаясь на нормы и стандарты, которых не было в то время, правда? Мне особенно нравится говорить о мертвых ссылках, когда оба они на самом деле все еще очень активны, и учитывая, что рассматриваемый сайт, вероятно, останется таковым еще в течение 5 лет. Ну что ж.
KTC
3
@mirabilos Вы можете прийти правильно , возможно , но ваша жалоба ответ , что , казалось, было сделано 5 лет назад , когда нормы отличались не применяется. Вы должны были только что признать свою ошибку. Даже если это не так, и вы вместо этого подразумеваете, что он должен быть обновлен или изменен, это все равно не обязательно. Ответ был достаточен от того, как это было.
konsolebox
@ KTC За исключением случаев, когда правительство закрывается и сайт не работает. Ваш ответ мог быть полезной информацией, но на данный момент полностью отсутствует. Таким образом, читатель этого вопроса и его ответов по-прежнему задается вопросом, что было обновлено в 2014 году (из-за неполного ответа), а также текущее состояние (из-за правительственного закрытия веб-сайта NIST). Я хотел бы добавить недостающую информацию, однако ...
G DeMasters
11

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

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

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

Марк Лаката
источник
1
ST Micro: EBC должен быть ЕЦБ; К сведению: например, STM32L4A6 поддерживает 128-битные и 256-битные AES с ECB, CBC, CTR, GCM, а также режимом кода аутентификации сообщений Galois (GMAC) или шифровального кода аутентификации сообщений. Алгоритмы связывания CMAC также поддерживаются аппаратным обеспечением.
Том Кушель
-3

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

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

chris166
источник
Ах да, конечно. CBC XOR предшествует блоку зашифрованного текста с блоком открытого текста перед шифрованием. Первый блок использует IV. Таким образом, чтобы расшифровать любой блок, вы должны успешно расшифровать все предыдущие блоки. хорошо, это хорошее понимание
Cheeso
6
Нет, вам нужно иметь доступ только к предыдущему зашифрованному тексту , который не требует расшифровки каких-либо предыдущих блоков.
Кафе
Ах, хорошо, это означает, что CBC просто отлично с произвольным доступом, не так ли?
Cheeso
4
@Cheeso: CBC подходит для произвольного доступа для чтения, но не для произвольного доступа для записи. Используйте CTR там.
Paŭlo Ebermann
3
@ PaŭloEbermann Для CTR с произвольным доступом не очень хорошая идея, поскольку он допускает серьезные атаки, если злоумышленник наблюдает две версии зашифрованного текста. Вместо этого используйте XTS или настраиваемый блочный шифр.
CodesInChaos