Отправитель и получатель. Сообщения и шифрование 18 глава

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

8.6 Обновление ключей

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

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

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

8.7 Хранение ключей

Наименее сложными при хранении ключей являются проблемы одного пользователя, Алисы, шифрующей файлы для последующего использования. Так как она является единственным действующим пользователем системы, только она и отвечает за ключ. В некоторых системах используется простой подход: ключ хранится в голове Алисы и больше нигде. Это проблемы Алисы - помнить ключ и вводить его всякий раз, когда ей нужно зашифровать или расшифровать файл.

Примером такой системы является IPS [881]. Пользователи могут либо вводить 64-битовый ключ непосредственно, либо ввести ключ как более длинную символьную строку. В последнем случае система генерирует 64-битовый ключ по строке символов, используя технику перемалывания ключа.

Другим решением является хранить ключ в виде карточки с магнитной полоской, пластикового ключа с встроенной микросхемой ROM (называемого ROM-ключ) или интеллектуальной карточки [556, 557, 455]. Пользователь может ввести свой ключ в систему, вставив физический носитель в считывающее устройство, встроенное в его шифрователь или подключенное к компьютерному терминалу. Хотя пользователь может использовать ключ, он не знает его и не может его скомпрометировать. Он может использовать его только тем способом и только для тех целей, которые определены вектором контроля.

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

Эта техника становится более безопасной при разбиении ключа на две половины, одна из которых хранится в терминале, а вторая - в ROM‑ключе. Так работает безопасный телефон STU-III правительства США. Потеря ROM‑ключа не компрометирует криптографический ключ - замените этот ключ и все снова станет нормально. То же происходит и при потере терминала. Следовательно, компрометация ROM-ключа или системы не компрометирует криптографический ключ key - врагу нужно заполучить обе части.

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

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

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

8.8 Резервные ключи

Алиса работает главным финансистом в Secrets, Ltd. - "Наш девиз - Мы тебе не скажем." Как примерный служащий корпорации она в соответствии с инструкциями по безопасности шифрует все свои данные. К несчастью, она, проигнорировав инструкции по переходу улицы, попала под грузовик. Что делать президенту компании Бобу?

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

У Боба есть несколько способов избежать этого. Простейший иногда называют условным вручением ключей (см. раздел 4.14). Он требует, чтобы все сотрудники записали свои ключи на бумажках отдали их начальнику службы безопасности компании, который запрет их где-нибудь в сейф (или зашифрует их главным ключом). Теперь, чтобы не случилось с Алисой, Боб узнает ее ключ у начальника службы безопасности. Еще одну копию Боб также должен хранить в своем сейфе, в противном случае, если начальник службы безопасности попадет под другой грузовик, Бобу снова не повезет.

Проблема такой системы управления ключами в том, что Боб должен верить, что его начальник службы безопасности не воспользуется чужими ключами. Что еще серьезнее, все сотрудники должны верить, что начальник службы безопасности не воспользуется их ключами. Существенно лучшим решением является использование протокола совместного использования секрета (см. раздел 3.7).

Когда Алиса генерирует ключ, она одновременно делит ключ не несколько частей и затем посылает все части - зашифрованные, конечно - различным должностным лицам компании. Ни одна из этих частей сама по себе не является ключом, но все эти части можно собрать вместе и восстановить ключ. Теперь Алиса защищена от злоумышленников, а Боб - от потери всех данных Алисы после ее попадания под грузовик. Или, она может просто хранить разные части, зашифрованные открытыми ключами соответствующих должностных лиц компании, на своем жестком диске. Таким образом, никто не участвует в управлении ключами, пока это не станет необходимым.

Другая схема резервирования [188] использует для временного условного вручения ключей интеллектуальные карточки (см. раздел 24.13). Алиса может поместить ключ, которым закрыт ее жесткий диск, на интеллектуальную карточку и выдать ее Бобу, пока она в отъезде. Боб может использовать карточку для доступа к жесткому диску Алисы, но, так как ключ хранится на карточке, Боб не сможет его узнать. Кроме того, такая система контролируема с обеих сторон: Боб может проверить, что ключ открывает диск Алисы, а когда Алиса вернется, она сможет проверить, использовал ли Боб раз этот ключ, и если да, то сколько раз.

