ИМХО, надо бы за такую фигню подать в жалобу в Мжд. Суд По Правам Человека, ибо нефиг. Интересно, почему тогда не пресуют PGP'шников ?
Отсюда вообще следует, что в России запрещается использовать какие-либо "стойкие" алгоритмы, ибо под определение "сильной защиты" они то как раз и относятся 

Добавлено @ 15:56 
sergejzr, 
Я имел ввиду чистую математику, как то простые числа.

Добавлено @ 16:07 
sergejzr, спасибо за информацию, я этого вообще не знал. Прочитал документ по твоей ссылке и был неприятно удивлен.

Это сообщение отредактировал(а) En_t_end - 20.1.2007, 15:55

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


Всмысле не рассматиравать? Для детерменированной проверки? Даже если их не рассматривать то умрешь раньше чем он проверит одно число. и это действительно практически.



А я это и не отрицал, я про это и говорил

Вот накалякал, ИМХО, решение моей проблемы.
В левом верхнем углу решение №1 всё остальное - №2

Это сообщение отредактировал(а) En_t_end - 22.1.2007, 15:35

Присоединённый файл ( Кол-во скачиваний: 15 )
 Shem.jpg 20,72 Kb

а чем тебе не понравилась идея ассиметричного шифрования... имхо в данной ситуации это лучший вариант!!.. 
.... или я не правильно понял твою диаграмму))

Это сообщение отредактировал(а) v2v - 22.1.2007, 17:30

Что-то не понять мне никак вашей схемы, поясните пожалуйста словами.

Это сообщение отредактировал(а) Alexandr87 - 23.1.2007, 05:58

Alexandr87, 

В левом верхнем углу:
На сервере хранятся пароли в виде F(password)
При каждом соединении генерируется новой массив байтов r.
Клиент получает r и использует формулу: G(F(Password)+r) для посылки пароля серверу.
Сервер соответсвенно выполняет команду:
G(F(Password)+r)==G(F(Password)+r)
Чтобы удостверится, что пароль действительно правильный.
F,G - хеширующие.
НО! здесь я обманываю сам себя... ведь зная F(Password) который хранится на сервере(не исключаем возможности похищения хешей) BadMan может зайти на сервер под видом клиента. Т.е снова плохо.
Случай №2 гораздо предпочтительней описан он здесь:
http://forum.vingrad.ru/s/3232d0997705d45e...ml#entry1008574
Но мне кажется, что и тут меня ждет фиаско, ибо слишком уж много я требую от хеширующих функций...

В общем моё мнение по поводу 1.("в левом верхнем углу"), ага только теперь кроме той проблеммы, которую назвали вы:

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

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

По идее "по правилам криптографии" по настоящему секретным может считаться только ключ, который нигде не хранится (кроме головы пользователя). Что касается всей остальной инфы, мы должны исходить из того, что она может попасть в руки врага полностью или частично. 

Враги вообще повсюду )))



Тем более, что этот велосипед всегда будет хуже. 

(ну если только изобретающий не гуру-криптограф, второй диффи-хельманн  )

ПС:
Большой оффтоп
Я сейчас тоже комплексной системой занимаюсь. Так вот, на яве такое писать - одно удовольствие. Включая SSL, private/public key, сокеты итд.

ОФФТОП

))) насколько память мне не изменяет - это  два человека.

http://www.securitylab.ru/news/289448.php

W4FhLF,

с твоей ссылки