A public service announcement

[gene]

It's not my job to hand-feed you. I provided some initial references, and now it is up to you to explain why your method is superior. You have not.

The reasons why eksblowfish is several orders of magnitude harder to bruteforce that other algos (like SHA, or N interations of hash-x) have little to do with iterations. It is because hashes were never designed to encrypt passwords, despite what theymos may think. They are, in part, designed to be fast. This is the opposite of what you want when protecting from password cracking (slow).

from http://www.skein-hash.info/about :

The Skein Hash Function Family
Fast, Secure, Simple, Flexible, Efficient. And it rhymes with "rain."

[...]

Skein is fast. Skein-512—our primary proposal—hashes data at 6.1 clock cycles per byte on a 64-bit CPU. This means that on a 3.1 GHz x64 Core 2 Duo CPU, Skein hashes data at 500 MBytes/second per core—almost twice as fast as SHA-512 and three times faster than SHA-256. An optional hash-tree mode speeds up parallelizable implementations even more. Skein is fast for short messages, too; Skein-512 hashes short messages in about 1000 clock cycles.

The references explain why eksblowfish is so good at being slow. But go ahead... keep "daring" me to explain (the references that I posted in this thread do an ample job, for those who are interested). I will admit that your taunts amuse me, however.

The post of yours that I linked is salient because it demonstrates your level of understanding of security issues. You seem to think that just by nesting questionable mechanisms N times, that you have achieved some sort of a secure cascade effect. This is demonstrably untrue in your "methods," as FalconFour described. It may help others decide wether or not to trust your scheme if they know what other schemes you have proposed on these very fora.

Also, the burden of proof rests on the person who presents new methods. You.

Bcrypt is the best tool to protect password databases against offline attacks.

[gene]

The "strength" of the hashing is irrelevant (even an 80-bit hash function - used properly - cannot be bruteforced by the current bitcoin network in any reasonable time). The only thing that matters is how long it takes to try one key for an attacker. bcrypt and whatever iterated hashing you're using achieve this in a very different way, and it is hard to compare.

It is true by the way that iterated hashing increases the chances for collisions, but only slightly. As explained in an earlier linked post, NIST recommends PBKDF2 for storing passwords, which is in fact based on salted iterated hashing.

So please stop throwing insults to eachother. Yes, bcrypt() is a very good way for storing passwords, but so it a (well implemented) iterated hashing scheme. Iterated hashing schemes are better researched and used, but bcrypt() is somewhat slower to implement in hardware. If you really want maximal resistance to hardware-assisted attacks, scrypt() may be an even better choice, yet even more recent.

Scrypt looks good, and if I were a bit less conservative with these issues, I would use it. The only thing is that it hasn't been around for as long, so maybe not quite as much peer review and bcrypt. I'm not sure if I trust the implementations out there yet. The CYA types love PBKDF2 because it meets all "industry standards," and that is ok, I suppose. After all, everything out of RSA® (The Security Division of EMC Corp.) has been bulletproof, right? 

[ShadowOfHarbringer]

The reasons why eksblowfish is several orders of magnitude harder to bruteforce that other algos (like SHA, or N interations of hash-x) have little to do with iterations.

Let me quote something for you:

Provos and Mazières took advantage of this, and actually took it further. They developed a new key setup algorithm for Blowfish, dubbing the resulting cipher "Eksblowfish" ("expensive key schedule Blowfish"). The key setup begins with a modified form of the standard Blowfish key setup, in which both the salt and password are used to set all subkeys. Then there are a number of rounds in which the standard Blowfish keying algorithm is applied, using alternately the salt and the password as the key, each round starting with the subkey state from the previous round. This is not cryptographically significantly stronger than the standard Blowfish key schedule, but the number of rekeying rounds is configurable; the hashing process can therefore be made arbitrarily slow, which helps deter brute-force attacks upon the hash or salt.

As you are an insolent fool, which doesn't understand a thing about hashing algorithms and you failed to explain how bcrypt actually works, let me explain you in my own words what this description means.

Roughly the eksblowfish is all about creating multiple keys, of which each is mixed with salt, and then each of the keys is applied in each of multiple rounds of the algorithm. Each next (n+1) round begins in mixing the key with salt and applying it to the previous (n) round through encryption. In other words, bcrypt() is simply a recurrent hashing algorithm, where each consecutive round of hashing begins with adding the salt to the result of previous round.

Exactly as the algorithm which I have written.

The references explain why eksblowfish is so good at being slow. But go ahead... keep "daring" me to explain (the references that I posted in this thread do an ample job, for those who are interested). I will admit that your taunts amuse me, however.

You are still a fool, and you have explained nothing. What you have done is a copypasta work from other sites. You haven't actually described in your own words how the algorithms work.

The post of yours that I linked is salient because it demonstrates your level of understanding of security issues. You seem to think that just by nesting questionable mechanisms N times, that you have achieved some sort of a secure cascade effect

1. Learn to read first, before you start talking to me. I have never ever in any post said anything about any "cascade effect".
2. STOP MANIPULATING!. STOP making offtopic so it makes you look smarter than you actually are. You are weak, and you are using cheap tricks of the weak. This will not work with me.

It's not my job to hand-feed you.

It is your job to provide valid logical arguments since you started this stupid discussion. You have failed to do so.

Bcrypt is the best tool to protect password databases against offline attacks.

Actually, i personally think about incorporating bcrypt() into my algo for greater performance, but i will be continuing this discussion just to prove how stupid, impudent and manipulative you are.