слово введения: этот ответ был частично ответом на многие вопросы, которые я видел под [encryption] тег, который показал, что люди, развернув совершенно небезопасный код. Обращаясь к этим программистам, я написал следующее вступительное предложение с намерением встряхнуть их достаточно, чтобы переосмыслить их подход к криптографии, до их применение напали. Если вы находитесь здесь в процессе обучения, это здорово! Нам нужно больше программистов с базовыми знаниями в области криптографии. Продолжайте спрашивать и добавляйте тихое " пока! к моему открытию:

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

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

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

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

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

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

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

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

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

для образовательных целей сравнения режимы

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

• режимы, требующие заполнения: Как и в Примере, заполнение обычно может быть опасным, потому что оно открывает возможность атак oracle. Самая простая защита-аутентифицировать каждое сообщение перед расшифровкой. Увидеть ниже.
  • ЕЦБ шифрует каждый блок данных независимо, и один и тот же блок открытого текста приведет к одному и тому же блоку зашифрованного текста. Взгляните на ЕЦБ зашифрованное изображение смокинга на страница Википедии ЕЦБ чтобы понять, почему это серьезная проблема. Я не знаю ни одного случая использования, когда ЕЦБ был бы приемлемым.
  • CBC имеет IV и, таким образом, нуждается в случайности каждый раз, когда сообщение зашифровано, изменение части сообщения требует повторного шифрования всего после изменения, ошибки передачи в одном шифротекстовом блоке полностью уничтожают открытый текст и изменяют дешифрование следующего блока, дешифрование может быть распараллеливание / шифрование не может, открытый текст податлив до определенной степени - это может быть проблема.
• режимы шифрования потока: эти режимы генерируют псевдослучайный поток данных, который может зависеть или не зависеть от открытого текста. Подобно потоковым шифрам вообще, сгенерированный псевдослучайный поток XORed с открытым текстом для генерации зашифрованного текста. Поскольку вы можете использовать столько бит случайного потока, сколько вам нравится, вы не нужна прокладка вообще. Недостатком этой простоты является то, что шифрование полностью ковкий, это означает, что расшифровка может быть изменен злоумышленником в любом случае он любит, как и для обычного текста Р1, а шифротекст С1 и псевдо-случайный поток R и злоумышленник может выбрать разницу D таким образом, что расшифровка зашифрованного текста С2=С1⊕д Р2 = Р1⊕D, а Р2 = С2⊕Р = (С1 ⊕ д) ⊕ р = д ⊕ (С1 ⊕ Р). Также один и тот же псевдослучайный поток никогда не должен использоваться дважды, как для двух шифртекстов С1=Р1⊕R и С2=Р2⊕Р, злоумышленник может вычислить операции XOR двух plaintexts как С1⊕С2=Р1⊕Р⊕Р2⊕Р=Р1⊕Р2. Это также означает, что изменение сообщения требует полного повторного шифрования, если исходное сообщение могло быть получено злоумышленником. Все следующие режимы шифрования steam требуют только операции шифрования блочного шифра, поэтому в зависимости от шифра это может сэкономить некоторое пространство (кремний или машинный код) в чрезвычайно ограниченных средах.
  • CTR просто, он создает псевдослучайный поток, который не зависит от открытого текста, различные псевдослучайные потоки получаются путем подсчета из разных nonces / IVs, которые умножаются на максимальную длину сообщения, чтобы предотвратить перекрытие, используя шифрование сообщений nonces возможно без случайности сообщений, дешифрование и шифрование завершаются распараллеливаемыми, ошибки передачи влияют только на неправильные биты и ничего больше
  • OFB также создает псевдослучайный поток, независимый от открытого текста, различные псевдослучайные потоки получаются, начиная с другого nonce или random IV для каждого сообщения, ни шифрование, ни дешифрование не являются параллельными, так как с CTR использование шифрования сообщений nonces возможно без случайности сообщений, так как с CTR ошибки передачи влияют только на неправильные биты и ничего больше
  • CFBпсевдослучайный поток зависит от открытого текста, другого nonce или random IV необходим для каждого сообщения, например, с CTR и OFB с использованием nonces шифрование сообщений возможно без случайности сообщений, дешифрование распараллеливается / шифрование отсутствует, ошибки передачи полностью уничтожают следующий блок, но только влияют на неправильные биты в текущем блоке
• режимы шифрования диска: эти режимы специализированы для шифрования данных под абстракцией файловой системы. По соображениям эффективности изменение некоторых данных на диске должно потребовать перезаписи не более одного блока диска (512 байт или 4 КБ). Они выходят за рамки этого ответа, поскольку они имеют значительно разные сценарии использования, чем другие. не используйте их ни для чего, кроме шифрования диска уровня блока. Некоторые члены: XEX, XTS, LRW.

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

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

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

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

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

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

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

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

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

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

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

Я не знаю о проблемах с IP.

теперь к хорошему материалу от профессора Рогауэя:

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

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

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

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

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

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

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

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

ALG1–6: коллекция Mac, все они основаны на CBC-MAC. Слишком много планов. Некоторые из них доказуемо безопасны как Vil PRFs, некоторые как Fil PRFs, а некоторые не имеют доказуемая безопасность. Некоторые схемы допускают разрушительные атаки. Некоторые из режимов датированы. Ключ-разделение недостаточно внимания для режимов, которые имеют его. Не следует принимать массово,но возможен выборочный выбор "лучших" схем. Было бы также неплохо принять ни один из этих режимов в пользу CMAC. Некоторые Маки ISO 9797-1 широко стандартизированы и используются, особенно в банковской сфере. Вскоре будет выпущена пересмотренная версия стандарта (ISO/IEC FDIS 9797-1:2010). [93].

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

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

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

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

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

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

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

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

ограничения оборудования

STM32L (low energy ARM cores) from ST Micro support ECB, CBC,CTR GCM
CC2541 (Bluetooth Low Energy) from TI supports ECB, CBC, CFB, OFB, CTR, and CBC-MAC

ограничения с открытым исходным кодом

Original rijndael-api source  - ECB, CBC, CFB1
OpenSSL - command line CBC, CFB, CFB1, CFB8, ECB, OFB
OpenSSL - C/C++ API    CBC, CFB, CFB1, CFB8, ECB, OFB and CTR
EFAES lib [1] - ECB, CBC, PCBC, OFB, CFB, CRT ([sic] CTR mispelled)  
OpenAES [2] - ECB, CBC 

[1] http://www.codeproject.com/Articles/57478/A-Fast-and-Easy-to-Use-AES-Library

[2] https://openaes.googlecode.com/files/OpenAES-0.8.0.zip

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

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