Иногда получатель хочет проверить, является ли его конкретный ключ правильным ключом симметричного дешифрирования. Если открытый текст сообщения представляет собой что-то похожее на ASCII, он может попытаться расшифровать и прочитать сообщение. Если открытый текст случаен , то существуют другие приемы.
Наивным подходом явилось бы присоединение к открытому тексту до шифрования проверочного блока-известного заголовка. Получатель Боб расшифровывает заголовок и проверяет, что он правилен . Это работает, но дает Еве известный кусочек открытого текста, что помогает ей криптоанализировать систему . Это также об-
легчает вскрытие шифров с коротким ключом, таких как DES и все экспортируемые шифры. Рассчитайте заранее один раз для каждого ключа проверочную сумму, затем используйте эту проверочную сумму для определ е-ния ключа в любом сообщении, которое вы перехватили после этого . Любая проверочная сумма ключа, в которую не включены случайные или, по крайней мере, различные данные, обладает этим свойством . По идее это очень похоже на генерацию ключей по ключевым фразам.
Вот для этого способ получше [821]:
(1) Сгенерите вектор идентификации (отличный от используемого в сообщении).
(2) Используйте этот вектор идентификации для генерации большого блока битов: скажем, 512.
(3) Хэшируйте результат.
(4) Используйте те же фиксированные биты хэш-значения, скажем, 32, для контрольной суммы ключа .
Это тоже дает Еве какую-то информацию, но очень небольшую . Если она попытается использовать младшие 32 бита конечного хэш-значения для вскрытия грубой силой, ей придется для каждого вероятного ключа выпо л-нить несколько шифрований и хэширование, вскрытие грубой силой самого ключа окажется быстрее .
Она не получит для проверки никаких известных кусочков открытого текста, и даже если она сумеет подбр о-сить нам наше же случайное значение, она никогда не получит от нас выбранный открытый текст, так как он будет преобразован хэш-функцией прежде, чем она его увидит.
8.5 Использование ключей
Программное шифрование рискованно. Ушли те дни, когда простые микрокомпьютеры работали под управлением единственной программы. Сегодня время Macintosh System 7, Windows NT и UNIX. Невозможно сказать, когда операционная система остановит работающую программу шифрования , запишет все на диск и разрешит выполняться какой-то другой задаче. Когда операционная система, наконец, вернется к шифрованию, чтобы там не шифровалось, картинка может оказаться весьма забавной. Операционная система записала пр о-грамму шифрования на диск, и ключ записан вместе с ней. Ключ, незашифрованный, будет лежать на диске, пока компьютер не напишет что-нибудь в эту же область памяти поверх . Это может случиться через несколько минут, а может через несколько месяцев. Этого может и никогда не случиться, но ключ все же может оказаться на диске в тот момент, когда жесткий диск густо прочесывается вашим противником . В приоритетной, многозадачной среде, для шифрования можно установить достаточно высокий приоритет, чтобы эта операция не пр е-рывалась. Это снизило бы риск. Даже при этом система в целом в лучшем случае ненадежна.
Аппаратные реализации безопаснее. Многие из устройств шифрования разработаны так, чтобы любое вм е-шательство приводило бы к уничтожению ключа. Например, в плате шифрования для IBM PS/2 залитый эпо к-сидной смолой модуль содержит микросхему DES, батарею и память. Конечно, Вы должны верить, что прои з-водитель аппаратуры правильно реализовал все необходимые свойства.
Ряд коммуникационных приложений, например, телефонные шифраторы, могут использовать сеансовые ключи.Сеансовым называется ключ, который используется только для одного сеанса связи - единственного телефонного разговора - и затем уничтожается. Нет смысла хранить ключ после того, как он был использован . И если вы используете для передачи ключа от одного абонента другому некоторый протокол обмена ключами , то этот ключ не нужно хранить и перед его использованием . Это значительно снижает вероятность компрометации ключа.