Вопрос по aes, encryption – Как выбрать режим шифрования AES (CBC ECB CTR OCB CFB)?

409

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

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

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

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

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

"Это на самом деле не связано с программированием, а связано с алгоритмом". & # X2235; алгоритмы могут быть представлены математикой. & # X2235; компьютерное программирование может быть представлено математикой. & # X2234; Ваш вопрос о компьютерном программировании. Tyler Gillies
"Это на самом деле не связано с программированием, а связано с алгоритмом". & # X2235; алгоритмы могут быть представлены математикой, а фондовые рынки могут быть представлены математикой, ваш вопрос о фондовых рынках. / извините за сарказм, но, хотя заключение было совершенно очевидно правильным, аргумент был совершенно очевидно неверным Shien

Ваш Ответ

7   ответов
28
Anything but ECB. If using CTR, it is imperative that you use a different IV for each message, otherwise you end up with the attacker being able to take two ciphertexts and deriving a combined unencrypted plaintext. The reason is that CTR mode essentially turns a block cipher into a stream cipher, and the first rule of stream ciphers is to never use the same Key+IV twice. There really isn't much difference in how difficult the modes are to implement. Some modes only require the block cipher to operate in the encrypting direction. However, most block ciphers, including AES, don't take much more code to implement decryption. For all cipher modes, it is important to use different IVs for each message if your messages could be identical in the first several bytes, and you don't want an attacker knowing this.
Для поддержки вашей точки 1 (+1 к этому кстати):codinghorror.com/blog/archives/001267.html
@ Theran - точка 2 - другое случайное число для каждого сообщения? Нет, я думаю, что это не правильно. У меня сложилось впечатление, что запуск счетчика всегда с нуля - это нормально. @caf, я думаю, когда Терана говорит «сообщение» он не означает «блокировать». Конечно, счетчик увеличивается для каждого блока конкретного сообщения, которое проходит через шифр. Кажется, Теран говорит, что каждое сообщение должно начинаться с другого начального значения счетчика. И я думаю, что это не правильно. Cheeso
в отношении пункта 3 - я прочитал статьи, в которых, например, говорится, что режим CTR меньше для реализации, поскольку дешифрование - это то же преобразование, что и шифрование. Поэтому половина кода. Но, как я уже сказал, не относится к машине серверного класса. Cheeso
Вы не должны начинать CTR со случайного числа, поскольку у него есть небольшая, но увеличивающаяся вероятность столкновения с частью предыдущего сообщения. Вместо этого монотонно увеличивайте его (это может означать, что вы помните, где находитесь в постоянном хранилище), и повторно введите ключ, если (когда) у вас закончится счетчик.
Да, я оговорился. Это значение IV / nonce, которое должно измениться для режима CTR, но оно объединяется со счетчиком перед шифрованием, поэтому я склонен думать о нем как о случайной начальной точке для счетчика. Поскольку для шифрования в направлении шифрования требуется только использование шифра, для многих шифров необходимо только повернуть подразделы для дешифрования. AES немного громоздкий для расшифровки, но это не так, как если бы вы все равно могли реализовать его на uC со 128 байтами оперативной памяти. Подключи занимают больше оперативной памяти, чем это!
-3

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

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

@ Pa & # x16D; loEbermann Для произвольного доступа CTR не является хорошей идеей, поскольку он допускает серьезные атаки, если злоумышленник наблюдает две версии зашифрованного текста. Вместо этого используйте XTS или настраиваемый блочный шифр.
Нет, вам нужно иметь доступ только кciphertext, который не требует расшифровки любых предыдущих блоков.
@Cheeso: CBC подходит для произвольного доступа для чтения, но не для произвольного доступа для записи. Используйте CTR там.
Ах да, конечно. CBC XOR предшествует блоку зашифрованного текста с блоком открытого текста перед шифрованием. Первый блок использует IV. Таким образом, чтобы расшифровать любой блок, вы должны успешно расшифровать все предыдущие блоки. хорошо, это хорошее понимание. Cheeso
Ах, хорошо, что означает, что CBC в порядке с произвольным доступом, не так ли? Cheeso
284