В подобной схеме не нужна передача данных. Для безопасного телефона ключ должен существовать только в течение разговора и не дольше. Для хранилищ данных, как было показано, условное вручение ключей может быть неплохой идеей. Я теряю ключи примерно раз в пять лет, а моя память получше, чем у многих. Если бы 200 миллионов человек пользовались криптографией, подобная частота привела бы к потере 40 миллионов ключей ежегодно. Я храню копии ключей от моего дома у соседа, потому что я могу потерять свои ключи. Если бы ключи от дома были подобны криптографическим ключам, то, потеряв их, я никогда не смог бы попасть внутрь и вступить в свои права владения. Также, как я храню где-то в другом месте копии своих данных, мне имеет смысл хранить и резервные копии моих ключей шифрования.

8.9 Скомпрометированные ключи

Все протоколы, методы и алгоритмы этой книги безопасны только, если ключ (закрытый ключ в системе с открытыми ключами) остается в тайне. Если ключ Алисы украден, потерян, напечатан в газете или скомпрометирован иным способом, то все ее безопасность исчезнет.

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

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

Хорошо, если Алиса знает, когда был скомпрометирован ее ключ. Если ключ распределяет KDC, то Алиса должна сообщить ему о компрометации своего ключа. Если KDC не используется, то ей следует известить всех корреспондентов, которые могут получать от нее сообщения. Кто-то должен опубликовать тот факт, что любое сообщение, полученное после потери ключа Алисой, является подозрительным, и что никто не должен посылать сообщения Алисе, используя соответствующий открытый ключ. Рекомендуется, чтобы программное обеспечение использовало какие-нибудь метки времени, тогда пользователи смогут определить, какие сообщения законны, а какие подозрительны.

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

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

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

8.10 Время жизни ключей

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

— Чем дольше используется ключ, тем больше вероятность его компрометации. Люди записывают ключи и теряют их. Происходят несчастные случаи. Если вы используете ключ в течение года, то вероятность его компрометации гораздо выше, чем если бы вы использовали его только один день.

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

— Чем дольше используется ключ, тем больше соблазн приложить необходимые усилия для его вскрытия - даже грубой силой. Вскрытие ключа, используемого в течение дня для связи между двумя воинскими подразделениями, позволит читать сообщения, которыми обмениваются подразделения, и создавать поддельные. Вскрытие ключа, используемого в течение года всей военной командной структурой, позволило бы взломщику в течение года читать все сообщения, циркулирующие в этой системе по всему миру, и подделывать их. В нашем мире закончившейся холодный войны какой ключ выбрали бы для вскрытия вы?

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

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

Для систем, использующих специализированные каналы связи, все не так очевидно. У ключей должно быть относительно короткое время жизни, в зависимости от значимости данных и количества данных, зашифрованных в течение заданного периода. Ключ для канала связи со скоростью передачи 1 Гигабит в секунду возможно придется менять гораздо чаще, чем для модемного канала 9600 бит/с. Если существует эффективный метод передачи новых ключей, сеансовые ключи должны меняться хотя бы ежедневно.

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

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

Время жизни закрытых ключей для приложений криптографии с открытыми ключами зависит от приложения. Закрытые ключи для цифровых подписей и идентификации могут использоваться годами (даже в течение человеческой жизни). Закрытые ключи для протоколов бросания монеты могут быть уничтожены сразу же после завершения протокола. Даже если считается, что время безопасности ключа примерно равно человеческой жизни, благоразумнее менять ключ каждую пару лет. Во многих четях закрытые ключи используются только два года, затем пользователь должен получить новый закрытый ключ. Старый ключ, тем не менее, должен храниться в секрете на случай, когда пользователю будет нужно подтвердить подпись, сделанную во время действия старого ключа. Но для подписания новых документов должен использоваться новый ключ. Такая схема позволит уменьшить количество документов, которое криптоаналитик сможет использовать для вскрытия.

8.11 Разрушение ключей

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

Ключи должны уничтожаться надежно (см. раздел 10.9). Если ключ записан на бумажке, бумажку нужно разрезать и сжечь. Пользуйтесь качественными уничтожителями бумаги, рынок заполнен дефектными устройствами. Алгоритмы, описанные в этой книге, надежно противостоят вскрытию грубой силой, стоящему миллионы долларов и требующему миллионов лет. Если враг сможет раскрыть ваш ключ, добыв плохо измельченные документы из вашего мусорника и наняв сотню безработных в какой-нибудь отсталой стране за 10 центов в час склеивать вместе кусочки разрезанных страниц, он выгодно вложит пару десятков тысяч долларов.

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

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

8.12 Управление открытыми ключами

Криптография с открытыми ключами упрощает управление ключами, но у нее есть свои собственные проблемы. У каждого абонента, независимо от числа людей в сети, есть только один открытый ключ. Если Алиса захочет отправить Бобу сообщение, ей придется где-то найти открытый ключ Боба. Она может действовать несколькими способами:

