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-а.
Что вам эта идея и ее реализация?
комментариев: 11558 документов: 1036 редакций: 4118
Приехали... Пароли никто никогда не шифрует, тем более асимметричными ключами (зачем?). Их хэшируют и передают в неявном виде. Собственно, хэш пароля и есть ключ расшифрования для закрытого ключа во всех OpenPGP-системах (HushMail в том числе). Странно, что Вы не понимаете таких элементарных вещей.
Что бы это значило?
А не лишним было бы описать, учитывая уязвимости RC4, например, неслучайность начальной гаммы.
По словарю подбирают пароли, но никак не ключи.
По формальным признакам уж очень смахивает на ханаанский бальзам. Конечно же, это сугубо ИМХО. Но я Вашей системой пользоваться точно не стану. А тем более платить за неё деньги. :)
комментариев: 9796 документов: 488 редакций: 5664
А попросить админа загрузиться с дискетки нельзя? При помощи вот этой штуки к примеру: http://tinfoilhat.shmoo.com/
(Хотя обычно нельзя конечно)
Не помню где, но утверждалось, что RC4-encryption=E(IV || K) и E(K || IV) ненадежны. Не впихнуть туда нормальный вектор инициализации. Очень желательно хэшировать перед шифрованием: RC4-ecncryption=E(H(IV || K)).
Это даже если оставить в стороне невысокий статус RC4.
У Вас так сделано или как-то иначе?
Впрочем, для Вашей схемы, где высокий запас прочности особенно не нужен это может быть несущественно.
https://www.epointsystem.org/pks/tool: Java-апплет?
У меня нет возможности проверить работу с Java. Но идея понятна. Развертывание "походного" ассиметричного ключа происходит из пароля. Пользователь все равно должен доверять и рабочему терминалу и Вашему серверу (так же как HushMail). Ну разве что у вас applet побыстрее качается.
Т.е. Вы к своему обычному ключу цепляете на связку "походный ключ", не наделенный особым доверием и если что можете временно им пользоваться в поездках, разворачивая его прямо из пароля в Java-апплете браузера. В принципе идея может и не плохая, там где не нужна особая безопасность (по аналогии с hushmail), просто не очень внятно изложенная.
комментариев: 9796 документов: 488 редакций: 5664
P. S. Sattva, если это тот "Daniel A. Nagy ", с которым я лично переписывался и обсуждал некоторые вопросы криптографии, то он достаточно компетентный в своей области человек: http://www.epointsystem.org/~nagydani/homepage
Иногда он не совсем хорошо говорит по-русски, по этому не стоит слишком придираться к его словам, не выяснив, в чем дело, что он конкретно имеет в виду.
Вы меня неправильно поняли: шифруется закрытый ключь при помощи пароля (как там из пароли делается ключь для симметричного шифра — вопрос совсем другой). В HushMail происходит следующее: пароль хешируется двумя разными способами, и результат одного используется как ключь к шифрованию закрытого ключа, а результат другого — как индекс в базе данных, где эти зашифрованные ключи хранятся.
То и значит, что пароль — дополнительная мера защиты криптографического ключа (основная мера защиты — ограниченный физический доступ). То есть увеличение размера ключа прибавит безопасности даже в случае одного и того же пароля. Но если ключ на чужом сервере, и защищен он только паролем, то увеличивать длину ключа бессмыслено, когда взлом ключа и подбор пароля примерно равны по затратам.
Ну ладно, читайте сами по-английски: http://www.epointsystem.org/~nagydani/one-factor
Именно из-за неслучайности начальной гаммы отбрасывается первые 256 символов. В случае ElGamal-ключа, вообще отбрасываю первый мегабайт.
В том то и вся фишка, что у меня ключь генерируется исходя из пароля. Для того, чтобы проверить пароль, надо сгенерировать первое простое число, и проверить, делит ли оно модуль ключа RSA.
генератор ключа RSA
генератор ключа ElGamal
Можете посмортеть, проверить. Я старался писать просто и понятно.
комментариев: 9796 документов: 488 редакций: 5664
Были и какие-то комментарии на эту статью для тех, кто все таки хочет использовать RC4 не
использовать конкатенацию или XOR ключа и IV.
Да пожалуйста! Используйте. Нам не жалко.
комментариев: 11558 документов: 1036 редакций: 4118
комментариев: 9796 документов: 488 редакций: 5664
Потерявшему все, израненному и преследуемому паранойей владельцу ключа достаточно будет доползти до ближайшего Интернет-кафе и набрать заветный пароль в браузере!
Пароли для защиты основного и разворачивания отменяющего ключа конечно же должны быть разными.
комментариев: 11558 документов: 1036 редакций: 4118
Интересен в этом аспекте вопрос кодировки. Скажем, один пароль, набранный в utf8 или cp1251, даст два разных ключа. Видимо, джава-апплет должен преобразовывать пароль к какой-то одной кодировке, вероятно, utf8.
Хотя настоящий параноик выберает пароль мышкой из случайной перестановки символов, чтобы защититься от keylogger-ов. ;-) Гммм, может быть реализовать и такой способ ввода?
Это я конечно внимательно прочитал перед тем, как использовать RC4. Вот, кстати, ссылка на pdf: http://www.drizzle.com/~aboba/IEEE/rc4_ksaproc.pdf
Вот некоторые замечания на этот счет от RSADSI: http://www.rsasecurity.com/rsalabs/node.asp?id=2009
Непосредственно атаки описанные в статье к моему случаю неприменимы. Грубо говоря дело в том, что длина минимально распознаваемого выхода RC4 очень быстро растет удаляясь от начала потока. Даже после отбрасывания первых 256 байтов предсказать хоть один бит первого 512-битового простого числа в потоке — нереально. В случае ElGamal ключа, я отбрасываю целый мегабайт (это, к слову, обычно значительно меньше, чем первое простое число), и использую всего 32 байта, так что описанные атаки даже с перспективными доработками не применимы. Я думал речь о чем-то новом.
комментариев: 11558 документов: 1036 редакций: 4118
Учитывая модель угрозы и естественные ограничения Вашей реализации, не думаю, чтобы это было целесообразно. И движения мыши, и снимки экрана тоже можно снять "средствами удалённого администрирования".
[off-topic]
В каком-то из дискуссионных листов (cypherpunk, кажется) когда-то предлагали такой способ ввода: виртуальная клавиатура для ввода мышкой, но без нанесённых на неё букв; само расположение букв (случайное) печатается на принтере. Здесь, правда, тоже упираемся в целостность (в смысле integrity) среды исполнения и периферии: буфер принтера можно прочитать, кабель — прослушать. Решением тут может быть (за исключением Trusted Computing Base) — КПК с единственным криптографическим приложением, поставленным на чистую ОС, без всяких средств связи, кроме флэш-карт.
[/off-topic]
С одной стороны, окошко HushMail для ввода пароли предусматривает пароль из 10-20 символов, с другой стороны они рекламируют безопасность 4096-битового ключа RSA. Смешно. А то, что они берут в заложники мой закрытый ключ, если я не пользуюсь им некоторое время, и требуют денежный выкуй — просто наглость.
И это еще не все проблемы с HushMail: у них подписанное и зашифрованное сообщение выглядит следующим образом: формируется документ clearsigned, и в этом виде он шифруется как текст, даже без MDC. Конечно в ручную это проверяется, но обычные почтовые клиенты на такую дикость не рассчитывают и автоматически не проверяют такую подпись. Поддержка международных шрифтов (кириллица, и пр.) тоже хромает в HushMail. Мой апплет формирует сообщения по всем правилам, и как полагается использует UTF-8 во всех случаях.