id: Гость   вход   регистрация
текущее время 22:49 28/03/2024
Автор темы: Гость, тема открыта 01/09/2005 01:20 Печать
создать
просмотр
ссылки

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 След.
Комментарии
— SATtva (01/09/2005 08:57)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
хранить закрытый ключь зашифрованный им (тем более в 2048 битов, как в HushMail) бессмыслено, а можно генерировать ключь прямо из пароля.

Приехали... Пароли никто никогда не шифрует, тем более асимметричными ключами (зачем?). Их хэшируют и передают в неявном виде. Собственно, хэш пароля и есть ключ расшифрования для закрытого ключа во всех OpenPGP-системах (HushMail в том числе). Странно, что Вы не понимаете таких элементарных вещей.

В PGP (или GPG) другое дело: пароль — просто дополнительная мера защиты.

Что бы это значило?

Конкретно как — не секрет, но сейчас лень подробно описывать.

А не лишним было бы описать, учитывая уязвимости RC4, например, неслучайность начальной гаммы.

А также, RSA ключь генерируется достаточно долго, так что подбор по словарю займет много времени.

По словарю подбирают пароли, но никак не ключи.

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

По формальным признакам уж очень смахивает на ханаанский бальзам. Конечно же, это сугубо ИМХО. Но я Вашей системой пользоваться точно не стану. А тем более платить за неё деньги. :)
— unknown (01/09/2005 09:43)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Я несколько раз оказывался в ситуации, когда единственный доступ в интернет — публичный web-терминал, а передать или получить секретное сообщение — ой, как надо

А попросить админа загрузиться с дискетки нельзя? При помощи вот этой штуки к примеру: http://tinfoilhat.shmoo.com/
(Хотя обычно нельзя конечно)

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

Не помню где, но утверждалось, что 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), просто не очень внятно изложенная.
— unknown (01/09/2005 09:56)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
По формальным признакам уж очень смахивает на ханаанский бальзам. Конечно же, это сугубо ИМХО.

P. S. Sattva, если это тот "Daniel A. Nagy ", с которым я лично переписывался и обсуждал некоторые вопросы криптографии, то он достаточно компетентный в своей области человек: http://www.epointsystem.org/~nagydani/homepage

Иногда он не совсем хорошо говорит по-русски, по этому не стоит слишком придираться к его словам, не выяснив, в чем дело, что он конкретно имеет в виду.
— Гость (01/09/2005 11:57)   <#>
Приехали... Пароли никто никогда не шифрует, тем более асимметричными ключами (зачем?).

Вы меня неправильно поняли: шифруется закрытый ключь при помощи пароля (как там из пароли делается ключь для симметричного шифра — вопрос совсем другой). В HushMail происходит следующее: пароль хешируется двумя разными способами, и результат одного используется как ключь к шифрованию закрытого ключа, а результат другого — как индекс в базе данных, где эти зашифрованные ключи хранятся.

В PGP (или GPG) другое дело: пароль — просто дополнительная мера защиты.

Что бы это значило?

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

А не лишним было бы описать, учитывая уязвимости RC4, например, неслучайность начальной гаммы.

Ну ладно, читайте сами по-английски: http://www.epointsystem.org/~nagydani/one-factor

Именно из-за неслучайности начальной гаммы отбрасывается первые 256 символов. В случае ElGamal-ключа, вообще отбрасываю первый мегабайт.

А также, RSA ключь генерируется достаточно долго, так что подбор по словарю займет много времени.

По словарю подбирают пароли, но никак не ключи.

В том то и вся фишка, что у меня ключь генерируется исходя из пароля. Для того, чтобы проверить пароль, надо сгенерировать первое простое число, и проверить, делит ли оно модуль ключа RSA.
— Гость (01/09/2005 12:07)   <#>
Generating an RSA key pair involves generating two N/2 bit primes. If these primes are congruent to 3 mod 4, the public modulus will be a Blum integer. The advantage is that the best known zero-knowledge proof of factorization of Blum integers is a lot more efficient than the best known zero-knowledge proof of factorization. Thus, we propose the following method for generating an N or N-1 bit RSA key, where N is divisible by 16:

1. Initialize an RC4 keystream generator with a key consisting of the concatenation of the user id, the 0x0A separator, the password and the 0x00 terminator.

2. Discard the first 256 bytes from the keystream.

3. Read N/16 bytes from the keystream into p in big-endian manner.

4. Set the most significant bit and the two least significant bits of p

5. Test p for primality. If it fails, go to step 3.

