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

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

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

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

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

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

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.



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

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



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](https://en.wikipedia.org/wiki/Initialization_vector)'s every time you encrypt, and they should be [random](https://en.wikipedia.org/wiki/Cryptographically_secure_pseudorandom_number_generator). If you cannot guarantee they are [random](https://en.wikipedia.org/wiki/Cryptographically_secure_pseudorandom_number_generator), use OCB as it only requires a [nonce](https://en.wikipedia.org/wiki/Cryptographic_nonce), not an [IV](https://en.wikipedia.org/wiki/Initialization_vector), and there is a distinct difference. A [nonce](https://en.wikipedia.org/wiki/Cryptographic_nonce) does not drop security if people can guess the next one, an [IV](https://en.wikipedia.org/wiki/Initialization_vector) can cause this problem.



[Режимы работы блочного шифра](https://en.wikipedia.org/wiki/Block_cipher_modes_of_operation)? Затем перейдите по ссылке в Википедии, чтобы[NIST: Рекомендация для режимов работы блочного шифра](http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38a.pdf).



[Вот](http://web.cs.ucdavis.edu/~rogaway/papers/modes.pdf), В разделе 1.6 приводится краткое изложение, которое я здесь переписываю, добавляя мой собственный акцент на полужирном шрифте (если вы нетерпеливы, тогда его рекомендация - использовать режим CTR, но я предлагаю вам прочитать мои параграфы о целостности сообщений и шифровании ниже).

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

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

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

Если вам нужны и целостность сообщения, и шифрование, вы можете объединить два алгоритма: обычно мы видим CBC с HMAC, но нет причин связывать себя с CBC. Важно знать, что[сначала зашифруйте, затем MAC зашифрованный контент](https://crypto.stackexchange.com/questions/202/should-we-mac-then-encrypt-or-encrypt-then-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].

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

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

**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 бит. Широко стандартизирован и используется.



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

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

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

[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>



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](https://en.wikipedia.org/wiki/Padding_%28cryptography%29#PKCS7) потому что это было определено в некоторых серьезных стандартах криптографии. Прочитав где-то, что CBC[доказуемо безопасный](https://crypto.stackexchange.com/questions/3883/why-is-cbc-with-predictable-iv-considered-insecure-against-cpa) если вы используете случайный IV и защищенный блочный шифр, вы будете спокойны, даже если храните ваши конфиденциальные данные на стороне клиента.

Спустя годы после того, как ваши услуги действительно выросли до значительных размеров, специалист по информационной безопасности свяжется с вами в ответственном раскрытии. Она говорит вам, что может расшифровать все ваши куки, используя[набивка оракула](https://blog.skullsecurity.org/2013/a-padding-oracle-example)потому что ваш код выдает страницу с ошибкой, если заполнение каким-то образом нарушено.

**This is not a hypothetical scenario:** [У Microsoft был именно такой недостаток в ASP.NET еще несколько лет назад.](https://weblogs.asp.net/scottgu/archive/2010/09/18/important-asp-net-security-vulnerability.aspx)

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

What to do if you need to encrypt data
Для активных соединений используйте TLS (обязательно проверьте имя хоста сертификата и цепочку эмитента). Если вы не можете использовать TLS, найдите API самого высокого уровня, который ваша система может предложить для вашей задачи, и убедитесь, что вы понимаете гарантии, которые она предлагает, и, что более важно, то, что она не гарантирует. Для примера выше рамки, такие какPlay предложения[складские помещения на стороне клиента](https://www.playframework.com/documentation/2.1.3/ScalaSessionFlash)Однако через некоторое время сохраненные данные не будут признаны недействительными, и если вы изменили состояние на стороне клиента, злоумышленник может восстановить предыдущее состояние без вашего ведома.

Если высокоуровневая абстракция недоступна, используйте криптографическую библиотеку высокого уровня. Ярким примером является[NaCl](https://nacl.cr.yp.to/index.html) и переносимая реализация со многими языковыми привязками[натрий](http://labs.umbrella.com/2013/03/06/announcing-sodium-a-new-cryptographic-library/), Используя такую библиотеку, вам не нужно заботиться о режимах шифрования и т. Д., Но вы должны быть еще более внимательны к деталям использования, чем с абстракцией более высокого уровня, как никогда не используйте одноразовый номер дважды.

Если по какой-то причине вы не можете использовать высокоуровневую криптобиблиотеку, например, из-за того, что вам нужно определенным образом взаимодействовать с существующей системой, нет никакого способа тщательно обучить себя. Я рекомендую прочитать[Инженерная криптография Фергюсона, Коно и Шнайера](https://www.schneier.com/book-ce.html), Пожалуйста, не обманывайте себя, полагая, что вы можете создать безопасную систему без необходимой подготовки. Криптография чрезвычайно тонка, и практически невозможно проверить безопасность системы.

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](https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Electronic_Codebook_(ECB)) 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](http://www.jakoblell.com/blog/2013/12/22/practical-malleability-attack-against-cbc-encrypted-luks-partitions/).
**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](https://en.wikipedia.org/wiki/Malleability_%28cryptography%29), 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](https://en.wikipedia.org/wiki/Disk_encryption_theory): 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](http://sockpuppet.org/blog/2014/04/30/you-dont-want-xts/). Some members: XEX, XTS, LRW.
Authenticated encryption:
Чтобы предотвратить атаки оракула дополнения и изменения в зашифрованном тексте, можно вычислить[код аутентификации сообщения](https://en.wikipedia.org/wiki/Message_authentication_code) (MAC) на зашифрованном тексте и расшифровывать его, только если он не был подделан. Это называется encrypt-then-mac и[должно быть предпочтительнее любого другого заказа](http://www.thoughtcrime.org/blog/the-cryptographic-doom-principle/), За исключением очень немногих случаев использования аутентичность так же важна, как и конфиденциальность (последняя из которых является целью шифрования). Схемы шифрования с аутентификацией (со связанными данными (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](http://www.cs.ucdavis.edu/~rogaway/ocb/license.htm), 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](https://software.intel.com/en-us/articles/intel-carry-less-multiplication-instruction-and-its-usage-for-computing-the-gcm-mode) Intel has introduced to speed up the calculation of GHASH.
Recommendation:
Учитывая важность аутентификации, я бы порекомендовал следующие два режима блочного шифрования для большинства случаев использования (за исключением целей шифрования диска): если данные аутентифицируются асимметричной подписью, используйте CBC, в противном случае используйте GCM.