the same key.

CBC, OFB and CFB are similar, however OFB/CFB is better because you only need encryption and not decryption, which can save code space.

CTR is used if you want good parallelization (ie. speed), instead of CBC/OFB/CFB.

XTS mode is the most common if you are encoding a random accessible data (like a hard disk or RAM).

OCB is by far the best mode, as it allows encryption and authentication in a single pass. However there are patents on it in USA.

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

You should ALWAYS use unique IV's every time you encrypt, and they should be random. If you cannot guarantee they are random, use OCB as it only requires a nonce, not an IV, and there is a distinct difference. A nonce does not drop security if people can guess the next one, an IV can cause this problem.
GCM очень похож на OCB (производительность и другие свойства), но не обременен никакими патентами, поэтому это лучший выбор. Единственным недостатком является тот факт, что реализация очень сложная & # x2013; но вам не нужно беспокоиться об этом, если вы используете библиотеку.
... как ответ, который говорит, что "CBC, OFB и CFB идентичны" нет ни одного понижения?
CBC, OFB and CFB далеко не идентичны.
CTR поддается распараллеливанию, потому что вы можете разбить сообщение на куски, каждый из которых имеет диапазон значений счетчиков, связанных с ним, и независимо зашифровать (или расшифровать) каждый кусок. Напротив, CFB полагается на выход из предыдущего блока в качестве одного из входов для следующего, поэтому он строго последовательный и по своей сути не распараллеливаемый. Аналогично для других упомянутых режимов.
Даже если вы шифруете только один блок, ECB не следует использовать, если вы будете шифровать этот один блок более одного раза (возможно, более одного раза) одним и тем же ключом.
12
@ KTC За исключением случаев, когда правительство закрывается и сайт не работает. Ваш ответ мог быть полезной информацией, но на данный момент полностью отсутствует. Таким образом, читатель этого вопроса и его ответов по-прежнему задается вопросом, что же было обновлено в 2014 году (из-за неполного ответа) и каково его текущее состояние (из-за правительственного закрытия веб-сайта NIST). Я хотел бы добавить недостающую информацию, однако ...
@mirabilos Выmay прийти правильноarguablyно ваша жалоба на ответ, чтоappeared to have been made 5 лет назад там, где нормы были другими, не применимо. Вы должны были только что признать свою ошибку. Даже если это не так, и вместо этого вы подразумеваете, что он должен быть обновлен или изменен, это все равно не обязательно. Ответ был достаточен от того, как это было.
@mirabilos Прошло почти 5 лет, ссылаясь на нормы и стандарты, которых не было в то время, правда? Мне особенно нравится говорить о мертвых ссылках, когда оба они на самом деле все еще очень активны, и учитывая, что рассматриваемый сайт, вероятно, останется таковым еще в течение 5 лет. Ну что ж.
Этот ответ не соответствует стандартам качества Stackoverflow. Предположим, что в вашем ответе все внешние ссылки перестали работать, и суммируйте & # x2013; если не прямо, скопируйте & # x2013; соответствующую информацию, в идеале таким образом, чтобы наилучшим образом ответить на исходный вопрос.
28

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

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

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

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

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

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

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

Block ciphers modes, encryption but not message integrity

ECB: Блочный шифр, режим шифрует сообщения, кратные n битам, путем отдельного шифрования каждого n-битного фрагмента.The security properties are weak, метод утечки равенства блоков по позициям блоков и времени. Имеет значительную унаследованную ценность и ценность как строительный блок для других схем, но режим не достигает какой-либо вообще желаемой цели безопасности сам по себе и должен использоваться со значительной осторожностью;ECB should not be regarded as a “general-purpose” confidentiality mode.

