Кто-нибудь может объяснить, всё же, смогу ли я продавать программу использующую OpenSSl ? А то я не очень силён в тонкостях англ. языка 

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



Я говорю о том, что грамотных криптоаналитиков, способных подвергнуть фундаментальному анализу серьёзные алгоритмы, в мире не так много, а ты мне про подход



Ну компилировать я слава Богу пока не разучился, скомпилировать и заставить работать разные вещи Или у тебя получилось найти коллизию к какому-нибудь хешу?
PS: http://www.securitylab.ru/software/232876.php
Сам не качал, нет возможности проверить, поэтому насчёт работоспособности ничего сказать не могу, но учитывая статус ресурса стоит задуматься

ссылка дохлая

ХЫ-ХЫ-ХЫ долго ржал, все дружно идем сюда:
http://www.aisys.ru/mdcrack/

Добавлено @ 21:40 
W4FhLF, 

Это обычный переборщик. И как правильно заметил товарищ(если нажать "прикинуть")
 по ссылке http://www.aisys.ru/mdcrack/ то в среднем при средних условиях это займет столько времени, что "Даже если начать прямо сейчас, то хрена мы дождемся...".

En_t_end, ну, написано, что якобы коллизии ищет, поэтому я и обратил внимание. Не написали бы они это просто так?

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



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



Видимо это и имел ввиду Snowy, тока вот потоковое-надо на симметричное заменить. (Потоковое шифрование может быть и асимметричным, впринципе любой блочный алгоритм, можно легко использовать для потокового шифрования)
На мой взгляд данный метод лучше Хельман: на клиенте не надо постоянно генерировать большие простые числа для ключей, а на сервере подобные ключи можно генерировать раз в пол года и затем постоянно использовать один и тот же ключ. 



Эт точно, чтоб написать библиотеку работы с большими числами - уйдет много свободного вермени, проще использовать уже готовые открытые реализации.
А вот поиск больших чисел - это простите не от программиста зависит, он не должен писать какой-то сверхумдренный алгоритм их поиска. Просто случайно генерируются числа и проверяются на простоту каким-нибудь полиноминальным алгоритмом. Единственно, что можно сделать, чтобы теоретически ускорить поиск в 2 раза - это менять последний бит на 1, чтоб числа были нечетными.


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


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

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




Да не, помнится, когда было опубликовано это сообщение кто-то даже примеры коллизионных хешей приводил, была выложена md5coll.c которая под вендой ни у кого не пахала, но говорили, что под никсами на приличной машине люди за 2 часа находили коллизию к хешу. Потом ещё одна статья вышла описывающая способ взлома md5 за 8 часов, после ещё несколько публикаций о уязвимостях. Было это уже больше полутора лет назад, поэтому я забыл подробности. 

 Ну как то я не думаю, что будет переслан только один пароль к чему это?

Alexandr87, 

На данный момент мне нужно лишь передать пароль таким образом, чтобы его не заснифили. Дальнейший обмен я по видимому буду вести через потоковые алгоритмы.
ЗЫ блин, уже голова болит. Мне надо каким-то образом заюзать Хельмана, но не ввязываясь в авантюры с лицензиями. Может есть где-то в сети любительские реализации Хельмана ? вместе с решенным вопросом генерации больших простых чисел.

Про это и разговор - перечитайте еще раз посты. Разговор, как раз про то, чтобы передать сессионый ключ для, как вы говорите, "потокового" алгоритма.

Добавлено @ 12:57 
Не заморачивайтесь с Хельманом - используйте SSL. На мой взгляд - использование Хульмана в данной ситуации избыточно, или тогда нужно вообще пересмотреть систему аутентификации и построить её на открытых ключах, тогда впринципе волнение, что пароли будут сперты с сервера проподет.




Это сообщение отредактировал(а) Alexandr87 - 20.1.2007, 13:11

Единственные заморочки там с  p и r, а они открытые(т.е одного раза их достаточно сгенерить на всё жизнь). Остальные - обыкновенные интегеры.


В России насколъко я знаю вообще такая криптография вообще запрещена  законом  


Нет, это можно сделать, чтобы ускорить поиск практически, дополнительно можно не рассматривать числа менъше корня числа. А для теории, также применяемой на практике,  существует множество быстрых способов определения, что число НЕ простое (эх, криптографией уже года с 2 не занимался , а то бы побольше рассказал там Якоби, Эйлер итд.). Этими способами отсекается куча мусора. К тому же простые числа встречаются довольно часто даже оооочень большие. Это теорема и она не доказана(это как раз повод получить Нобеля).

sergejzr, 

Т.е. каким это образом ?

Добавлено @ 15:37 

Как же тогда https'ы в России, работающие через SSL, в котором этот алгоритм(там он называется DH) реализован ?

Мне тоже интересно  В подробности законодательства РФ я не вникал, но погуглил немного.


То есть спецслужбы хотят иметь все ключи. ИМХО - полный маразм.

Кстати, помоему, Нобелевскую Премию не дают за математику...

En_t_end, почитай про Эйлера. Великий математик он так же работал в областях физики, механики, астрономии итд. Математика  - одно дело, её применение - другое.