Это - копия документа, находившегося на http://dz.ru. Авторские права, если не указано иначе, принадлежат Дмитрию Завалишину и/или Евгении Завалишиной. Все изменения, внесенные мной, находятся в этой рамочке.Пожалуйста, прочитайте disclaimer. |
Прродолжаем разговор о PGP.
В настоящее время довольно остро строит вопрос о том, какой версией пользоваться. Можно выбирать из 2.6, 5.5 и 6.0. И выбор - не из легких. :-( Дело в том, что 2.6 и более ранние поддерживали только ключи в фромате RSA. Версия 5.5 - последняя из тех, что эти ключи поддерживает, а 6.0 уже работает только с алгоритмом и ключами DSS/Diffie-Hellman. То есть международная версия будет поддерживать RSA, но, по всей видимости, не американская.
То есть идеальной версии, которая позволяла бы сегодня общаться со всеми, видимо, нет. Одно из лучших решений геморройно - поставить версию 5.0-5.5 и сделать себе ключи в обоих форматах. С теми, кто поддерживает новый формат общаться в нем, с остальными - в RSA. Если я найду свой старый RSA-шный секретный ключ - так и сделаю. :-) А пока - опробую технологии на ключах типа DSS/Diffie-Hellman.
Более простое решение - пользоваться PGP 5.5.3, но ключом RSA: в этом случае несовместимость будет только с PGP 6.0 американского разлива, а им еще мало кто пользуется.
В принципе, есть вероятность, что со временем PGP 2.6 изживется со свету и пользоваться RSA-ключами станет не нужно. Принципиально этому ничто кроме лени не мешает, но поддержка Юникса у PGP-шников не очень хороша, а 2.6 - хорошо вылизанная софтина, и Юниксоиды слезть с нее не спешат. Тормозят прогресс человечества, одним словом. ;-)
| |
|
Интересна также и новая концепция мета-представителей (от слова "представлять" в смысле "знакомить"), так, наверное, это будет по-русски. Идея в том, что подпись ключа теперь может снабжаться также флагами "meta-introducer" и "trusted introducer" (доверенный представитель... или доверенный сводник?:). Если я подписываю чей-либо ключ как ключ мета-представителя, то это повышает мою степень доверия к нему на новый уровень. Теперь, если хозяин этого ключа подпишет чей-либо ключ с флагом доверенного представителя (trusted introducer), то моим PGP этот третий человек будет восприниматься как доверенное лицо, и все, что он подпишет, будет считаться заверенным как если бы я лично поставил ему уровень доверия "trusted".
Я не проверил еще этот механизм на практике, но очевидно, что подписывать чей-то ключ с флагом "meta-introducer" нужно, только если ты доверяешь этому человеку весьма и весьма.
Понятно, откуда возникла концепция мета-представителей. Без них ты вынужден либо лично убеждаться в достоверности используемых ключей и подписывать их сам, либо искать кого-либо, кому ты доверяешь, и кто подписал нужный тебе ключ. Внесение в этот механизм лишнего уровня косвенности позволяет еще на единичку увеличить диаметр множества ключей, которыми ты можешь пользоваться не задумываясь, а это, в свою очередь, резко увеличивает их абсолютное число. Как говорится, "через третьи руки я наверняка знаком с президентом".
| |
|
У одного из лучших, по моему мнению, авторов современной Компьютерры, Максима Отставнова, есть сайт, посвященный PGP. Его можно рекомендовать тем, кто не в ладах с английским и потому не может пользоваться оригинальными материалами на сайте разработчиков.
| |
|
Кстати о Компьютерре. В последних двух номерах не указан тираж. А это может означать только то, что он упал недопустимо сильно. Настолько, что лучше рисковать нарушением закона и не говорить. Если учесть, что Компьютерра давно снимает сливки на рынке рекламы в этом секторе печатной продукции, то симптом плохой. :-(
| |
|
Один из читателей упрекнул меня - мол, приглашение подписывать мой ключ нарушает постулаты PGP, потому как вдруг это не я, а злой враг притаился на моем сайте, взломав его, пока я сплю, и подложил ключик, чтобы вы все его подписывали, а он потом от моего имени шифрованную почту посылал и получал.
Я рад, что получил это письмо, ибо навело на интересные рассуждения, и, надеюсь, это не пройдет даром. Итак, начинаем рассуждать. :-)
Фактически, автор письма прав - действительно гад мог бы прорваться на сайт, взломав его, и выступить от моего имени, подложив для вашей подписи левый ключ. Давайте на секунду представим, что www.dz.ru лежит не на легендарной паранойе Сергея Трофимовского, которую нельзя взломать и танком, потому что сисадминистее Трофимовского нет на свете сисадминов, а на каком-либо обычном легко ломаемом сайте.
Что из того следует? Что если на сайте лежит предложение подписывать ключ и присылать подпись владельцу, то нужно убедиться в любом из двух моментов:
- Что выложенный ключ - действительно мой.
- Что подписанный результат попадет действительно ко мне.
Любого условия достаточно, чтобы подписывать с чистой душой. Потому как если злой человек подложил мне ключик на сайт, но подписи получу я, а не он, то толку с его махинаций - ноль. Мало того, взломщик должен не просто снимать копии с моей почты, а сделать так, чтобы именно это письмо не попало ко мне - иначе я подниму тревогу.
Как можно убедиться с существенной вероятностью, что выложенный на WWW ключ - мой? Да просто подождав пару дней. Если я не заорал "измена", не написал о взломе сайта, не убрал ключа - все нормально. Я ведь тоже читаю свой сайт для проверки и регулярно захожу на несколько номеров назад. Еще одним фактором служит то, что выложенный ключ уже имел несколько подписей.
Что же касается перехвата моей почты, то мой почтовый ящик лежит не у провайдера на машине, а у меня, и приходит почта сюда прямо по SMTP, так что перехватить ее - не детская забава.
| |
|
Бродил я вчера по сети. Использовал для
этого 4.5-й Netscape, и, как это с нетскейпами у меня
нередко случается, он упал. :-( Но... не успел еще
труп нетскейпа долететь до земли, как откуда-то
из глубин моей машины вынырнул визард и
осторожно спросил - а можно ли он, визард, отошлет
от моего имени баг-репорт в нетскейп? Он,
честно-честно, ничего про меня Нетскейпу не
скажет, а только сообщит, в каком состоянии был
броузер и обо что он спотыкнулся. Я (см. справа)
разрешил. Ничего страшного (как, впрочем, и
полезного) с тех пор не случилось, но теперь меня
гложут вопросы - сколько они получают
багрепортов таким образом, нельзя ли на эту тему
сказать что-либо параноидальное :-) и значит ли
это, что теперь 4.5 будет вычищен до блеска и
никогда-никогда не будет падать? :-)
Более того. Говоря глобально, не принес ли Интернет новую эру в софтостроении? Ведь резонно - научить софтину отправлять багрепорты саму, причем багрепорты куда более детальные. По сути, уже знание адреса останова и номера ошибки/exception-а позволяет если не найти ошибку во всей ее полноте, то хоть сделать так, чтобы она не приводила к фатальным последствиям. Более того, можно вновь вернуть к жизни институт assert-ов, проверок в коде, которые сделаны исключительно для того, чтобы уронить программу, если не выполняется некоторое жизненно важное условие. В настоящее время многие предпочитают отключать их в окончательных релизах с тем, чтобы не пугать пользователя и в надежде, по сути, на авось. Тогда как при четко налаженном механизме сообщений автору об ошибках в программе имеет смысл не уменьшать, а увеличивать число точек, в которых программа может упасть - это приведет к тому, что она быстрее и более полно будет исправлена.
По моему - так. (С) Винни-Пух. :-)
| |
|
Продолжение о новой версии OS/2 - Aurora. Сравнительное тестирование быстродействия и надежности новой файловой системы, JFS, которую, напомню, IBM перетащил в OS/2 из своего Юникса по имени AIX.
 |