— Получить ключ от Боба.

— Получить его из централизованной базы данных.

— Получить его из своей личной базы данных.

В разделе 2.5 обсуждаются возможные способы вскрытия криптографии с открытыми ключами, основанных на подмене ключа Боба ключом Мэллори. Используется следующий сценарий: пусть Алиса хочет послать сообщение Бобу. Она обращается к базе данных открытых ключей и получает открытый ключ Боба. Но подлый Мэллори подменяет ключ Боба своим собственным. (Если Алиса запрашивает ключ непосредственно у Боба, Мэллори для успешной подмены придется перехватить ключ Боба при передаче.) Алиса шифрует сообщение ключом Мэллори и отправляет его Бобу. Мэллори перехватывает сообщение, расшифровывает и читает его. Затем шифрует открытым ключом Боба и отправляет по назначению. Ни Боб, ни Алиса ни о чем не догадываются.

Заверенные открытые ключи

Заверенным открытым ключом, или сертификатом, является чей-то открытый ключ, подписанный заслуживающим доверия лицом. Заверенные ключи используются, чтобы помешать попыткам подмены ключа [879]. Заверенный ключ Боба в базе данных открытых ключей состоит не только из открытого ключа Боба. Он содержит информацию о Бобе - его имя, адрес, и т.д. - и подписан кем-то, кому Алиса доверяет - Трентом (обычно известным как орган сертификации, certification authority,или CA). Подписав и ключ, и сведения о Бобе, Трент заверяет, что информация о Бобе правильна, и открытый ключ принадлежит ему. Алиса проверяет подпись Трента и затем использует открытый ключ, убедившись в том, что он принадлежит Бобу и никому другому. Заверенные ключи играют важную роль во многих протоколах с открытыми ключами, например, PEM [825] (см. раздел 24.10) и X.509 [304] (см. раздел 24.9).

В таких системах возникает сложная проблема, не имеющая прямого отношения к криптографии. Каков смысл процедуры заверения? Или, иначе говоря, кто для кого имеет полномочия выдавать сертификаты? Кто угодно может заверит своей подписью чей угодно открытый ключ, но должен же быть какой-то способ отфильтровать ненадежные сертификаты: например, открытые ключи сотрудников компании, заверенные CA другой компании. Обычно создается цепочка передачи доверия: один надежный орган заверяет открытые ключи доверенных агентов, те сертифицируют CA компании, а CA компании заверяют открытые ключи своих работников. Вот еще вопросы, над которыми стоит подумать:

— Какой уровень доверия к чьей-то личности обеспечивает сертификат?

— Каковы взаимоотношения между человеком и CA, заверяющим его открытый ключ, и как эти отношения отражаются в сертификате?

— Кому можно доверить быть "одним надежным органом", возглавляющим сертификационную цепочку?

— Насколько длинной может быть сертификационная цепочка?

В идеале прежде, чем CA подпишет сертификат Боба, Бобу нужно пройти определенную процедуру авторизации. Кроме того, для защиты от скомпрометированных ключей важно использовать какие-нибудь метки времени или признаки срока действия сертификата [461].

Использование меток времени недостаточно. Ключи могут стать неправильными задолго до истечения их срока либо из-за компрометации, либо по каким-то административным причинам. Следовательно, важно, чтобы CA хранил список неправильных заверенных ключей, а пользователи регулярно сверялись бы с этим списком. Эта проблема отмены ключей все еще трудна для решения.

К тому же, одной пары открытый ключ/закрытый ключ недостаточно. Конечно же, в любая хорошая реализация криптографии с открытыми ключами должна использовать разные ключи для шифрования и для цифровых подписей. Такое разделение разрешает различные Это разделение учитывает различные уровни защиты, сроки действия, процедуры резервирования, и так далее. Кто-то может подписывать сообщения 2048-битовым ключом, который хранится на интеллектуальной карточке и действует двадцать лет, а кто-то может использовать для шифрования 768-битовый ключ, который хранится в компьютере и действует шесть месяцев.

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

Распределенное управление ключами

В некоторых случаях такой способ централизованного управления ключами работать не будет. Возможно, не существует такого CA, которому доверяли бы Алиса и Боб. Возможно, Алиса и Боб доверяют только своим друзьям. Возможно, Алиса и Боб никому не доверяют.

