On Thu, May 23, 2002 at 07:35:12AM -0400, Steven M. Bellovin wrote:
> In my opinion, there's no technical reason to do it.  If you want to 
> add a new scheme, SHA512 would be a much better choice.  The only 
> reason I can see is password file compatibility with OpenBSD.

That is the main reason it seems like a useful idea to me, and while my
knowledge on the subject isn't by any means authoritative, blowfish-hashed
passwords are slower to crack than MD5. (My tests with John the ripper
confirm that an i386 system gets much less crypts/sec doing blowfish than
MD5 or DES)

> First, passwords are not "encrypted", they're *hashed*.  That is, 
> encryption has the property that it's reversible; one can go from the 
> ciphertext to the plaintext.  The password scheme is by intent 
> irreversible (see the Morris and Thompson paper in the November 1979 
> issue of CACM -- which, come to think of it, might be in the 
> newly-freed Unix documents) for more details on the design.

I am quite aware of that, and if you look at my original message, I never
made the claim that passwords were "encrypted" rather than hashed.

> To achieve that, the DES-based scheme uses the password as the key when 
> encrypting a known value -- ciphers are designed to resist recovery of 
> the key.  But that's what limited people to 8-character passwords -- 
> that was the key length.  Blowfish can do better, of course, but 
> there's really no point -- SHA512 is almost certainly as strong 
> cryptographically, and has no limit on input size.  SHA512 *is* a 
> secure hash function, which is what the current scheme is trying to 
> emulate (secure hash functions didn't exist in 1979; they'd just barely 
> been speculated on).

No argument here.

> If SHA512 falls to a cryptanalytic attack, all of our other 
> cryptographic hash functions (including MD5) will almost certainly fall 
> as well; they're based on the same principles.  But such attacks are 
> almost certainly much harder than the real weak point of passwords:  
> guessability.
> 
> As I recall, Blowfish uses 64-bit blocks.  That alone is reason enough 
> to use SHA512, which uses 512-bit blocks:  there's less chance of a 
> random collision (not that you'll see either collide).
> 
> (The only technical reason to even think about Blowfish is because its 
> key setup operation is slow.  But you can achieve the same goal by 
> iterating SHA512 enough times.  Frankly, I don't know which is slower, 
> a single SHA512 or a single Blowfish setup/encrypt operation.)

I am willing to consider adding SHA512 support instead of blowfish. Where
can I find some information on the algorithm and (if possible) source code
implementing it?

> 		--Steve Bellovin, http://www.research.att.com/~smb (me)
> 		http://www.wilyhacker.com ("Firewalls" book)
> 
> 

-- 
/~\ The ASCII                         Sean Davis
\ / Ribbon Campaign                    aka dive
 X  Against HTML
/ \ Email!                   http://endersgame.net/~dive/