Из Википедии, бесплатной энциклопедии
Перейти к навигации Перейти к поиску
WikiProject Криптография / Информатика (Номинальный C-класс, Высшая важность)
Значок WikiProjectЭта статья находится в рамках WikiProject Cryptography , совместной работы по расширению охвата криптографии в Википедии. Если вы хотите принять участие, посетите страницу проекта, где вы можете присоединиться к обсуждению и увидеть список открытых задач.
Статья C-класса C Эта статья была оценена как C-Class по шкале качества .
 Вершина Эта статья была оценена как Top-значение по шкале важности .
Значок рабочей группы
Эта статья поддерживается WikiProject Computer science (помечена как Top-important ).
 
WikiProject Computing / Программное обеспечение / CompSci / Безопасность (Номинальный C-класс, Средняя важность)
Значок WikiProjectЭта статья находится в рамках WikiProject Computing , совместной работы по расширению охвата компьютеров , вычислений и информационных технологий в Википедии. Если вы хотите принять участие, посетите страницу проекта, где вы можете присоединиться к обсуждению и увидеть список открытых задач.
C-Class article C Эта статья была оценена как C-Class по шкале качества проекта .
 Середина Эта статья была оценена как средняя по шкале важности проекта .
Значок рабочей группы
Эта статья поддерживается WikiProject Software (помечена как Низкая важность ).
Значок рабочей группы
Эта статья поддерживается WikiProject Computer science (помечена как Средняя ).
Значок рабочей группы
Эта статья поддерживается WikiProject Computer Security (помечена как High-important ).
 
Чем вы можете помочь WikiProject Computer science :

Вот некоторые задачи, требующие внимания:
  • Запросы на статьи  :
    • Запрошенные статьи / Прикладные искусства и науки / Информатика, вычисления и Интернет
  • Очистка  :
    • Статьи по информатике, требующие внимания
    • Статьи по информатике, требующие внимания специалистов
  • Копировать редактировать  :
    • Вычисление
  • Развернуть  :
    • Информатика
  • Информационное окно  :
    • Статьи по информатике без инфобоксов
  • Поддерживать  :
    • Хронология вычислительной техники 2020–2029 гг.
  • Фото  :
    • Найдите изображения для биографий компьютерных ученых (см. Список компьютерных ученых )
    • Компьютерные статьи, требующие изображений
  • Заглушки  :
    • Заготовки по информатике
  • Без ссылки  :
    • ВикиПроект Информатика / БП без ссылок
  • Связанные с проектом  :
    • Пометьте все соответствующие статьи в категории "Информатика" и подкатегориях с помощью {{ WikiProject Computer science }}
Чем вы можете помочь WikiProject Computer Security :
  • редактировать
  • история
  • смотреть
  • удалять
Вскоре AAlertBot будет генерировать оповещения о статьях . Пожалуйста, дайте несколько дней для обработки. Дополнительная информация...
  • Ответьте на вопрос о Same-origin_policy
  • Проверить важность и качество существующих статей
  • Определите категории, связанные с компьютерной безопасностью
  • Отметьте похожие статьи
  • Определите статьи для создания (см. Также: Запросы статей )
  • Определите статьи для улучшения
  • Создайте окно навигации по проекту, включая списки принятых статей, запрошенных статей, отрецензированных статей и т. Д.
  • Найдите редакторов, проявивших интерес к этой теме, и попросите их взглянуть здесь.

Архивы

  • Февраль 2004 г. - июль 2006 г. (Перенести другие разделы на эту страницу архива позже.)


Архивы [ править ]

Страница обсуждения становилась загроможденной, и я боялся, что некоторые важные комментарии останутся незамеченными. Создание: / Архив 1 Lunkwill 20:43, 7 октября 2006 г. (UTC)

Да, это начало загромождаться. Спасибо. Я добавил архивные коробки вверху страниц. - Дэвид Гётберг, 00:03, 8 октября 2006 г. (UTC)

Нужно ли хранить капельницу в секрете? [ редактировать ]

В этой статье прямо говорится, что нет необходимости хранить IV в секрете. Однако есть хорошо известный аргумент в пользу того, чтобы держать это в секрете. См .: http://www.ciphersbyritter.com/NEWS6/CBCIV.HTM для обсуждения этого. В книге «Основы сетевой безопасности», 2-е изд. Столлингса, на странице 45 также говорится, что IV следует хранить в секрете.

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

- Человек посередине (MITM) может, изменяя IV, изменять биты в первом блоке полученного открытого текста. MITM точно знает, какие биты полученного открытого текста будут изменены. Это нарушит целостность, но не сделает открытый текст доступным для MITM.

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

Я считаю, что заявление об отсутствии необходимости хранить IV в секрете следует удалить / изменить.

