Звучит круто, но в pdf ни слова о алгоритме, страничка на которую дана сцылка в той же pdf is under construction... (((

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

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

одно плохо... коллизия это одно, а вот искомая строка к сажылению другое... например если в бд пароль храница в виде md5(mypassword), то коллизия покатит, если не содержыт, конечно, символов с ord < 32..

а дядька видно сурьёзный, видали сколько у него публикаций...

ну да, это я и  имел в виду...

Одна проблема, подавляющее кол-во паролей не будут проходить проверку на спецсимволы.

хм! интересно...
А прогу кто нить уже пишет или алгоритм - военная тайна ?  

Да что то то китайци SHA1 то вот теперь MD, придется криптографам почасать затылок и придумать более продвинутый алгоритм шифрования

Кстати, по поводу хэш-алгоритмов: по ссылочке на блог Шнайера есть кое-какая интересная мысль:

All hashes are necessarily vulnerable to less than brute-force attack as well, simply because they are hashes. Anytime hashtext is allowed to be shorter than the corresponding plaintext, collisions must occur because the possible combinations are more finite. There is no way around this, so like for public-key cryptography, one must compensate by having longer hashtext. The perceived usefulness of modern hashes appears to exceed the perceived usefulness of the 8-bit checksum by a magnitude proportional to how many more collisions the 8-bit checksum would have in the given application. Defining "broken" as "requiring less than brute force" therefore renders the term "broken" meaningless since, in the absence of more "secure" hashing algorithms, making the hashtext longer necessarily reduces collisions. However, because when the length of the hashtext reaches the length of the plaintext, you essentially have symmetric cryptography with a known key and algorithm (unless of course the algorithm allows collisions when hashtext length equals plaintext length, currently seen as undesirable), there is a paradox where a longer hashtext is also less secure. The true usefulness of a hash is proportional to how much processing it takes to find a collision. If we assume that the more processing it takes to calculate a hash in the first place, the more processing it would take to find a collision, the challenge becomes the development of hash algorithms that take more processing power. If available processing power were to cease increasing, the practicality of finding collisions would also cease to increase, and there would be no further need or use for newer hash algorithms that take more processing power. As long as that doesnt happen, expect each hash algorithm to be replaced periodically with a newer one that takes more steps to calculate. After all is said and done, that is really the only way to stay ahead of the game.

Вкратце: говорится о том, что в принципе любой хэш-алгоритм подвержен такому "взлому". Поэтому выходом может быть, например, разработка такого алгоритма, в котором вычисление MD занимает большее время и, соответственно, из-за этого перебор будет длиться дольше. Поэтому в результате "взломать", т.е. подобрать, становится сложнее =).
Но всё равно когда-нибудь любой алгоритм не выдержит такой брут-форс-атаки, и придётся внедрять новые алгоритмы
И это "the only way to stay ahead of the game"
)