CBC: Схема шифрования на основе IV, режим безопасен как вероятностная схема шифрования, достигая неразличимости от случайных битов, предполагая случайное IV.Confidentiality is not achieved if the IV is merely a nonceили если это одноразовый номер, зашифрованный под тем же ключом, который используется схемой, как это неверно предлагает стандарт. Ciphertexts очень податливы. Нет выбранной защиты от зашифрованного текста (CCA). Конфиденциальность утрачивается при наличии правильного дополнения оракула для многих методов заполнения. Шифрование неэффективно из-за его серийности. Широко используемые свойства безопасности режима только для конфиденциальности приводят к частому неправильному использованию. Может использоваться как строительный блок для алгоритмов CBC-MAC.I can identify no important advantages over CTR mode.

CFB: Схема шифрования на основе IV, режим безопасен как вероятностная схема шифрования, достигая неразличимости от случайных битов, предполагая случайное IV.Confidentiality is not achieved if the IV is predictableили если он сделан одноразовым номером, зашифрованным под тем же ключом, который используется схемой, как это неверно предлагает стандарт. Шифротексты податливы. Нет CCA-безопасности. Шифрование неэффективно из-за его серийности. Схема зависит от параметра s, 1 & # x2264; s & # x2264; n, обычно s = 1 или s = 8. Неэффективно для необходимости одного вызова блочного шифра для обработки только s битов. Режим обеспечивает интересную & # x201C; самосинхронизацию & # x201D; имущество; вставка или удаление любого количества s-битных символов в зашифрованный текст только временно нарушает правильное дешифрование.

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

CTR: Схема шифрования на основе IV, режим обеспечивает неотличимость от случайных битов, предполагая одноразовый IV. В качестве безопасной схемы, основанной на одноразовом использовании, режим также может использоваться в качестве вероятностной схемы шифрования со случайным IV. Полный сбой конфиденциальности, если одноразовый номер повторно используется при шифровании или дешифровании. Распараллеливаемость режима часто делает его быстрее, в некоторых настройках, намного быстрее, чем другие режимы конфиденциальности. Важный строительный блок для схем аутентифицированного шифрования.Overall, usually the best and most modern way to achieve privacy-only encryption.

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

MACs (message integrity but not encryption)

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

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

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

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

authenticated encryption (both encryption and message integrity)

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

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