есть идеи?

  • Обсуждение, на которое вы ссылаетесь, включает нескольких хорошо известных и уважаемых исследователей, указывающих на то, что я также считаю лучшим ответом (который изложен в статье): CBC обеспечивает только строгую секретность, но не целостность. В очень-очень слабом смысле, вы можете вывести целостность в CBC, ища "искаженные" блоки сообщений. Это может означать, что произошло вмешательство, но в качестве тривиального примера, если я отправляю вам шифрование вывода из моего генератора случайных чисел (возможно, чтобы вы могли провести на нем какие-то статистические тесты), как вы собираетесь отличить «искаженный» случайные биты из "неразборчивых" битов? Поскольку MAC, напротив, обеспечивают очень сильную защиту целостности, зачем спорить о немного более слабой целостности и без того бесполезно слабой целостности, предлагаемой CBC? Просто используйте подходящий инструмент для работы. Что касается помощи криптоаналитикам, стандарт, который мы используем для безопасности, уже включает выбранные атаки с открытым текстом; если бы CBC не был безопасным для CPA, мы бы вообще не считали его безопасным. Это самое замечательное в сильной безопасности - мы гарантируем, что конструкции работают надежно при таких строгих ограничениях, что вам никогда не придется беспокоиться об обнаружении «искажений» или предотвращении выбора злоумышленниками открытых текстов. Lunkwill 02:22, 20 января 2005 г. (UTC)


Я думаю, что это смутно уместно здесь:
В Linux пользователи, которые использовали dm-crypt / cryptoloop в обычном режиме CBC, используют общедоступный IV. Это приводило к проблемам с атаками водяных знаков, чтобы обойти этот режим ESSIV, который сохраняет IV, используемые для секрета. См. Стр. 59 http://clemens.endorphin.org/nmihde/nmihde-A4-os.pdf, где упоминается ESSIV / CBC - «ГЛАВА 4. АТАКИ CBC»
Я думаю, что ваша атака "утечки контента" довольно хорошо известна (разве AC об этом не говорит?) И не вызывает особого беспокойства; Для 128-битного IV у вас есть около 2 ^ 64 ожидаемых блока до коллизии, как и в случае с MD5. Если 2 ^ 64 недостаточно, перейдите к AES-256 и получите безопасность 2 ^ 128. Но вы спрашивали не об этом; Что касается водяных знаков, похоже, что он работает только потому, что злоумышленник может изменить зашифрованный текст, и это предполагает, что люди ожидают целостности от режима секретности. IOW, вы должны использовать MAC. Но я полагаю, что эта атака имеет какое-то отношение к секретности; рассматривалась ли эта атака в литературе? Лунквилл 20:19, 12 августа 2005 г. (UTC)
Вы, ребята, похоже, говорите о той же недельности, которая обсуждается в вопросе ниже (Случайный IV в CBC). Я взял на себя смелость переместить этот вопрос прямо сюда. Кажется, ответ заключается в том, что IV не обязательно должен быть секретным, но для некоторых режимов IV должен быть непредсказуемым.. То есть злоумышленник не должен быть в состоянии предсказать, какой IV будет использоваться для шифрования будущих сообщений. См. Следующий раздел для получения более подробной информации об этом. (Ссылка «ESSIV», которую кто-то дал выше, актуальна в этом случае и также описывает это. Но обратите внимание, что эта проблема актуальна и для других систем, кроме шифрования диска.) Да, и обратите внимание, что MAC не решает этот IV проблема. Что решает это, так это использование CSPRNG с секретным семенем для создания IV. Или создайте CSPRNG с использованием самого блочного шифра следующим образом: если в качестве IV используется счетчик, просто зашифруйте IV с помощью блочного шифра (вы можете использовать тот же секретный ключ, что и ключ сообщения), чтобы создать непредсказуемый IV, который затем IV используется в блочном режиме. - Дэвид Гётберг, 14:09, 6 октября 2006 г. (UTC)
> - Человек посередине (MITM) может, изменяя IV, изменять биты в первом блоке полученного открытого текста.
> MITM точно знает, какие биты полученного открытого текста будут изменены. Это поставит под угрозу целостность,
> но не делать открытый текст доступным для MITM.
На практике это неверно. Нельзя использовать зашифрованный текст без гарантий подлинности. Период: Джеффри Уолтон, 19:18, 21 февраля 2012 г. (UTC)
> В очень-очень слабом смысле, вы можете вывести целостность в CBC, ища "искаженные" блоки сообщений.
Нет, это не так. «Распространенное заблуждение состоит в том, что шифрование обеспечивает аутентификацию источника данных и целостность данных, согласно аргументу, что если сообщение расшифровывается с помощью ключа, совместно используемого только со стороной A, и сообщение имеет смысл, то оно должно исходить от A.» - из Hanbook of Applied Cryptography, ISBN  0-8493-8253-7  Ошибка параметра в {{ ISBN }}: недействительный ISBN . , п. 364. Джеффри Уолтон 19:23, 21 февраля 2012 г. (UTC)

Случайный IV в CBC [ править ]

Мы действительно должны включить предупреждение о том, что в режиме CBC IV не должен быть предсказуем для злоумышленника, а должен генерироваться случайным образом после того, как известен открытый текст. Если это условие не выполняется, доказательства безопасности нарушаются, и происходит эффективная распознающая атака. - ciphergoth 10:27, 28 мая 2006 г. (UTC)

