Как выбрать режим шифрования AES (CBC ECB, CTR OCB, CFB)?
https://stackoverflow.com/questions/1220751
-
10-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Какие из них предпочтительнее при каких обстоятельствах?
Я хотел бы увидеть список критериев оценки для различных режимов и, возможно, обсуждение применимости каждого критерия.
Например, Я думаю, что одним из критериев является "размер кода" для шифрования и дешифрования, что важно для встроенных систем с микрокодированием, таких как сетевые адаптеры стандарта 802.11.ЕСЛИ код, необходимый для реализации CBC, намного меньше, чем требуется для CTR (я не знаю, правда ли это, это всего лишь пример), тогда я мог бы понять, почему режим с меньшим кодом был бы предпочтительнее.Но если я пишу приложение, которое работает на сервере, а библиотека AES, которую я использую, в любом случае реализует как CBC, так и CTR, то этот критерий не имеет значения.
Понимаете, что я подразумеваю под "списком критериев оценки и применимостью каждого критерия"??
На самом деле это не связано с программированием, но связано с алгоритмом.
Решение
ECB не следует использовать при шифровании более чем одного блока данных одним и тем же ключом.
CBC, OFB и CFB похожи, однако OFB / CFB лучше, потому что вам нужно только шифрование, а не дешифрование, что может сэкономить место для кода.
CTR используется, если вы хотите хорошего распараллеливания (т.е.скорость), вместо CBC/OFB/CFB.
Режим XTS является наиболее распространенным, если вы кодируете произвольно доступные данные (например, жесткий диск или оперативную память).
OCB, безусловно, является лучшим режимом, поскольку он позволяет осуществлять шифрование и аутентификацию за один проход.Однако в США на это есть патенты.
Единственное, что вам действительно нужно знать, это то, что ECB не следует использовать, если вы не шифруете только 1 блок.XTS следует использовать, если вы шифруете данные, к которым осуществляется случайный доступ, а не поток.
- Вы ВСЕГДА должны использовать уникальный IVэто происходит каждый раз, когда вы шифруете, и они должны быть Случайный.Если вы не можете гарантировать, что они Случайный, используйте OCB , поскольку для этого требуется только одноразовый, не являющийся IV, и есть явная разница.A одноразовый не снижает уровень безопасности, если люди могут угадать следующий, IV может вызвать эту проблему.
Другие советы
Пожалуйста, подумайте долго и упорно, если вы не можете обойтись без внедрения своей собственной криптографии
Уродливая правда заключается в том, что если вы задаете этот вопрос, вы, вероятно, не сможете спроектировать и внедрить безопасную систему.
Позвольте мне проиллюстрировать свою мысль:Представьте, что вы создаете веб-приложение, и вам нужно сохранить некоторые данные сеанса.Вы могли бы присвоить каждому пользователю идентификатор сеанса и сохранить данные сеанса на сервере в хэш-карте, сопоставляющей идентификатор сеанса с данными сеанса.Но тогда вам придется иметь дело с этим надоедливым состоянием сервера, и если в какой-то момент вам понадобится больше одного сервера, все пойдет наперекосяк.Итак, вместо этого у вас есть идея сохранить данные сеанса в файле cookie на стороне клиента.Вы, конечно, зашифруете его, чтобы пользователь не мог читать данные и манипулировать ими.Итак, какой режим вам следует использовать?Заходя сюда, вы читаете верхний ответ (извините, что выделил вас из myforwik).Первый рассмотренный - ECB - не для вас, вы хотите зашифровать более одного блока, следующий - CBC - звучит неплохо, и вам не нужен параллелизм CTR, вам не нужен произвольный доступ, поэтому никакие XTS и патенты не являются PITA, поэтому никакого OCB.Используя свою криптографическую библиотеку, вы понимаете, что вам нужно некоторое дополнение, потому что вы можете зашифровать только значения, кратные размеру блока.Ты выбираешь PKCS7 потому что это было определено в некоторых серьезных стандартах криптографии.Прочитав где-то, что CBC является доказуемо безопасный при использовании случайного ввода-вывода и защищенного блочного шифрования вы можете быть спокойны, даже если храните свои конфиденциальные данные на стороне клиента.
Спустя годы, после того как ваш сервис действительно вырос до значительных размеров, специалист по ИТ-безопасности связывается с вами для ответственного раскрытия информации.Она говорит вам, что может расшифровать все ваши файлы cookie с помощью дополняющая атака оракула, потому что ваш код выдает страницу с ошибкой, если заполнение каким-то образом нарушено.
Это не гипотетический сценарий: У Microsoft был именно этот недостаток в ASP.NET еще несколько лет назад.
Проблема в том, что существует множество подводных камней, связанных с криптографией, и чрезвычайно легко создать систему, которая выглядит безопасной для непрофессионала, но которую тривиально взломать знающему злоумышленнику.
Что делать, если вам нужно зашифровать данные
Для активных подключений используйте TLS (обязательно проверьте имя хоста сертификата и цепочку отправителей).Если вы не можете использовать TLS, поищите API самого высокого уровня, который ваша система может предложить для вашей задачи, и убедитесь, что вы понимаете гарантии, которые он предлагает, и, что более важно, чего он не гарантирует.В приведенном выше примере фреймворк типа Воспроизвести Предложения складские помещения на стороне клиента, Однако через некоторое время это не делает сохраненные данные недействительными, и если вы изменили состояние на стороне клиента, злоумышленник может восстановить предыдущее состояние незаметно для вас.
Если нет доступной высокоуровневой абстракции, используйте высокоуровневую криптографическую библиотеку.Ярким примером является NaCl и переносимая реализация со многими языковыми привязками - это Натрий.Используя такую библиотеку, вам не нужно заботиться о режимах шифрования и т.д.но вы должны быть еще более осторожны с деталями использования, чем при абстракции более высокого уровня, например, никогда не использовать одноразовый номер дважды.
Если по какой-то причине вы не можете использовать высокоуровневую криптографическую библиотеку, например, потому, что вам нужно определенным образом взаимодействовать с существующей системой, нет никакого способа обойти тщательное обучение.Я рекомендую прочитать Разработка криптографии Фергюсоном, Коно и Шнайером.Пожалуйста, не обманывайте себя, полагая, что вы можете создать безопасную систему без необходимой подготовки.Криптография чрезвычайно тонка, и проверить безопасность системы практически невозможно.
Сравнение режимов
Только шифрование:
- Режимы, требующие заполнения:Как и в примере, заполнение обычно может быть опасным, поскольку оно открывает возможность атак oracle с дополнением.Самая простая защита - проверять подлинность каждого сообщения перед расшифровкой.Смотрите ниже.
- ЕЦБ шифрует каждый блок данных независимо, и один и тот же блок открытого текста приведет к одному и тому же блоку зашифрованного текста.Взгляните на зашифрованное изображение смокинга ЕЦБ на Страница ЕЦБ в Википедии чтобы понять, почему это серьезная проблема.Я не знаю ни одного варианта использования, в котором ЕЦБ был бы приемлемым.
- Си - Би - Си имеет IV и, следовательно, нуждается в случайности каждый раз, когда сообщение зашифровывается, изменение части сообщения требует повторного шифрования всего после изменения, ошибки передачи в одном блоке зашифрованного текста полностью уничтожают открытый текст и изменяют расшифровку следующего блока, дешифрование может быть распараллелено / шифрование невозможно, открытый текст в определенной степени податлив - это может быть проблемой.
- Режимы потокового шифрования:Эти режимы генерируют псевдослучайный поток данных, который может зависеть от открытого текста, а может и не зависеть.Аналогично потоковым шифрам в целом, сгенерированный псевдослучайный поток преобразуется в открытый текст для генерации зашифрованного текста.Поскольку вы можете использовать столько битов случайного потока, сколько захотите, вам вообще не нужно заполнение.Недостатком такой простоты является то, что шифрование полностью податливый, это означает , что расшифровка может быть изменен злоумышленником в любом случае он любит, как для обычного текста Р1, а шифротекст C1 и псевдо случайного потока R и он может выбрать ситуацию D таким образом, что расшифровка зашифрованного текста С2=С1⊕D равен Р2 = Р1⊕D, а П2 = С2⊕Р = (С1 ⊕ д) ⊕ р = д ⊕ (С1 ⊕ Р).И тот же псевдослучайный поток никогда не должны использоваться два раза в течение двух шифртекстов С1=Р1⊕р и С2=Р2⊕Р, злоумышленник может вычислить XOR с двух plaintexts как C1⊕С2=Р1⊕Р⊕Р2⊕Р=Р1⊕Р2.Это также означает, что изменение сообщения требует полного повторного шифрования, если исходное сообщение могло быть получено злоумышленником.Для всех следующих режимов шифрования steam требуется только операция шифрования блочным шифром, поэтому в зависимости от шифра это может сэкономить некоторое пространство (на кремнии или машинном коде) в чрезвычайно ограниченных средах.
- CTR это просто, это создает псевдослучайный поток, который не зависит от открытого текста, различные псевдослучайные потоки получаются путем подсчета из разных одноразовых номеров / IV, которые умножаются на максимальную длину сообщения, чтобы предотвратить перекрытие, использование шифрования одноразовых сообщений возможно без случайности для каждого сообщения, дешифрование и шифрование выполняются параллельно, ошибки передачи влияют только на неправильные биты и ничего более
- ОФБ также создает псевдослучайный поток, независимый от открытого текста, разные псевдослучайные потоки получаются при запуске с другого одноразового номера или случайного IV для каждого сообщения, ни шифрование, ни дешифрование не распараллеливаются, так как при шифровании сообщений с использованием одноразовых номеров возможно шифрование сообщений без случайности для каждого сообщения, так как при ошибках передачи CTR только неправильные биты и ничего более
- CFBпсевдослучайный поток зависит от открытого текста, для каждого сообщения требуется другой одноразовый номер или случайный IV, например, в случае CTR и OFB с использованием одноразовых номеров шифрование сообщений возможно без случайности для каждого сообщения, дешифрование распараллеливается / шифрование - нет, ошибки передачи полностью уничтожают следующий блок, но влияют только на неправильные биты в текущем блоке
- Режимы шифрования диска:Эти режимы специализированы для шифрования данных ниже абстракции файловой системы.По соображениям эффективности изменение некоторых данных на диске должно требовать перезаписи не более одного блока диска (512 байт или 4 кб).Они выходят за рамки этого ответа, поскольку их сценарии использования сильно отличаются от других. Не используйте их ни для чего, кроме шифрования диска на уровне блоков.Некоторые участники:XEX, XTS, ЖРО.
Аутентифицированное шифрование:
Чтобы предотвратить атаки oracle с дополнением и изменения зашифрованного текста, можно вычислить код аутентификации сообщения (MAC) в зашифрованном тексте и расшифровывать его только в том случае, если он не был подделан.Это называется encrypt-then-mac и должен быть предпочтительнее любого другого заказа.За исключением очень немногих случаев использования, аутентичность так же важна, как и конфиденциальность (последняя из которых является целью шифрования).Аутентифицированные схемы шифрования (с ассоциированными данными (AEAD)) объединяют процесс шифрования и аутентификации из двух частей в один режим блочного шифрования, который также создает тег аутентификации в процессе.В большинстве случаев это приводит к повышению скорости.
- СКК представляет собой простую комбинацию режима CTR и CBC-MAC.Используя два блочных шифрования на блок, это происходит очень медленно.
- OCB это быстрее, но обременено патентами.На бесплатное (как в freedom) или невоенное программное обеспечение владелец патента предоставил бесплатную лицензию, хотя.
- GCM это очень быстрая, но, возможно, сложная комбинация режима CTR и GHASH, MAC-адреса над полем Галуа с 2 ^ 128 элементами.Его широкое использование в важных сетевых стандартах, таких как TLS 1.2, отражается специальная инструкция Intel внедрила для ускорения вычисления GHASH.
Рекомендация:
Учитывая важность аутентификации, я бы рекомендовал следующие два режима блочного шифрования для большинства случаев использования (за исключением целей шифрования диска):Если данные аутентифицируются с помощью асимметричной подписи, используйте CBC, в противном случае используйте GCM.
Формальный анализ был проведен Филом Рогавеем в 2011 году, здесь . В разделе 1.6 приводится краткое изложение, которое я здесь переписываю, добавляя мой собственный акцент на полужирном шрифте (если вы нетерпеливы, тогда его рекомендация - использовать режим CTR, но я предлагаю вам прочитать мои параграфы о целостности сообщений и шифровании ниже).
Обратите внимание, что большинство из них требуют, чтобы IV был случайным, что означает непредсказуемость и, следовательно, должно быть сгенерировано с криптографической безопасностью. Однако некоторые требуют только «nonce», который не требует этого свойства, а вместо этого требует только того, чтобы оно не использовалось повторно. Поэтому проекты, которые полагаются на одноразовый номер, менее подвержены ошибкам, чем проекты, которые этого не делают (и поверьте мне, я видел много случаев, когда CBC не реализован при правильном выборе IV). Таким образом, вы увидите, что я добавил жирный шрифт, когда Рогавей говорит, что что-то вроде «конфиденциальности не достигается, когда IV - это одноразовый номер», это означает, что если вы выберете свой криптографически безопасный (непредсказуемый) IV, то проблем не будет. Но если вы этого не сделаете, то вы потеряете хорошие свойства безопасности. Никогда не используйте IV для любого из этих режимов.
Кроме того, важно понимать разницу между целостностью сообщения и шифрованием. Шифрование скрывает данные, но злоумышленник может изменить зашифрованные данные, и результаты могут быть приняты вашим программным обеспечением, если вы не проверите целостность сообщения. Хотя разработчик скажет «но измененные данные вернутся как мусор после расшифровки», хороший инженер по безопасности обнаружит вероятность того, что мусор вызовет нежелательное поведение в программном обеспечении, а затем превратит этот анализ в настоящую атаку. Я видел много случаев, когда использовалось шифрование, но целостность сообщения была действительно нужна больше, чем шифрование. Понять, что вам нужно.
Я должен сказать, что, хотя GCM обладает как шифрованием, так и целостностью сообщений, это очень хрупкая конструкция: если вы повторно используете IV, вы облажались - злоумышленник может восстановить ваш ключ. Другие проекты менее хрупки, поэтому я лично боюсь рекомендовать GCM, основываясь на количестве плохого кода шифрования, которое я видел на практике.
Если вам нужны и целостность сообщения, и шифрование, вы можете объединить два алгоритма: обычно мы видим CBC с HMAC, но нет причин связывать себя с CBC. Важно знать, сначала зашифруйте, а затем MAC зашифрованный контент , а не наоборот. Кроме того, IV должен быть частью вычисления MAC.
Мне не известны проблемы с IP.
Теперь к хорошим материалам от профессора Рогэвея:
Режимы блочных шифров, шифрование, но не целостность сообщений
ECB : блочный шифр, режим шифрует сообщения, кратные n битам, путем отдельного шифрования каждого n-битного фрагмента. Свойства безопасности являются слабыми , метод утечки равенства блоков по позициям блоков и времени. Имеет значительную унаследованную ценность и ценность как строительный блок для других схем, но режим не достигает какой-либо вообще желаемой цели безопасности сам по себе и должен использоваться со значительной осторожностью; ЕЦБ не следует рассматривать как «универсальный» режим конфиденциальности .
CBC . Схема шифрования, основанная на IV, режим безопасен как вероятностная схема шифрования, обеспечивающая неразличимость от случайных битов при условии случайного IV. Конфиденциальность не достигается, если IV является просто одноразовым номером , или если это одноразовый номер, зашифрованный под тем же ключом, который используется схемой, как это неверно предлагается в стандарте. Ciphertexts очень податливы. Нет выбранной защиты от зашифрованного текста (CCA).Конфиденциальность утрачивается при наличии правильного дополнения оракула для многих методов заполнения. Шифрование неэффективно из-за его серийности. Широко используемые свойства безопасности режима только для конфиденциальности приводят к частому неправильному использованию. Может использоваться как строительный блок для алгоритмов CBC-MAC. Я не вижу важных преимуществ по сравнению с режимом CTR.
CFB . Схема шифрования, основанная на IV, режим безопасен как вероятностная схема шифрования, обеспечивающая неразличимость от случайных битов при условии случайного IV. Конфиденциальность не достигается, если IV является предсказуемым , или если он сделан одноразовым номером, зашифрованным под тем же ключом, который используется схемой, как это неверно предлагается в стандарте. Шифротексты податливы. Нет CCA-безопасности. Шифрование неэффективно из-за его серийности. Схема зависит от параметра s, 1 & # 8804; s & # 8804; n, обычно s = 1 или s = 8. Неэффективно для необходимости одного вызова блочного шифра для обработки только s битов. Режим обеспечивает интересную & # 8220; самосинхронизацию & # 8221; имущество; вставка или удаление любого количества s-битных символов в зашифрованный текст только временно нарушает правильное дешифрование.
OFB . Схема шифрования на основе IV обеспечивает безопасный режим в виде вероятностной схемы шифрования, обеспечивающей неразличимость от случайных битов при условии случайного IV. Конфиденциальность не достигается, если IV - это одноразовый номер, хотя фиксированная последовательность IV (например, счетчик) работает нормально. Ciphertexts очень податливы. Нет CCA безопасности. Шифрование и дешифрование неэффективно из-за их последовательной Нативно шифрует строки любой битовой длины (заполнение не требуется). Я не могу определить никаких важных преимуществ по сравнению с режимом CTR.
CTR : в схеме шифрования на основе IV этот режим обеспечивает неразличимость от случайных битов, предполагая одноразовый IV. В качестве безопасной схемы, основанной на одноразовом использовании, режим также может использоваться в качестве вероятностной схемы шифрования со случайным IV. Полный сбой конфиденциальности, если одноразовый номер повторно используется при шифровании или дешифровании. Распараллеливаемость режима часто делает его быстрее, в некоторых настройках, намного быстрее, чем другие режимы конфиденциальности. Важный строительный блок для схем аутентифицированного шифрования. В целом, обычно это лучший и самый современный способ шифрования только для конфиденциальности.
XTS . Схема шифрования на основе IV. Этот режим работает путем применения настраиваемого блочного шифра (защищенного как сильный PRP) к каждому n-битному фрагменту. Для сообщений, длина которых не делится на n, последние два блока обрабатываются специально. Единственное разрешенное использование режима - для шифрования данных на устройстве с блочной структурой. Узкая ширина основного PRP и плохая обработка дробных конечных блоков являются проблемами. Более эффективный, но менее желательный, чем (широко-блочный) PRP-защищенный блочный шифр.
MAC (целостность сообщения, но не шифрование)
ALG1 & # 8211; 6 : набор MAC, все из которых основаны на CBC-MAC. Слишком много схем. Некоторые из них надежно защищены как VIL PRF, некоторые - FIL PRF, а некоторые не имеют доказуемой безопасности. Некоторые схемы допускают разрушительные атаки. Некоторые из режимов устарели. Разделение клавиш недостаточно подходит для режимов, которые его имеют. Не должны приниматься в массовом порядке, но должны выборочно выбирать & # 8220; best & # 8221; схемы возможны. Также было бы хорошо принять ни один из этих режимов в пользу CMAC. Некоторые из MAC ISO 9797-1 широко стандартизированы и используются, особенно в банковской сфере. Скоро будет выпущена пересмотренная версия стандарта (ISO / IEC FDIS 9797-1: 2010) [93].
CMAC : MAC, основанный на CBC-MAC, режим гарантированно безопасен (до границы дня рождения) в виде (VIL) PRF (при условии, что базовый блочный шифр является хорошим PRP). По существу минимальные издержки для схемы на основе CBCMAC. По своей сути
Начните с чтения информации об этом в Википедии - Режимы работы блочного шифра ? Затем перейдите по ссылочной ссылке в Википедии на 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
Мне известен один аспект: хотя CBC обеспечивает лучшую безопасность, изменяя IV для каждого блока, он не применим к зашифрованному контенту с произвольным доступом (например, к зашифрованному жесткому диску).
Итак, используйте CBC (и другие последовательные режимы) для последовательных потоков и ECB для произвольного доступа.