6. Verify that the system-wide public exponent e (e.g. F4=65537) and p are relative primes. If not, go to step 3.

7. Generate q the same way as p.

8. The public modulus becomes pq.

9. Calculate d as the multiplicative inverse of e mod (p-1)(q-1), If (q-1) and e are relative primes, otherwise go to step 7.


— Гость (01/09/2005 12:11)   <#>
Сам код java тоже выставлен на публичное обозрение.
генератор ключа RSA
генератор ключа ElGamal

Можете посмортеть, проверить. Я старался писать просто и понятно.
— Гость (01/09/2005 12:26)   <#>
unknown:

Не помню где, но утверждалось, что RC4-encryption=E(IV || K) и E(K || IV) ненадежны. Не впихнуть туда нормальный вектор инициализации. Очень желательно хэшировать перед шифрованием: RC4-ecncryption=E(H(IV || K)). Это даже если оставить в стороне невысокий статус RC4. У Вас так сделано или как-то иначе? <!--escaped--></blockquote><!--escaped--> У меня просто E(IV||K), и я об этой слабостит RC4 не слышал. Интересно было бы прочитать статью.

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

Мне тоже так кажется.

https://www.epointsystem.org/pks/tool: Java-апплет?

Да.

У меня нет возможности проверить работу с Java. Но идея понятна. Развертывание "походного" ассиметричного ключа происходит из пароля. Пользователь все равно должен доверять и рабочему терминалу и Вашему серверу (так же как HushMail). Ну разве что у вас applet побыстрее качается.

Это верно. Безопасности я по сравнению с HushMail не добавил, только надежность. Свой "походный ключ" я смогу восстановить даже если провайдер сгорит в пожаре. HushMail, если им не пользоваться некоторое время, то уничтожает закрытый ключ, и потом его уже никак не восстановить.

Мне кажется, что я создал систему по безопасности сравнимую с HushMail, но с меньшими затратами ресурсов и меньшим риском утраты ключа для пользователя.

Т.е. Вы к своему обычному ключу цепляете на связку "походный ключ", не наделенный особым доверием и если что можете временно им пользоваться в поездках, разворачивая его прямо из пароля в Java-апплете браузера. В принципе идея может и не плохая, там где не нужна особая безопасность (по аналогии с hushmail), просто не очень внятно изложенная.

Спасибо за более понятное изложение! Разрешаете использовать эту формулировку в русскоязычной документации?
— unknown (01/09/2005 13:41)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664


Weaknesses in the Key Scheduling Algorithm of

RC4

Scott Fluhrer1, Itsik Mantin2, and Adi Shamir2 1 Cisco Systems, Inc., 170 West Tasman
Drive, San Jose, CA 95134

sfluhrer@cisco.com 2 Computer Science department, The Weizmann Institute, Rehovot 7610
0, Israel.

fitsik, shamirg@wisdom.weizmann.ac.il

Abstract. In this paper we present several weaknesses in the key scheduling algorithm
of RC4, and describe their cryptanalytic significance. We identify a large number of w
eak keys, in which knowledge of a small number of key bits suffices to determine many
state and output bits with non-negligible probability. We use these weak keys to const
ruct new distinguishers for RC4, and to mount related key attacks with practical compl
exities.



Section 6 describes a weakness of RC4 in a common mode of operation in which attacker
visible IV's are concatenated with a fixed secret key. It is easy

to extend the attack to other simple types of combination operators (e.g., when we XOR
the IV and the fixed key) with essentially the same complexity. We recommend to neutr
alize this weakness by avoiding this mode of operation, or by using a secure hash to f
orm the key presented to the KSA from the IV and secret key


Были и какие-то комментарии на эту статью для тех, кто все таки хочет использовать RC4 не
использовать конкатенацию или XOR ключа и IV.



Спасибо за более понятное изложение! Разрешаете использовать эту формулировку в русскоязычной документации?


Да пожалуйста! Используйте. Нам не жалко.
— SATtva (01/09/2005 14:19)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Д. Надь, спасибо за более развёрнутый ответ на мою критику. К сожалению, цепляние за некорректные и неточные формулировки — побочный эффект юридического образования. ;) Читал Ваши комментарии в OpenPGP WG, но не сразу понял, что здесь именно Ваш постинг. За "диагноз" прошу извинить, но рад, что недопонимание разрешилось. :)
— unknown (01/09/2005 17:35)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Если такая схема окажется надежной (в рамках всех допущений), то ключ, разворачиваемый из пароля можно назначить для отмены (отзыва) основного ключа PGP, если он скомпрометирован, а копий или отзывающих сертификатов и доверенных отменителей не осталось.