Не могли бы вы процитировать это, пожалуйста? Я не понимаю, почему (кто?) Знание открытого текста должно влиять на работу моего генератора случайных чисел. Лунквилл 18:44, 28 мая 2006 г. (UTC)
Ах, я понимаю, что означает шифергот. Мне кажется, проблема в том, что злоумышленник при некоторых обстоятельствах может проверить, правильно ли он догадался о содержании предыдущего сообщения. (Я предполагаю, что это и означает «отличительная атака».) То есть, если он может обмануть отправителя, чтобы зашифровать сообщения, разработанные злоумышленником, но отправитель по-прежнему использует тот же ключ и предсказуемый IV, такой как счетчик сообщений, используемый в качестве IV . Затем, если злоумышленник догадывается о предыдущем сообщении, он может создавать новые сообщения с тем же содержанием, но с измененным первым блоком, так что при xored с новым IV будет вызывать тот же ввод для первого шифрования. Если злоумышленник угадал правильно, то новый зашифрованный зашифрованный текст будет выглядеть точно так же, как зашифрованный текст старого сообщения. Если злоумышленник может составить несколько сообщений и заставить отправителя зашифровать их все, он может даже попробовать несколько разных догадок! И он может угадывать и проверять один блок сообщения за раз, таким образом постепенно угадывая все сообщение. Страшная штука.
Но если IV не счетчик, а случайное значение ( CSPRNGможет быть использован) и создан / опубликован отправителем ПОСЛЕ того, как сообщение для отправки выбрано / создано, злоумышленник не может правильно спроектировать первый блок и, следовательно, не может проводить такие тесты. О, похоже, есть простое решение. Если вы используете счетчик сообщений в качестве IV, просто зашифруйте IV, прежде чем использовать его для операции XOR для первого блока. Это то же самое, что и создание IV с CSPRNG. Обратите внимание, что IV не обязательно должен быть секретным, его можно отправлять в открытом виде. Пока и отправитель, и получатель "испортили" IV в достаточной степени, выполняя шифрование на нем, так что каждый новый IV становится непредсказуемым до того, как он будет использован для XORing. Также его можно отправить в зашифрованном виде. Не имеет значения, видит ли злоумышленник, что используется для XOR, если он не может предсказать, что будет использоваться для XOR в будущих сообщениях.
Это могло быть причиной того, что в некоторых старых книгах я видел, что IV зашифрован перед использованием в режиме CBC. Но в новых книгах, которые у меня есть, этого не делается. Кажется, с тех пор криптографы забыли об этой атаке?
В любом случае, это еще одна веская причина избегать использования режима CBC. Проще говоря, это означает, что режим CBC, представленный здесь и в современных книгах, небезопасен.
- Дэвид Гётберг, 05:25, 6 октября 2006 г. (UTC)
Криптографы не забыли об этих атаках. Скорее они нашли новые. То, что вы описываете, - это просто частный случай поблочной адаптивной атаки по выбранному открытому тексту. То есть злоумышленник может узнать зашифрованный текст блока i, а затем выбрать блок открытого текста i.+1. В этом случае возможна отличительная атака (как вы описали выше). Например, использование последнего блока зашифрованного пакета в качестве IV для шифрования следующего пакета - плохая идея. Таким образом, как вы описываете, IV просто должен быть непредсказуемым, но не обязательно секретным, и он не должен быть известен злоумышленнику, чтобы избежать выбранных атак с открытым текстом. Точно то же самое должно быть верно для каждого блока зашифрованного текста: злоумышленник не должен изучать его, прежде чем выбрать блоки открытого текста. Таким образом, с IV следует просто обращаться так же, как с любым блоком зашифрованного текста. CBC очень сложно использовать, и его никогда не следует использовать без MAC. Но это небезопасно. 67.84.116.166 15:33, 6 октября 2006 г. (UTC)
Так почему же небезопасно использовать зашифрованный CTR в качестве IV? Просто любопытно ... 83.64.176.129 19:19, 30 августа 2007 г. (UTC)
83.64.176.129: Вы нас неправильно поняли. И я, и 67.84.116.166 говорят, что использование зашифрованного счетчика в качестве IV безопасно. То есть счетчик должен быть зашифрован, чтобы сделать его случайным и непредсказуемым (для злоумышленника), прежде чем он будет использован для XOR с первым открытым текстом. Но, похоже, не имеет значения, передается ли он в открытом виде или в зашифрованном виде. - Дэвид Гётберг, 00:36, 31 августа 2007 г. (UTC)
Я понял, что есть аналогичная проблема с режимом CTR. Если, например, счетчик сообщений используется в качестве IV для режима CTR, и мы используем обычный подход, чтобы иметь IV, равный размеру блока блочного шифра, и мы просто добавляем внутренний счетчик режима (CTR) к IV, затем счетчик сообщений и CTR будет плохо взаимодействовать. Поэтому нам нужно, чтобы IV изменялся более непредсказуемым образом между каждым сообщением. То есть способом, который не взаимодействует с CTR. Решение похоже на то же, что и для проблемы IV в режиме CBC: либо используйте CSPRNG для создания IV, либо создайте своего рода CSPRNG, используя сам блочный шифр, позволяя ему зашифровать простой IV перед его фактическим использованием. (Вы можете использовать тот же ключ, что и для сообщения). Мне кажется, что для всех режимов IV должен быть зашифрован, чтобы «испортить» непредсказуемым образом перед первым использованием / комбинацией с любыми другими данными. Режимы CFB и OFB кажутся нормальными, как описано в этой статье, поскольку они делают именно это. Обратите внимание, что ни для одного из режимов IV не должен быть секретным, просто убедитесь, что он достаточно случайный / непредсказуемый. (Если вы беспокоитесь о секретности IV, тогда вы думаете об аутентификации сообщений, а не о секретности, и для этого вам следует использовать MAC-адреса.) -Дэвид Гётберг 14:27, 6 октября 2006 г. (UTC)