Привет Дима. Довелось мне слегка пощупать Аврору. Сразу скажу, что впечатления двоякие. С одной стороны, это обычный Мерлин с дополнительными сетизмами, но пока не ясно насколь они работоспособны, да и не было времени вплотную ими заняться, поэтому я занялся тестированием новой файловой системы, JFS.
Система:
Надо отметить что JFS расположена у меня достаточно нетривиально: На HDD0 в начале диска 500Mb, в конце диска еще 30Mb + на HDD2 раздел размером в 1,2Gb, соответвенно получаем суммарный объем около 1,7Gb. Для тестирования устойчивости применялся следующий метод: Запуск достаточно большого количества сессий с записью, чтением, удалением файлов (в качестве файлов применялись архивы - чтобы можно было оценить их целостность), затем, когда диск был практически полон (свободное место около 3 мегабайт) нажималась кнопка Reset. Проход ChkDsk по разделу с JFS составлял чуть более 2 секунд !. Потерь файлов не наблюдалось ни в одном случае, всего таких нештатных перезагрузок было около 20. Затем я перешел к тестированию JFS на скорость. Для этого я применил следующую программу:
Конечно, данная программа вряд ли может дать абсолютно точные цифры, но относительную производительность оценить позволяет. Запускалась данная программа с параметром /L:200000 (то есть пишем файл в ~200mb) А теперь результаты:
В последних цифрах я не ошибся, :-) все
именно так и есть. |
Результаты, надо сказать, удивительные. Что касается времени chkdsk в две секунды, то это нормально. По идее, NTFS тоже должна тестироваться мгновенно всегда. Но скорость записи в 60 мег в секунду, что в добрые два десятка раз лучше HPFS - это как-то сильновато... Хотелось бы сравнения производительности другими тестами, а то сомненья гложут.
Что касается неподдержки ACL (Access Control Lists - возможности детально описывать права доступа пользователей к файлам и каталогам), то, вероятно, IBM решил плюнуть на это дело ввиду большой сложности их поддержки в файловой системе от Юникса и позиционировать JFS как файловую систему для таких приложений как SQL и WWW-сервера, которые всяко имеют собственную схему прав доступа и не очень нуждаются в поддержке ACL, зато высокая надежность ФС для них - весьма нелишний фактор.
Тем не менее, было бы обидно, если бы ACL не появились в релизе - это означает, что JFS, в частности, нельзя применять на разделяемых по сети томах. Ну или можно применять, но в очень-очень ограниченных масштабах.