Потерявшему все, израненному и преследуемому паранойей владельцу ключа достаточно будет доползти до ближайшего Интернет-кафе и набрать заветный пароль в браузере!

Пароли для защиты основного и разворачивания отменяющего ключа конечно же должны быть разными.
— SATtva (01/09/2005 18:03)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Потерявшему все, израненному и преследуемому паранойей владельцу ключа достаточно будет доползти до ближайшего Интернет-кафе и набрать заветный пароль в браузере!

Интересен в этом аспекте вопрос кодировки. Скажем, один пароль, набранный в utf8 или cp1251, даст два разных ключа. Видимо, джава-апплет должен преобразовывать пароль к какой-то одной кодировке, вероятно, utf8.
— Гость (01/09/2005 19:10)   <#>
Да, все кодировки преобразуются в UTF-8. И еще одно предупреждение: некоторые реализации джавы не разрешают в элементе графического интерфейса для паролей ничего, кромя US-ASCII printable. То же самое можно сказать про некоторые клавиатуры публичных интернет-терминалов.
Хотя настоящий параноик выберает пароль мышкой из случайной перестановки символов, чтобы защититься от keylogger-ов. ;-) Гммм, может быть реализовать и такой способ ввода?
— Гость (01/09/2005 19:37)   <#>
unknown:
Weaknesses in the Key Scheduling Algorithm of RC4

Scott Fluhrer1, Itsik Mantin2, and Adi Shamir2 1 Cisco Systems, Inc., 170 West Tasman
Drive, San Jose, CA 95134

Это я конечно внимательно прочитал перед тем, как использовать RC4. Вот, кстати, ссылка на pdf: filehttp://www.drizzle.com/~aboba/IEEE/rc4_ksaproc.pdf
Вот некоторые замечания на этот счет от RSADSI: http://www.rsasecurity.com/rsalabs/node.asp?id=2009

Непосредственно атаки описанные в статье к моему случаю неприменимы. Грубо говоря дело в том, что длина минимально распознаваемого выхода RC4 очень быстро растет удаляясь от начала потока. Даже после отбрасывания первых 256 байтов предсказать хоть один бит первого 512-битового простого числа в потоке — нереально. В случае ElGamal ключа, я отбрасываю целый мегабайт (это, к слову, обычно значительно меньше, чем первое простое число), и использую всего 32 байта, так что описанные атаки даже с перспективными доработками не применимы. Я думал речь о чем-то новом.
— SATtva (01/09/2005 19:44)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Гммм, может быть реализовать и такой способ ввода?

Учитывая модель угрозы и естественные ограничения Вашей реализации, не думаю, чтобы это было целесообразно. И движения мыши, и снимки экрана тоже можно снять "средствами удалённого администрирования".

[off-topic]
В каком-то из дискуссионных листов (cypherpunk, кажется) когда-то предлагали такой способ ввода: виртуальная клавиатура для ввода мышкой, но без нанесённых на неё букв; само расположение букв (случайное) печатается на принтере. Здесь, правда, тоже упираемся в целостность (в смысле integrity) среды исполнения и периферии: буфер принтера можно прочитать, кабель — прослушать. Решением тут может быть (за исключением Trusted Computing Base) — КПК с единственным криптографическим приложением, поставленным на чистую ОС, без всяких средств связи, кроме флэш-карт.
[/off-topic]
— Гость (01/09/2005 20:22)   <#>
Да нет, конечно. Поставленная задача: догнать по степени безопасности HushMail сэкономив как можно больше ресурсов и повысив надежность.

С одной стороны, окошко HushMail для ввода пароли предусматривает пароль из 10-20 символов, с другой стороны они рекламируют безопасность 4096-битового ключа RSA. Смешно. А то, что они берут в заложники мой закрытый ключ, если я не пользуюсь им некоторое время, и требуют денежный выкуй — просто наглость.

И это еще не все проблемы с HushMail: у них подписанное и зашифрованное сообщение выглядит следующим образом: формируется документ clearsigned, и в этом виде он шифруется как текст, даже без MDC. Конечно в ручную это проверяется, но обычные почтовые клиенты на такую дикость не рассчитывают и автоматически не проверяют такую подпись. Поддержка международных шрифтов (кириллица, и пр.) тоже хромает в HushMail. Мой апплет формирует сообщения по всем правилам, и как полагается использует UTF-8 во всех случаях.
На страницу: 1, 2 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3