Схема декодирования CFB верна? [ редактировать ]

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

Вы правы. Фиксированный. Лунквилл 18:37, 30 мая 2005 г. (UTC)

Также мне кажется, что что-то еще не так. Из того, что я узнал, только старшие t битов вывода алгоритма шифрования используются в качестве входных данных для XOR. Это создает следующие t бит зашифрованного текста. Эти t бит зашифрованного текста затем используются в качестве младших битов ввода для следующего цикла алгоритма шифрования (при этом старшие биты просто сдвигаются на t бит влево). Типичные значения t - 1 и 8. Джипис 02:51, 6 октября 2006 г. (UTC)

Я согласен с Джиписом в том, что показатель CFB может быть улучшен. Я смотрю на цифру шифрования для CFB в Криптографии Столлингса и сетевой безопасности, 5-е изд. (Рисунок 6.5) и выглядит иначе, чем в Википедии. В книге ясно, что мы берем s бит из вывода блока шифрования и отбрасываем оставшиеся bs бит (где b - размер блока). В книге s бит шифротекста подаются в сдвиговый регистр. Джбарсело ( разговор ) 10:50, 25 октября 2010 (UTC)

В тексте описывается, как использовать метод, когда размер сегмента меньше размера блока. Однако это настолько важная часть этого режима, что следует включить рисунок, описывающий ее. Описание того, как сегментирование включено в алгоритм, можно найти в «Прикладной криптографии Шнайера» (2-е изд., Раздел 9.6), NIST SP800-38a (раздел 6.3) и в Руководстве по прикладной криптографии Манезеса и др. (Раздел 7.2.2 ( iii) и рис. 7.1 (c)). Lauri.pirttiaho ( разговор ) 07:21, 20 февраля 2011 (UTC)

Я разделил статью CFB и оставил изображение в разделе «Упрощенный CFB». Полное описание CFB для NIST CFB-1, CFB-8 и т. Д. Я оставил в другом разделе. Разделение довольно значительное, поскольку уязвимость IV = 0 атаки Zerologon не имела смысла при первоначальном описании и упрощенном изображении. Возможно, правильное изображение из NIST SP800-38A можно было бы нарисовать и вставить позже, чтобы облегчить понимание режимов CFB в будущем. Blaufish ( разговорное ) 13:35, 17 октября 2020 (UTC)

Может быть, какие-то внешние ссылки? [ редактировать ]

Кто-нибудь думает, что это стоит добавить в ссылки?

Рекомендации по режимам работы блочного шифра; Методы и методы http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf

Он немного более подробный, чем описания здесь (охватывает CBC, CFB, OFB, CTR, ECB), и многое прояснил для меня. Другие вещи, которые он охватывает:

- тестовые векторы для AES в 5 режимах- поколение IV- Распространение ошибки- Заполнение сообщения- Счетчики
Звучит как отличный справочник. Я пошел дальше и добавил его как внешнюю ссылку. Zetawoof ( ζ ) 22:21, 17 сентября 2006 г. (UTC)

Стоит отметить, что в первом абзаце статьи «История и стандартизация» говорится: «Существуют и другие режимы конфиденциальности, которые не были одобрены NIST. Например, CTS - это режим кражи зашифрованного текста, доступный во многих популярных криптографических библиотеках». но этот пример ошибочен. NIST опубликовал приложение к специальной публикации NIST 800-38A, октябрь 2010 г., в котором добавлены 3 варианта кражи зашифрованного текста для режима CBC, что делает эти варианты «одобренными» в смысле слова FIPS 140-2. Я предлагаю изменить текст и добавить этот документ в качестве внешней ссылки. - Предыдущий неподписанный комментарий добавлен 72.29.187.229 ( обсуждение ) 19:51, 9 мая 2017 г. (UTC)

OFB уязвим для атак с использованием известного открытого текста [ править ]

Стоит ли упоминать? Хотелось бы так думать.

83.147.140.156 ( разговорное ) 11:59, 27 февраля 2008 (UTC)

В разделе IV статьи уже отмечается, что повторное использование одного и того же IV делает OFB небезопасным. Если вам известна другая «атака с использованием известного открытого текста», дайте ссылку. 85.2.23.131 ( разговорное ) 21:04, 27 февраля 2008 (UTC)

CFB используется со сдвиговым регистром [ править ]