Распределенное управление ключами, используемое в PGP (см. раздел 24.12), решает эту проблему с помощью поручителей. Поручители - это пользователи системы, которые подписывают открытые ключи своих друзей. Например, когда Боб создает свой открытый ключ, он передает копии ключа своим друзьям - Кэрол и Дэйву. Они знают Боба, поэтому каждый из них подписывает ключ Боба и выдает Бобу копию своей подписи. Теперь, когда Боб предъявляет свой ключ чужому человеку, Алисе, он предъявляет его вместе с подписями этих двух поручителей. Если Алиса также знает Кэрол и доверяет ей, у нее появляется причина поверить в правильность ключа Боба. Если Алиса знает Кэрол и Дэйва и хоть немного доверяет им, у нее также появляется причина поверить в правильность ключа Боба. Если она не знает ни Кэрол, ни Дэйва у нее нет причин доверять ключу Боба.

Спустя какое-то время Боб соберет подписи большего числа поручителей. Если Алиса и Боб вращаются в одних кругах, то с большой вероятностью Алиса будет знать одного из поручителей Боба. Для предотвращения подмены Мэллори одного ключа другим поручитель должен быть уверен, прежде чем подписывать ключ, что этот ключ принадлежит именно Бобу. Может быть, поручитель потребует передачи ключа при личной встрече или по телефону.

Выгода этого механизма - в отсутствии CA, которому каждый должен доверять. А отрицательной стороной является отсутствие гарантий того, что Алиса, получившая открытый ключ Боба, знает кого-то из поручителей, и, следовательно, нет гарантий, что она поверит в правильность ключа.

9 Типы алгоритмов и криптографические режимы

Существует два основных типа симметричных алгоритмов: блочные шифры и потоковые шифры. Блочные шифрыработают с блоками открытого текста и шифротекста - обычно длиной 64 бита, но иногда длиннее. Потоковые шифрыработают с битовыми или байтовыми потоками открытого текста и шифротекста (иногда даже с потоками 32-битных слов). Блочный шифр, использующий один и тот же ключ, при шифровании всегда превращает один и тот же блок открытого текста в один и тот же блок шифротекста. Потоковый шифр при каждом шифровании превращает один и тот же бит или байт открытого текста в различные биты или байты шифротекста.

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

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

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

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

9.1 Режим электронной шифровальной книги

Режим электронной шифровальной книги (electronic codebook,ECB) - это наиболее очевидный способ использовать блочный шифр: блок открытого текста заменяется блоком шифротекста. Так как один и тот же блок открытого текста заменяется одним и тем же блоком шифротекста, то теоретически возможно создать шифровальную книгу блоков открытого текста и соответствующих шифротекстов. Однако, если размер блока - 64 бита, то кодовая книга будет состоять из 2⁶⁴ записей - слишком много для предварительного вычисления и хранения. И не забывайте, для каждого ключа понадобится отдельная шифровальная книга.

Это самый легкий режим работы. Все блоки открытого текста шифруются независимо. Нет необходимости в последовательном шифровании файла, можно зашифровать сначала 10 блоков из середины текста, затем последние блоки, и наконец, первые. Это важно для шифрованных файлов с произвольным доступом, например, для баз данных. Если база данных зашифрована в режиме ECB, то любая запись может быть добавлена, удалена , зашифрована или расшифрована независимо от любой другой записи ( при условии, что каждая запись состоит из целого числа блоков шифрования). Кроме того, обработка может быть распараллелена, если используются несколько шифровальных процессоров, они могут независимо друг от друга шифровать или дешифрировать различные блоки.

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

Если криптоаналитик знает, что блок открытого текста "5e081bc5" при шифровании превращается в блок шифротекста "7ea593a4," то он может мгновенно расшифровать этот блок шифротекста, в каком-бы другом сообщении он не появился. Если в шифрованном сообщении много повторов, которые имеют тенденцию занимать одинаковое место в различных сообщениях, криптоаналитик может получить много информации. Он может попытаться статистически вскрыть используемый открытый текст, независимо от силы блочного шифра.

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

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

Набивка

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

Последний блок дополняется (набивается) некоторым регулярным шаблоном - нулями, единицами, чередующимися нулями и единицами - для получения полного блока. При необходимости удалить набивку после дешифрирования запишите количество байтов набивки в последний байт последнего блока. Например, пусть размер блока - 64 бита, и последний блок состоит из 3 байтов (24 бит). Для дополнения блока до 64 бит требуется пять байтов, добавьте четыре байта нулей и последний байт с числом 5. После дешифрирования удалите последние 5 байтов последнего расшифрованного блока. Чтобы этот метод работал правильно, каждое сообщение должно быть дополнено. Даже если открытый текст содержит целое число блоков, вам придется добавить один полный блок. С другой стороны, можно использовать символ конца файла для обозначения последнего байта открытого текста и дополнить этот символ er.