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-а.
Что вам эта идея и ее реализация?
В данных условиях я считаю 1024-битовый ключь вполне адекватным, а 2048-битовый — внушающим необоснованное чувство безопасности. Использование DSA подписи на публичных терминалах тоже считаю необоснованно рискованным, так как можно утратить секретность закрытого ключа прямо в подписи, и никогда об этом не узнать.
комментариев: 9796 документов: 488 редакций: 5664
Еще надо убить админов, ходящих вокруг публичных терминалов, а то они там вечно подглядывают из за спины и тайминг-атаки с секундомером проводят.
Не внушает в меня оптимизма и работа Luke O'Konnor "On the Enthropy of Arcfour keys" из IBM research.
И все его улучшить пытаются (VMPC).
И дядьке Шнайеру он давно не нравится.
Но в конце концов не в нем (не в RC4) дело. PRNG можно реализовать и другой
Идея возможно годится для "travel key" или "password key revoker", для пользователей, которым нужна простота, легкость, мобильность и невысокий уровень безопасности.
Опять же, меня смущает, почему никто раньше ассиметричные ключи из паролей не генерировал? Хотя бы для не особо важных приложений.
Ссылку можете привести хоть на одно подобное исследование в данной области?
A из-за проблематичности подписи на дискретных логаритмах, для подписей не использовали ранее ассимметричные ключи развернутые из пароля, но для санкционирования доступа они уже давно в ходу.
A вообще очень хорошие и широко цитируемые труды существуют на данную тему, и вполне практичные приложения.
Вот например классика: http://srp.stanford.edu/ndss.html
комментариев: 11558 документов: 1036 редакций: 4118
К слову, возможно ли портировать Ваше приложение под мобильную платформу J2ME?
Вообще-то мобильник можно считать физически защищенным аппаратом с индивидуальным доступом, так что развертывать ключи из паролей там скорее всего не надо. Но плотно упакованная реализация RFC2004bis может пригодиться.
Писать и читать PGP-сообщения девайсом типа blackberry — заманчиво.
комментариев: 9796 документов: 488 редакций: 5664
Да, интересно. Действительно, время пришло и пора использовать новые мощности компьютерного железа на благо криптографии. Держите в курсе своих разработок.
комментариев: 9796 документов: 488 редакций: 5664
© David Wagner.
где то именно в его работах или сообщениях мне попадались предостережения от использования KEY || IV .даже после отбрасывания первых n-байтов гаммы. Может я ошибаюсь. Я точно не помню.
Попробуйте с ним связаться.
Я понимаю, что RC4(drop bytes) самый быстрый, но его рекомендуют использовать только в крайних случаях.
Лучше все-таки использовать подходящий режим RIJNDAEL (IV, K)
Где K=Hash(passwd)
Но в случае RSA-ключей (а для подписей только они и подходят, см. другую тему), по-моему все эти атаки на RC4 — непрактичны, так как угодав несколько битов потока, противник ничего не узнает о том, какое именно простое число первым попадется в потоке. А скорость RC4 мне очень нужна. Если используя RC4 у меня ключ разворачивается в течении, скажем 10 секунд, то используя Rijndael, это будет 50 секунд, что уже неприемлимо.