Я только что добавил раздел об использовании CFB со сдвиговым регистром. Если кто-то захочет добавить к этому диаграмму, это будет здорово. Существует пример одного здесь , но это не делает его очень ясно , когда регистр сдвига обновляется по сравнению с другими операциями. Wingedsubmariner ( разговор ) 20:23, 1 марта 2009 (UTC)

OFB может также относиться к Австрийской футбольной ассоциации? [ редактировать ]

«OFB» перенаправляется сюда. OFB может также относиться к Австрийской футбольной ассоциации.

ИМХО это неправильно. Австрийская футбольная ассоциация - это ÖFB или OEFB - у них есть лут на их веб-сайте http://www.oefb.at/ . С другой стороны, OEFB не перенаправляет на Австрийскую футбольную ассоциацию. —Предыдущий комментарий без знака добавлен 217.194.34.103 ( обсуждение ) 12:32, 24 ноября 2009 г. (UTC)

SVG графика [ править ]

Разве вся графика не должна быть svg? Я не очень хорошо умею делать svgs, но мы можем разместить шаблон, запрашивающий преобразование. Следует ли это делать? - Хрисмичели ( разговор ) 19:33, 20 февраля 2010 г. (UTC)

Почему? Они выглядят хорошо, и их так же легко редактировать, как PNG и SVG.
Перевод текста в PNG на другие языки (если вы хотите повторно использовать изображения, например, в испанской Википедии) так же просто, как перевод текста в SVG.
На самом деле, я думаю, что редактировать PNG проще, поскольку PNG не содержат всех ошибок рендеринга, которые все еще есть в SVG. SVG, которые мы создали несколько лет назад, плохо смотрятся здесь, в Википедии, поскольку Википедия изменила свой механизм рендеринга SVG. Хотя PNG-файлы, которые мы создали много лет назад, все еще выглядят нормально. А изображения, которые мы делаем с помощью современных инструментов SVG, часто плохо отображаются или вообще не отображаются в Википедии, поэтому нам постоянно приходится работать над ошибками. А SVG, созданные с помощью одного редактора SVG, иногда вообще не загружаются в другом редакторе SVG, поэтому мы даже не можем обновить некоторые изображения, созданные как SVG.
Использование растровых форматов, таких как PNG, проще и, вероятно, более перспективно для будущего. Скорее всего, изображения PNG можно будет рендерить и редактировать в будущем. Я думаю, что SVG следует использовать только там, где использование векторной графики явно является лучшим выбором. Для простых изображений здесь использование SVG просто не стоит проблем.
А люди, выполняющие преобразование PNG в SVG, часто не знают криптографии, поэтому, когда они переделывают изображения, они часто теряют или повреждают некоторые детали, которые важны для изображений. Я видел, как это происходило со многими нашими криптографическими изображениями. Поэтому, пожалуйста, не запрашивайте переделку этих изображений.
- Дэвид Гётберг ( разговор ) 22:05, 20 февраля 2010 г. (UTC)
Я уважаю ваше мнение. Использование SVG в Википедии не очень хорошее. Возможно, когда векторная графика получит лучшую поддержку в Википедии, мы сможем пересмотреть эту идею. - Хрисмичели ( разговор ) 06:21, 21 февраля 2010 г. (UTC)

Введение в статью [ править ]

Мне кажется, что введение в статью больше подходит для блочных шифров, а не для режимов работы блочного шифра. Я частично согласен с возвратом 85.1.208.213. Мне кажется, что первый абзац должен включать (1) определение «режима работы блочного шифра» (или, в более общем смысле, «режима работы»), и (2) список трех режимов: (а) конфиденциальность, (б) подлинность и (в) аутентифицированное шифрование. Я представляю себе нечто подобное: «В криптографии режим работы блочного шифра ... Есть три режима работы ...»

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

Может ли кто-нибудь с почерком прибить первый абзац?

Я не тот человек, которого можно звать для редактирования копий. Однако во время последней серии правок появилось несколько проблем. Вы указываете на одного из них. Как правило, ведущая часть на данный момент не очень удовлетворительна (стандартные тела лучше упоминать в основной части, примечание относительно использования примитива асимметричного шифрования больше сбивает с толку, чем поясняет, описания, касающиеся заполнения и введения размера блока и т. Д. ). В разделе «История» следует обсудить, что необходимость защиты целостности не была хорошо понятна в начале, и вместо этого были изучены свойства распространения ошибок в режимах. Примеры MAC не следует здесь обсуждать. Заполнение требуется для режимов, которые не превращают блочный шифр в потоковый шифр. Что касается аутентифицированного шифрования, AFAIK всезапатентованы однопроходные режимы. Фраза «к сожалению для криптографического сообщества» выбрана не очень удачно (даже если это правда). Объяснение однопроходной и двухпроходной обработки отсутствует. Не стесняйтесь решать эти проблемы. В противном случае я займусь этим, когда найду время. Нагех ( разговорное ) 20:37, 8 августа 2010 (UTC)
Часть первая сделана . Что касается MAC, то историческая ситуация гораздо сложнее, чем то, что наконец было осознано, что защита целостности была отдельной целью от шифрования (что произошло, скорее, в конце 80-х / начале 90-х годов). CBC-MAC был определен в начале 80-х годов. Основным драйвером для HMAC было то, что CBC-MAC были медленными, а специальные конструкции, основанные на хэш-функциях, были небезопасными. Поскольку HMAC не основан на блочном шифре и формально не является режимом работы (несмотря на сходство в конструкции хэш-функций), соответствующие параграфы в статье необходимо переписать.
Что касается аутентифицированного шифрования как реакции на людей, не понимающих, как их комбинировать, это также лишь одна сторона дела. Фактически, основной движущей силой множества новейших схем аутентифицированного шифрования была разработка эффективных схем с одним проходом.
Наге ( разговор ) 10:50, 18 сентября 2010 г. (UTC)

