Какие из них предпочтительнее при каких обстоятельствах?
Я хотел бы увидеть список критериев оценки для различных режимов и, возможно, обсуждение применимости каждого критерия.
Например, я думаю, что одним из критериев является «размер кода» для шифрования и дешифрования, что важно для встроенных систем микрокода, таких как сетевые адаптеры 802.11. Если код, необходимый для реализации CBC, намного меньше, чем тот, который требуется для CTR (я не знаю, это правда, это всего лишь пример), тогда я мог бы понять, почему предпочтителен режим с меньшим кодом. Но если я пишу приложение, которое работает на сервере, а библиотека AES, которую я использую, в любом случае реализует CBC и CTR, то этот критерий не имеет значения.
Видите, что я имею в виду под «списком критериев оценки и применимости каждого критерия»?
Это на самом деле не связано с программированием, но связано с алгоритмом.
источник
Ответы:
ECB не следует использовать при шифровании более одного блока данных одним и тем же ключом.
CBC, OFB и CFB похожи, однако OFB / CFB лучше, потому что вам нужно только шифрование, а не дешифрование, что может сэкономить место на коде.
CTR используется, если вы хотите хорошее распараллеливание (т.е. скорость), вместо CBC / OFB / CFB.
Режим XTS является наиболее распространенным, если вы кодируете произвольно доступные данные (например, жесткий диск или ОЗУ).
OCB - безусловно лучший режим, поскольку он позволяет шифрование и аутентификацию за один проход. Однако на это есть патенты в США.
Единственное, что вам действительно нужно знать, это то, что ECB не должен использоваться, если вы не шифруете только 1 блок. XTS следует использовать, если вы шифруете данные с произвольным доступом, а не поток.
источник
Пожалуйста, подумайте долго и усердно, если вы не можете обойти свою собственную криптографию
Ужасная правда в том, что если вы зададите этот вопрос, вы, вероятно, не сможете разработать и внедрить защищенную систему.
Позвольте мне проиллюстрировать мою мысль: представьте, что вы создаете веб-приложение и вам необходимо сохранить некоторые данные сеанса. Можно назначить каждому пользователю идентификатор сеанса и сохранить данные сеанса на сервере в виде идентификатора сеанса, отображающего хеш-карту, в данные сеанса. Но тогда вам придется иметь дело с этим неприятным состоянием на сервере, и если в какой-то момент вам понадобится более одного сервера, все станет грязно. Таким образом, вместо этого у вас есть идея сохранить данные сеанса в файле cookie на стороне клиента. Вы, конечно, зашифруете его, чтобы пользователь не мог читать и манипулировать данными. Так какой режим вы должны использовать? Приходя сюда, вы читаете верхний ответ (извините, что выделил вас в myforwik). Первый из них - ECB - не для вас, вы хотите зашифровать более одного блока, следующий - CBC - звучит хорошо, и вам не нужен параллелизм CTR, вам не нужен произвольный доступ, поэтому XTS и патенты не являются PITA, поэтому OCB нет. Используя свою криптографическую библиотеку, вы понимаете, что вам нужны некоторые отступы, потому что вы можете только зашифровать кратные размеру блока. Твой выборPKCS7, потому что это было определено в некоторых серьезных стандартах криптографии. После прочтения где-то, что CBC надежно защищен, если используется со случайным IV и защищенным блочным шифром, вы успокоитесь, даже если вы храните ваши конфиденциальные данные на стороне клиента.
Спустя годы после того, как ваши услуги действительно выросли до значительных размеров, специалист по информационной безопасности свяжется с вами в ответственном раскрытии. Она говорит вам, что может расшифровать все ваши куки с помощью атаки оракула заполнения , потому что ваш код выдает страницу с ошибкой, если заполнение каким-то образом нарушено.
Это не гипотетический сценарий: у Microsoft был именно такой недостаток в ASP.NET еще несколько лет назад.
Проблема в том, что в криптографии есть много подводных камней, и очень легко создать систему, которая выглядит безопасной для неспециалистов, но тривиальной для взломщика.
Что делать, если вам нужно зашифровать данные
Для активных соединений используйте TLS (обязательно проверьте имя хоста сертификата и цепочку эмитента). Если вы не можете использовать TLS, найдите API самого высокого уровня, который ваша система может предложить для вашей задачи, и убедитесь, что вы понимаете гарантии, которые она предлагает, и, что более важно, то, что она не гарантирует. В приведенном выше примере среда, подобная Play, предлагает средства хранения на стороне клиента , однако через некоторое время она не делает недействительными хранимые данные, и если вы изменили состояние на стороне клиента, злоумышленник может восстановить предыдущее состояние без вашего уведомления.
Если высокоуровневая абстракция недоступна, используйте криптографическую библиотеку высокого уровня. Ярким примером является NaCl, а переносимая реализация со многими языковыми привязками - Sodium . Используя такую библиотеку, вам не нужно заботиться о режимах шифрования и т. Д., Но вы должны быть еще более внимательны к деталям использования, чем с абстракцией более высокого уровня, как никогда не используйте одноразовый номер дважды.
Если по какой-то причине вы не можете использовать высокоуровневую криптобиблиотеку, например, из-за того, что вам нужно особым образом взаимодействовать с существующей системой, невозможно провести тщательное обучение. Я рекомендую ознакомиться с Криптографической инженерией Фергюсона, Коно и Шнайера . Пожалуйста, не обманывайте себя, полагая, что вы можете создать безопасную систему без необходимой подготовки. Криптография чрезвычайно тонка, и почти невозможно проверить безопасность системы.
Сравнение режимов
Только шифрование:
Аутентифицированное шифрование:
Чтобы предотвратить атаки оракула и изменения зашифрованного текста, можно зашифровать код аутентификации сообщения (MAC) на зашифрованном тексте и расшифровать его, только если он не был подделан. Это называется encrypt-then-mac и должно быть предпочтительнее любого другого порядка . За исключением очень немногих случаев использования аутентичность так же важна, как и конфиденциальность (последняя из которых является целью шифрования). Схемы шифрования с аутентификацией (со связанными данными (AEAD)) объединяют двухэтапный процесс шифрования и аутентификации в один режим блочного шифра, который также создает тег аутентификации в процессе. В большинстве случаев это приводит к улучшению скорости.
Рекомендация:
Учитывая важность аутентификации, я бы порекомендовал следующие два режима блочного шифрования для большинства случаев использования (за исключением целей шифрования диска): если данные аутентифицируются асимметричной подписью, используйте CBC, в противном случае используйте GCM.
источник
https://your.server
везде в своем приложении, чем придумывать какой-либо протокол обмена ключами и заставить библиотеки криптографии с обеих сторон работать гладко.Формальный анализ был сделан Филом Рогэвеем в 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 бит. Широко стандартизирован и используется.
источник
источник
Вы начали с чтения информации об этом в Википедии - Режимы работы блочного шифра ? Затем перейдите по ссылке в Википедии на NIST: Рекомендация для режимов работы блочного шифра .
источник
Вы можете выбрать на основе того, что широко доступно. У меня был тот же вопрос, и вот результаты моего ограниченного исследования.
Аппаратные ограничения
Ограничения открытого источника
[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 для произвольного доступа.
источник