PGP на ходу

Я несколько раз оказывался в ситуации, когда единственный доступ в интернет — публичный web-терминал, а передать или получить секретное сообщение — ой, как надо.
Раньше для этого у меня был account в HushMail, но это во-первых монстр (скачиваются мегабайты перед тем, как все заработает), a во-вторых если не пользоватся регулярно, то закрывают доступ и что еще печальнее — теряешь закрытый ключь.
Я решил эту проблему иначе: так, как безопасность системы всеравно не прeвышает безопасность пароля, хранить закрытый ключь зашифрованный им (тем более в 2048 битов, как в HushMail) бессмыслено, а можно генерировать ключь прямо из пароля. В PGP (или GPG) другое дело: пароль — просто дополнительная мера защиты.
Регистриротвать такие ключи можно тут: http://pgp.epointsystem.org
Пользоваться ими (шифровать, и проверять подписи, кстати, можно для любых ключей, предварительно закинув их на сервер) тут: http://pgp.epointsystem.org/tool-help

Пароль (или в случае подписи — имя и пароль) служат ключем к генератору псевдослучайного потока RC4, из которого и генерируются ключи. Конкретно как — не секрет, но сейчас лень подробно описывать.

Для подписи используется 1024-битовые RSA ключи, для шифрования 1024-битовые ElGamal ключи. Дело в том, что все схемы подписи кромя RSA катастрофически ломаются (то есть — открывают закрытый ключь), если выбранное случайное значение при подписи (такого в RSA нет) не достаточно случайно, так что они не подходят для публичных терминалов. А также, RSA ключь генерируется достаточно долго, так что подбор по словарю займет много времени.
Для шифрования используется ElGamal, потому что он мне больше нравится, чем RSA, хотя, конечно и RSA подходит (и, кстати, реализованно в данном приложении, просто ключь RSA для шифрования не регистрируется).

Для шифрования использую 3DES, так как этот блочный шифр доступен во всех реализациях OpenPGP по RFC2440 а также в JRE1.4, а значит его не надо скачивать с сервера при загрузки applet-а.

Что вам эта идея и ее реализация?

На страницу: 1, 2 След.

Комментарии

—	*Гость* (01/09/2005 20:38) <#>

Справедливости ради стоит отметить, что от 4096-битовых RSA-ключей они уже несколько лет назад отказались, и сейчас используют 1024-битовые DSA для подписи и 2048 битовый ElGamal для шифрования (мой ключ был уже таковым), но даже от этого польза весьма сомнительная.

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

—	unknown (01/09/2005 21:22) профиль/связь <#> комментариев: 9796 документов: 488 редакций: 5664

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

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

Не внушает в меня оптимизма и работа Luke O'Konnor "On the Enthropy of Arcfour keys" из IBM research.
И все его улучшить пытаются (VMPC).

И дядьке Шнайеру он давно не нравится.

Но в конце концов не в нем (не в RC4) дело. PRNG можно реализовать и другой

Идея возможно годится для "travel key" или "password key revoker", для пользователей, которым нужна простота, легкость, мобильность и невысокий уровень безопасности.

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

Ссылку можете привести хоть на одно подобное исследование в данной области?

—	*Гость* (01/09/2005 21:40) <#>

Ассиметричные ключи генерировали и раньше, только не RSA ключи, по той простой причине, что это было не под силу персональным компам в еще не очень далеком прошлом. Даже используя простенький генератор RC4 (не случайно!), развертка ключа из пароля длится несколько секунд (до полминуты, в особо неудачных случаях) в джава, и примерно в два раза быстрее в си на Pentium II 500MHz.

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

A вообще очень хорошие и широко цитируемые труды существуют на данную тему, и вполне практичные приложения.
Вот например классика: http://srp.stanford.edu/ndss.html

—	*Гость* (01/09/2005 21:44) <#>

Не знаю, как давно PGP попало в ваше поле зрения, но в начале девяностых у меня чай остывал, пока генерировался ключ приличной длины.

—	SATtva (01/09/2005 23:26) профиль/связь <#> комментариев: 11558 документов: 1036 редакций: 4118

Году в 94-м – 95-м (даже точно не помню) у меня ушло около суток, чтобы сгенерировать на i486 (эксперимента ради) 16-килобитный ключ RSA. Сегодня мобильные телефоны обладают сопоставимой или превосходящей вычислительной мощносностью.

К слову, возможно ли портировать Ваше приложение под мобильную платформу J2ME?

—	*Гость* (02/09/2005 00:02) <#>

Планирую этим занятся в не очень отдаленном будущем, в начале следующего года. А там — война план покажет. :-)
Вообще-то мобильник можно считать физически защищенным аппаратом с индивидуальным доступом, так что развертывать ключи из паролей там скорее всего не надо. Но плотно упакованная реализация RFC2004bis может пригодиться.
Писать и читать PGP-сообщения девайсом типа blackberry — заманчиво.

—	unknown (02/09/2005 09:04) профиль/связь <#> комментариев: 9796 документов: 488 редакций: 5664

A вообще очень хорошие и широко цитируемые труды существуют на данную тему, и вполне практичные приложения.
Вот например классика: http://srp.stanford.edu/ndss.html

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

—	unknown (02/09/2005 09:33) профиль/связь <#> комментариев: 9796 документов: 488 редакций: 5664

don't trust RC4 as a hashing function. It is not very good at
stirring input bytes (as witnessed by, e.g., Roos weak key class,
various related-key attacks, and other unpublished bad properties of the
key schedule). Thus, I recommend against using it as a way to stir in
entropy (and I see no reason to prefer it).

It's probably ok as a way of stretching good bits that you extracted
from an entropy pool, but of course, any stream or block cipher would
do for this application.

Why don't you tell us what your performance bound is, and maybe we can
find some other way to achieve it with better-studied primitives?

© David Wagner.
где то именно в его работах или сообщениях мне попадались предостережения от использования KEY || IV .даже после отбрасывания первых n-байтов гаммы. Может я ошибаюсь. Я точно не помню.

Попробуйте с ним связаться.

Я понимаю, что RC4(drop bytes) самый быстрый, но его рекомендуют использовать только в крайних случаях.
Лучше все-таки использовать подходящий режим RIJNDAEL (IV, K)
Где K=Hash(passwd)

—	*Гость* (02/09/2005 21:29) <#>

Да, скорее всего придется связаться с автором. В случае походных ElGamal ключей, наверное я просто перейду к старым добрым методам S2K (string to key) основанных на итеративном использовании хеш-функций. Нечего изобретать велосипед. Длина секретной части ElGamal-ключа соответствует длине выхода хеш-функции.
Но в случае RSA-ключей (а для подписей только они и подходят, см. другую тему), по-моему все эти атаки на RC4 — непрактичны, так как угодав несколько битов потока, противник ничего не узнает о том, какое именно простое число первым попадется в потоке. А скорость RC4 мне очень нужна. Если используя RC4 у меня ключ разворачивается в течении, скажем 10 секунд, то используя Rijndael, это будет 50 секунд, что уже неприемлимо.

На страницу: 1, 2 След.

Ваша оценка документа [показать результаты]