Предложение для первого абзаца [ править ]

Предложение по первому абзацу:

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

En.gravious ( разговор ) 16:43, 11 апреля 2013 (UTC)

Мне нужно простое и понятное введение.
Текущая версия и это предложение остаются слишком абстрактными и даже немного ошибочными. В режимах рассматривается не только шифрование, но и дешифрование. ECB - это режим, но он не обеспечивает такой же безопасности, как некоторые другие режимы. Не обозначайте весь класс преимуществами, которые существуют не для всех членов.
На моей странице обсуждения En.gravious заявила: «NIST определяет режим работы как алгоритм криптографического преобразования данных, в котором используется алгоритм блочного шифрования с симметричным ключом (NIST IR 7298 и NIST SP 800-38C)». Я не проверял источники, но это кажется лучшим объяснением, чем то, что есть у нас. Базовая конфиденциальность обеспечивается лежащим в основе блочным шифром.
Для меня режим работы - это просто описание того, как использовать блочный шифр для достижения более широкой цели (алгоритма). Допустим, у пользователя есть 8-байтовый блочный шифр, такой как DES (дросселирование). Должно быть какое-то соглашение о том, как использовать этот шифр для сообщений длиннее блока. Простой режим - это ECB, но у него есть некоторые проблемы (см. Penguin pix). Есть более сложные режимы, которые, как правило, решают некоторые проблемы. Они могут предложить большую безопасность, введя IV и / или цепочку. Некоторые режимы могут иметь другое назначение, например, вычисление дайджеста MAC.
Блочный шифр всегда поднимает проблему заполнения, но я не считаю это фундаментальной проблемой режима. Это скорее запоздалая мысль. Даже если бы кто-то передавал сообщение короче, чем блок, заполнение / засаливание было бы проблемой. Режиму работы это не свойственно.
Что важно сказать во введении?
Glrx ( разговор ) 18:45, 11 апреля 2013 (UTC)
Спасибо Grlx за ваши комментарии. Я попытался включить их и прокомментировать ниже:
Новое предложение для первого параграфа режимов работы блочного шифра :
В криптографии блочный шифр подходит только для безопасного криптографического преобразования (шифрования или дешифрования) одной группы бит фиксированной длины, называемой блоком. Для безопасного преобразования нескольких блоков было разработано множество режимов работы . Наиболее распространенными целями информационной безопасности при разработке этих режимов являются конфиденциальность и аутентичность .
Второй абзац первого предложения без изменений:
Режим работы описывает процесс шифрования данных в блоках и обычно использует рандомизацию на основе дополнительного входного значения, часто называемого вектором инициализации, чтобы сделать это безопасно. Обычно последняя часть данных, подлежащих шифрованию, меньше блока. Некоторые режимы работы требуют, чтобы последний блок был расширен для соответствия длине блока шифра с использованием подходящей схемы заполнения.
Преимущества / цели дизайна ЕЦБ:
«ECB Mode - это электронная кодовая книга. ECB изначально был определен NIST в FIPS 81. Стандарт, выпущенный в 1981 году, обеспечивает только конфиденциальность (Источник: http://www.cryptopp.com/wiki/ECB_Mode )».
«Один и тот же входной блок всегда производит один и тот же выходной блок под фиксированным бочонком в режиме ECB. Если это нежелательно в конкретном приложении, следует использовать режимы CBC, CFB или OFB. (Источник: FIPS 81)»
Даже если конфиденциальность нарушена, цель состоит в том, чтобы обеспечить конфиденциальность.
Набивка:
Режимы потокового шифрования, такие как OFB и CTR, не вызывают проблемы заполнения, заполнение характерно для блочных шифров и режимов работы, в которых используются блочные шифры.

En.gravious ( разговор ) 21:47, 11 апреля 2013 (UTC)

Я ударил молотком по первому абзацу. Он вдохновлен тем, что вы предложили, но не совсем так. Пожалуйста, измените его или скажите, что вы думаете. Скиппидо ( разговор ) 01:59, 12 апреля 2013 (UTC)
Я сохранил часть твоей работы. На ваше предложение: «Режим работы описывает процесс шифрования сообщений переменной длины с использованием блочного шифра при достижении различных целей по производительности, пропускной способности и безопасности». ссылаясь на «Справочник по прикладной криптографии» Менезеса, Оршота и др. В книге упоминаются на страницах 5, 227 и 228 различные критерии оценки для блочных шифров и режимы работы. Они упоминаются в блочном шифре под заголовком «Практическая оценка».

Однако в режимах блочного шифрования цели безопасности теперь упоминаются в первой строке статьи. Производительность больше относится к выбору между примитивами блочного шифра (AES, Serpent, Twofish и т. Д.), Чем к режиму работы, а пропускная способность больше применяется к режимам потокового шифрования IMHO. En.gravious ( разговор ) 14:11, 12 апреля 2013 (UTC)

Однобитовые ошибки и распространение ошибок. Противоречие в тексте? [ редактировать ]

В разделе, посвященном режиму обратной связи по шифрованию (CFB), говорится, что «если весь размер блока зашифрованного текста будет потерян, и CBC, и CFB будут синхронизироваться, но потеря только одного байта или бита навсегда прервет дешифрование ». Однако позже в том же разделе говорится, что «однобитное изменение зашифрованного текста влияет на два блока открытого текста: однобитное изменение в соответствующем блоке открытого текста и полное повреждение следующего блока открытого текста», но это " Последующие блоки открытого текста расшифровываются нормально . " Аналогичным образом, в разделе о цепочке блоков шифров (CBC) говорится, что «однобитное изменение зашифрованного текста вызывает полное повреждение соответствующего блока открытого текста и инвертирует соответствующий бит в следующем блоке открытого текста,. "

Как согласовать эти утверждения? Однобитовая или байтовая ошибка "не позволяет дешифровать" навсегда или только для пары блоков? - 66.50.16.13 ( разговорное ) 14:39, 21 марта 2014 г. (UTC)

В этих двух разделах говорится о двух разных видах однобитовых или однобайтовых повреждений зашифрованного текста, которые имеют два совершенно разных эффекта:

 зашифрованный текст: безошибочный оригинал cipertext: потерян один байт, а остальная часть сообщения переместилась зашифрованный текст: дублирован один байт, а остальная часть сообщения смещена cixhertext: один байт искажен, без смещения остальной части сообщения

Каждая программная ошибка переворота битов , включая замену одного символа другим символом, приводит к тому, что расшифрованный открытый текст имеет ошибку (и) в одном или двух блоках; но - с большинством режимов работы блочного шифра - остальная часть дешифрованного «открытого текста» идентична исходному открытому тексту.

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

Как мы могли бы улучшить эту статью, чтобы она не казалась противоречивой? - Дэвид Кэри ( разговор ) 16:48, 8 октября 2014 г. (UTC)

Надеюсь, решено; Я удалил части текста об обработке ошибок в CFB, которые не имели полного смысла и / или были чрезвычайно подробными / многословными. Я вставил текст SP800-38A о том, насколько хорошо самосинхронизируется CFB-1, и что другие режимы CFB, как ожидается, потребуют внешней синхронизации. Затем я вставил один из старых примеров, в котором CFB-XXX на самом деле будет самосинхронизироваться в особом случае (переворот одного бита), и пример, когда этого не произойдет (потеря одного бита при передаче). Blaufish ( разговорное ) 14:34, 17 октября 2020 (UTC)

Режимы OFB и CTR [ править ]

Что касается потокового характера режимов OFB и CTR, было бы хорошо указать явно, что открытый текст не обязательно должен состоять из полных блоков. Для частично заполненного окончательного блока открытого текста передаются только соответствующие символы зашифрованного текста (неполный блок зашифрованного текста); это все еще можно расшифровать.

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

Wstomv ( разговор ) 15:01, 30 мая 2014 (UTC)

Явный IV в CBC [ править ]

Было бы полезно добавить концепцию явных векторов инициализации. Это можно сделать либо в отдельном разделе, либо как часть режима CBC. В явном режиме IV к простому тексту добавляется блок случайных данных. Затем зашифрованный случайный блок заменяет IV, потому что первый блок всегда будет выброшен. Пример того, где это в настоящее время используется, можно найти на странице 6 «Проектирования и реализации дейтаграммного TLS» [1].

Я мог бы добавить это, но это первый раз, когда я редактирую какую-либо статью в Википедии, и я подумал, что страница обсуждения будет лучшим местом для начала. 216.45.141.162 ( разговорное ) 17:48, 2 января 2015 (UTC)

Рекомендации

  1. ^ Рескорла, Эрик. «Дизайн и реализация дейтаграммы TLS» (PDF) . crypto.stanford.edu . Дата обращения 2 января 2015 .

Неправильная формула OFB [ править ]

Когда j = 1, вы не используете I (0), вы используете I (1) и O (0). Следовательно, IV - это O (0), а не I (0). В качестве альтернативы вы можете сказать, что I (1) - это IV. - Предыдущий беззнаковый комментарий добавлен 68.11.83.88 ( обсуждение ) 02:06, 27 февраля 2015 г. (UTC)

^ O (0) не является IV, это результат Encrypt (IV), поэтому формула верна. Йоло МакСвагсон ( разговор ) 03:58, 1 мая 2015 (UTC)

а как насчет OpenSSL "Infinite Garble Extension"? [ редактировать ]

Он упоминается здесь и объясняется там, но я не нашел ничего об этом режиме в Википедии. Кто может захотеть добавить это сюда? - RokerHRO ( разговор ) 12:13, 27 апреля 2015 г. (UTC)

«Блокчейн» [ править ]

использование и основная тема цепочки блоков обсуждается, см. обсуждение: цепочка блоков (база данных транзакций) - 65.94.43.89 ( обсуждение ) 04:22, 29 мая 2015 г. (UTC)

«Блокчейн» [ править ]

Использование и основная тема Blockchain обсуждается, см. Обсуждение : Blockchain - 65.94.43.89 ( обсуждение ) 08:39, 29 мая 2015 г. (UTC)

Упомяните, что CBC и CTR «рекомендуются» [ править ]

Недавно я сделал небольшую правку, удалив фразу «Наряду с CBC, режим CTR является одним из двух режимов блочного шифрования, рекомендованных Нильсом Фергюсоном и Брюсом Шнайером». В моем редакционном сообщении говорилось:

давайте не будем предлагать обычному читателю, что прямое использование CBC или CTR вообще "рекомендуется"

Это было возвращено intgr, сказав:

не использовать ничего из этого "напрямую" "не рекомендуется" для случайного человека. Должны ли мы тогда очистить всю статью?

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

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

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

Dequis ( разговор ) 22:26, ​​10 октября 2015 (UTC)

@ Dequis : Почему утверждение, что одни режимы лучше других, бессмысленно или вредно? Я считаю , что существует широкий консенсус среди экспертов о том , что два рекомендуемых режимы являются лучше, по сравнению с другими , описанными в этой статье , - ЕЦБ, PCBC, CFB и OFB - которые полезны только в редких приложениях бахромы.
Вы говорите: « Возможно, это вырвано из контекста », но я так не думаю. Из самого источника :

Какой режим мне использовать?

Мы обсудили несколько режимов, но на самом деле мы бы рассмотрели только два режима: CBC и CTR. Мы уже объясняли, что ЕЦБ недостаточно безопасен. OFB - хороший режим, но CTR в некоторых отношениях лучше и не страдает проблемой короткого цикла. Нет причин выбирать OFB вместо CTR ".
Если вас не убедит только этот источник, я уверен, что можно найти больше.
Настоящая проблема в этой статье заключается в том, что в ней слишком много внимания уделяется классическим режимам без аутентификации, не признавая, что существует несколько приложений, для которых применимы разные виды режимов - режимы аутентифицированного шифрования и режимы шифрования диска . Но это отдельная тема. - intgr  [обсуждение] 21:47, 11 октября 2015 г. (UTC)

Включая другие редкие режимы шифрования [ править ]

Было бы неплохо добавить некоторые из других предложенных режимов шифрования в индекс этой статьи, и, возможно, они должны иметь свою собственную страницу или только одну страницу целиком. Ссылка: https://web.archive.org/web/20170904011624/http://csrc.nist.gov/groups/ST/toolkit/BCM/modes_development.html Список:

  • Состояние шифра https://web.archive.org/web/20170827215419/http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/proposedmodes/cs/cs-spec.pdf
  • EAX-Prime https://web.archive.org/web/20170215225642/http://csrc.nist.gov/groups/ST/toolkit//BCM/documents/proposedmodes/eax-prime/eax-prime-spec. pdf
  • IACBC https://web.archive.org/web/20170809010910/http://csrc.nist.gov/groups/ST/toolkit//BCM/documents/proposedmodes/iacbc/iacbc-spec.pdf
  • Входные выходные цепочки https://web.archive.org/web/20170201033009/http://csrc.nist.gov/groups/ST/toolkit/BCM//documents/proposedmodes/ioc/ioc-spec-2014.pdf
  • Распространение обратной связи с шифрованием https://web.archive.org/web/20170131091944/http://csrc.nist.gov/groups/ST/toolkit/BCM//documents/proposedmodes/pcfb/pcfb-spec.pdf
  • Случайная цепочка ключей https://web.archive.org/web/20170126135553/http://csrc.nist.gov/groups/ST/toolkit/BCM//documents/proposedmodes/rkc/rkc-spec.pdf
  • Синтетический IV https://web.archive.org/web/20170214234135/http://csrc.nist.gov/groups/ST/toolkit/BCM//documents/proposedmodes/siv/siv.pdf
  • расширенная цепочка блоков шифров https://web.archive.org/web/20170215074417/http://csrc.nist.gov/groups/ST/toolkit/BCM//documents/proposedmodes/xcbc/xcbc-spec.pdf

- Предшествующий беззнаковый комментарий, добавленный 202.40.137.199 ( обсуждение )

ЕЦБ / Требуется ссылка [ править ]

Чтобы объяснить, почему не следует использовать ECB:

  • https://www.notsosecure.com/hacking-crypto-fun-profit/ дает четкое объяснение
  • А Б. Шнайер, о Zoom, говорит: «Я не против AES-128, но использование режима ECB (электронная кодовая книга) указывает на то, что в компании нет никого, кто знает что-либо о криптографии [1] ».

Можно ли здесь использовать эти ссылки? Янико ( разговор )

  1. ^ https://www.schneier.com/blog/archives/2020/04/security_and_pr_1.html