каталоге. Эти скомбинированные возможности помогут предотвратить
дальнейшее распространение недействительного ключа.
Если указанный открытый ключ уже помечен как недействительный,
команда -kd выдаст запрос о необходимости восстановления ключа.
Дополнительные разделы
======================
Большая часть "Дополнительных разделов" находится в
"Руководстве пользователя PGP, часть II: Специальные разделы". Но
несколько разделов упомянуто в данной части документации.
Посылка зашифрованного текста через каналы электронной почты:
формат Radix-64
----------------------------------------------------------------
Многие системы электронной почты поддерживают только сообщения
в виде ASCII-текста, а не в виде двоичных 8-битных данных, из
которых состоят зашифрованные тексты. Чтобы обойти эту проблему,
PGP позволяет получить формат ASCII Radix-64, подобный формату
Internet Privacy-Enhanced Mail (PEM). Этот специальный формат
представляет двоичные данные, используя только печатаемые символы
ASCII, это полезно для передачи двоичных зашифрованных данных
через 7-битовые каналы или для посылки двоичных зашифрованных
данных как обычный текст электронной почты. Этот формат действует
как "транспортная оболочка", защищая данные от повреждения при
передаче их через межсистемные межсетевые шлюзы в Internet. Он
также включает в себя CRC-код для определения ошибок при
передаче.
Формат Radix-64 преобразует обычный текст при помощи
расширения групп из 3-х двоичных 8-битовых байтов в 4 печатаемых
символа ASCII, так что файл увеличивается приблизительно на 33%.
Но это увеличение не так уж плохо, если вы учтете, что файл,
вероятно, был сжат на большую величину перед кодированием его с
помощью PGP.
Для получения зашифрованного файла в формате Radix-64 просто
добавьте опцию "a" при шифровании или подписании сообщения,
например, так:
pgp -esa message.txt her_userid
В результате будет получен шифрованный файл с именем
"message.asc", который содержит данные в PEM-подобном формате
Radix-64. Этот файл может быть легко загружен в текстовый
редактор через 7-битовые каналы для передачи как нормальная
электронная почта в Internet или другой сети.
Дешифровка сообщения в такой транспортной оболочке ничем не
отличается от обычного. Напрмер:
pgp message
PGP будет автоматически искать ASCII-файл "message.asc"
прежде, чем двоичный файл "message.pgp". Она распознает, что файл
находится в формате Radix-64 и преобразует его обратно в двоичный
перед обычной обработкой, создавая, как побочный продукт,
шифрованный файл ".pgp" в двоичной форме. Окончательный выходной
файл будет иметь вид обычного текста, как это было в
первоначальном файле "message.txt".
Большинство средств электронной почты Internet запрещают
пересылку сообщений, размер которых больше 50000 байт. Более
длинные сообщения должны быть разделены на более маленькие,
которые пересылаются отдельно. Если ваше зашифрованное сообщение
весьма велико, и вы дали команду преобразования в Radix-формат,
то PGP автоматически разделит его на отдельные части, каждая из
которых является достаточно малой для посылки через систему
электронной почты. Эти части будут помещаться в файлы с
расширениями имен ".asc", ".as2", ".as3", и т.д. Получатель
должен соединить эти отдельные файлы снова вместе в один большой
файл перед тем, как приступать к дешифровке. При дешифровке PGP
будет игнорировать любой посторонний текст в заголовках
сообщений, который не включен в блоки Radix-64.
Если вы хотите послать открытый ключ кому-либо в формате
Radix-64, вам только надо добавить опцию "-a" при извлечении
ключа из вашего каталога ключей.
Если вы забыли использовать опцию "-a" при создании
зашифрованного файла или извлечении ключа, вы просто можете
преобразовать двоичный файл в формат radix-64, используя одну
опцию "-a", без задания любого шифрования. PGP преобразует его в
файл ".asc".
Если вы хотите послать по каналам электронной почты обычный
текстовый файл, который подписан, но не зашифрован, PGP просто
конвертирует его в формат radix-64, делая его нечитабельным для
обычного наблюдателя. Если исходный файл является просто текстом
(не двоичным файлом), то существует способ, с помощью которого
можно оставить сам текст в его исходном виде, преобразовав в
ASCII-оболочку только электронную подпись. Это делает возможным
для получателя прочитать текст сообщения просто глазами, без
применения PGP. Естественно, PGP остается необходимой для
проверки подписи. Для получения дополнительной информации об этой
возможности смотрите описание параметра CLEARSIG в разделе
"Установка параметров конфигурации: CONFIG.TXT" в части
"Специальные Разделы".
Системная переменная для задания имени пути
-------------------------------------------
PGP использует несколько специальных файлов для своих целей,
таких, как ваши стандартные каталоги ключей "pubring.pgp" и
"secring.pgp", файл начального числа для генерации случайных
чисел "randseed.bin", файл конфигурации PGP "config.txt" и файл
перевода сообщений на другие языки "language.txt". Эти
специальные файлы могут храниться в любом каталоге, только
требуется занести в системную переменную "PGPPATH" требуемый
каталог. Например, для MSDOS, это будет выглядеть так:
SET PGPPATH=C:\PGP
В результате PGP будет знать, что полное имя файла вашего
каталога открытых ключей будет иметь вид "C:\PGP\pubring.pgp".
Естественно, если этот каталог существует. Используйте ваш
любимый текстовый редактор чтобы изменить ваш файл AUTOEXEC.BAT в
MSDOS для автоматической установки этой переменной при начальной
загрузке системы. Если PGPPATH остается неопределенным,
считается, что эти специальные файлы находятся в текущем
каталоге.
Установка параметров конфигурации: файл CONFIG.TXT
--------------------------------------------------
PGP имеет ряд параметров, устанавливаемых пользователем,
которые могут быть определены в специальном текстовом файле
конфигурации с именем "config.txt", в каталоге, на который
указывает системная переменная PGPPATH. Наличие файла
конфигурации дает возможность пользователю определять в нем
различные флажки и параметры для PGP, исключая необходимость
каждый раз определять эти параметры в командной строке.
С помощью этих параметров конфигурации, например, вы можете
определить, где PGP сохраняет временные рабочие файлы, или вы
можете выбирать иностранный язык, который PGP будет использовать
для отображения диагностических сообщений и подсказок
пользователю, либо можете регулировать уровень скептицизма PGP
при определении истинности ключей, который основывается на числе
удостоверяющих подписей.
Для получения более подробной информации об этих параметрах
конфигурации, см. см. соответствующий раздел руководства
пользователя PGP, часть II.
Уязвимость
----------
Никакая система защиты данных не является несокрушимой. PGP
может быть обойдена целым рядом способов. Это может быть
компроментация вашего секретного ключа и фразы пароля, подделка
общего ключа, файлы, которые вы удалили, но они остались
физически на диске, вирусы и троянские кони, бреши в вашей
физической защите, электромагнитная эмиссия, дефект в
многопользовательских системах, анализ траффика, и, возможно,
даже прямой криптоанализ.
Для более детального обсуждения этих проблем см. раздел
"Уязвимость" в руководстве пользователя PGP, часть II.
Доверие к змеиному маслу
========================
При исследовании пакета криптографического программного
обеспечения всегда остается вопрос: почему вы должны доверять
этой программе? Даже если вы самостоятельно исследовали исходный
текст, но ведь не каждый имеет опыт в криптографии, чтобы судить
о степени защиты. Даже если вы опытный шифровальщик, вы можете
пропустить небольшие слабости в алгоритмах.
Когда я учился в колледже в начале семидесятых, я верил, что
изобрел прекрасную схему шифрования. Простой псевдослучайный
поток чисел добавлялся к потоку текста, чтобы создть
зашифрованный текст. В результате, по-видимому, частотный анализ
зашифрованного текста станет невозможным, и такой текст будет
недоступен для расшифровки даже наиболее мощным правительственным
службам. Я был настолько уверен в этом достижении. Излишне
самоуверен.
Спустя несколько лет я обнаружил эту самую схему в нескольких
статьях и учебниках по криптографии. Другой специалист размышлял
о той же самой схеме. К сожалению, она была представлена как одна
из простейших в качестве примера об использовании элементарной
криптографической технологии для ее вскрытия. Столь много для
моей прекрасной схемы.
Из этого скромного опыта я понял, как легко ошибиться в оценке
качества защиты при изобретении алгоритма шифрования. Большинство
людей не понимают, как дьявольски трудно изобрести алгоритм
шифрования, который мог бы долго противостоять и отражать атаки
сильного противника. Множество инженеров-программистов
разработали одинаково наивные схемы шифрования (часто
одинаковые), и некоторые из них были включены в коммерческие
криптографические программные пакеты и продавались за хорошие
деньги тысячам доверчивых пользователей.
Это похоже на продажу самофиксирующихся ремней безопасности,
которые смотрятся хорошо и удобны, но фиксируются в открытом
состоянии даже при самой медленной проверке. Зависимость от таких
ремней может быть хуже, чем даже не использовать ремни совсем.
Никто не предполагает, что они они действительно плохи вплоть до
настоящей аварии. Зависимость от слабого криптографического
программного обеспечения может привести к необходимости
размещения секретной информации с долей риска. Ведь вы не смогли
бы иначе выполнить это, если бы у вас не было никакого
криптографического программного обеспечения вообще. Возможно, вы
даже никогда и не обнаружите, что ваши данные были
скомпрометированы.
Иногда коммерческие пакеты используют Федеральный Стандарт
Шифрования Данных (DES), хороший стандартный алгоритм
рекомендуемый правительством для коммерческого применения (но не
для секретной информации, что в значительной степени странно -
хм... ). Существует несколько "режимов операции", которые DES
может использовать, некоторые из них лучше, другие хуже.
Правительство специально не рекомендует использовать самый слабый
и простейший режим для сообщений, режим Electronic Codebook
(ECB). Оно рекомендуют более сильные и более сложные режимы
Cipher Feedback (CFB) или Cipher Block Chaining (CBC).
К сожалению, большинство рассмотренных мною коммерческих
пакетов для шифрования применяют режим ECB. Когда я разговаривал
с авторами ряда подобных систем, они говорили мне, что никогда не
слышали о режимах CBC и CFB, и ничего не знали о слабостях режима
ECB. Тот факт, что они даже не изучили криптографию в объеме,
достаточном для знания элементарных принципов, не убеждает. Те же
самые программные пакеты часто включают в себя второй более
быстрый алгоритм шифрования который может использоваться вместо
медленного DES. Автор такого пакета нередко полагает, что его
собственный более быстрый алгоритм является столь же надежным,
как и DES, но после подробных расспросов я обычно выясняю, что
это просто-напросто разновидность моей знаменитой схемы времен