Это логично для раздела «Документация» [Тема шифрования] (stackoverflow.com/documentation/encryption/topics()  отлично подходит.
@zaph Все режимы имеют проблемы с повторным использованием IV. Почему CTR хуже, чем любой другой режим в этой ситуации?
Режим CTR: я не согласен с режимом CTR как лучшим выбором из-за большого количества сбоев на практике, в основном повторного использования IV. Даже Microsoft облажалась, по крайней мере, пару раз.
Режим CBC: Вероятно, наиболее распространенный режим и наиболее используемый режим на SO, ECB (который не должен использоваться) исключен. Основные недостатки использования - неслучайный IV, но мы видим более правильное использование с CSPRNG. Оракулы дополнения, хотя и являются проблемой, легко исправить, просто игнорируя и не возвращая ошибки дополнения. Некоторые реализации (например, Common Crypto) не сообщают об ошибках заполнения по существу успешным способом избежать их на уровне API.
Режим GCM: учитывая, что большинство в SO практически не знают о шифровании, не будут правильно использовать какой-либо режим, как правило, не используют аутентификацию и часто используют режим ECB. Режим GCM, вероятно, является лучшим выбором.here, К сожалению, отсутствие реализаций платформы, в некоторых случаях (iOS) отсутствие поддержки со стороны поставщика, плохая проверка, во многих случаях отсутствие аппаратной поддержки, в настоящее время проблематично. В противном случае это хорошо для непосвященных в шифровании, так как оно имеет встроенную аутентификацию и кажется будущим.
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

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

A word of introduction: This answer was partly a response to a lot of questions I've seen under the [encryption] tag that showed people deploying utterly insecure code. Addressing these programmers I wrote the following opening sentence with the intend to shake them up enough to rethink their approach to cryptography, доtheir application gets attacked. If you are here in the process of learning, that's great! We need more programmers with background knowledge in cryptography. Keep on asking and add a silent "yet!" to my opening:

If you need to ask this question, you probably don't know enough about cryptography to implement a secure system.

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

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

This is not a hypothetical scenario: У Microsoft был именно такой недостаток в ASP.NET еще несколько лет назад.

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

What to do if you need to encrypt data

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

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

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

For educational purposes a comparison of the modes Encryption only: Modes that require padding: Like in the example, padding can generally be dangerous because it opens up the possibility of padding oracle attacks. The easiest defense is to authenticate every message before decryption. See below. ECB encrypts each block of data independently and the same plaintext block will result in the same ciphertext block. Take a look at the ECB encrypted Tux image on the ECB Wikipedia page to see why this is a serious problem. I don't know of any use case where ECB would be acceptable. CBC has an IV and thus needs randomness every time a message is encrypted, changing a part of the message requires re-encrypting everything after the change, transmission errors in one ciphertext block completely destroy the plaintext and change the decryption of the next block, decryption can be parallelized / encryption can't, the plaintext is malleable to a certain degree - this can be a problem. Stream cipher modes: These modes generate a pseudo random stream of data that may or may not depend the plaintext. Similarly to stream ciphers generally, the generated pseudo random stream is XORed with the plaintext to generate the ciphertext. As you can use as many bits of the random stream as you like you don't need padding at all. Disadvantage of this simplicity is that the encryption is completely malleable, meaning that the decryption can be changed by an attacker in any way he likes as for a plaintext p1, a ciphertext c1 and a pseudo random stream r and attacker can choose a difference d such that the decryption of a ciphertext c2=c1⊕d is p2 = p1⊕d, as p2 = c2⊕r = (c1 ⊕ d) ⊕ r = d ⊕ (c1 ⊕ r). Also the same pseudo random stream must never be used twice as for two ciphertexts c1=p1⊕r and c2=p2⊕r, an attacker can compute the xor of the two plaintexts as c1⊕c2=p1⊕r⊕p2⊕r=p1⊕p2. That also means that changing the message requires complete reencryption, if the original message could have been obtained by an attacker. All of the following steam cipher modes only need the encryption operation of the block cipher, so depending on the cipher this might save some (silicon or machine code) space in extremely constricted environments. CTR is simple, it creates a pseudo random stream that is independent of the plaintext, different pseudo random streams are obtained by counting up from different nonces/IVs which are multiplied by a maximum message length so that overlap is prevented, using nonces message encryption is possible without per message randomness, decryption and encryption are completed parallelizable, transmission errors only effect the wrong bits and nothing more OFB also creates a pseudo random stream independent of the plaintext, different pseudo random streams are obtained by starting with a different nonce or random IV for every message, neither encryption nor decryption is parallelizable, as with CTR using nonces message encryption is possible without per message randomness, as with CTR transmission errors only effect the wrong bits and nothing more CFB's pseudo random stream depends on the plaintext, a different nonce or random IV is needed for every message, like with CTR and OFB using nonces message encryption is possible without per message randomness, decryption is parallelizable / encryption is not, transmission errors completely destroy the following block, but only effect the wrong bits in the current block Disk encryption modes: These modes are specialized to encrypt data below the file system abstraction. For efficiency reasons changing some data on the disc must only require the rewrite of at most one disc block (512 bytes or 4kib). They are out of scope of this answer as they have vastly different usage scenarios than the other. Don't use them for anything except block level disc encryption. Some members: XEX, XTS, LRW. Authenticated encryption:

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

CCM is a simple combination of CTR mode and a CBC-MAC. Using two block cipher encryptions per block it is very slow. OCB is faster but encumbered by patents. For free (as in freedom) or non-military software the patent holder has granted a free license, though. GCM is a very fast but arguably complex combination of CTR mode and GHASH, a MAC over the Galois field with 2^128 elements. Its wide use in important network standards like TLS 1.2 is reflected by a special instruction Intel has introduced to speed up the calculation of GHASH. Recommendation:

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

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

Похожие вопросы