Right, so bottom line, MD5 is showing signs of fatigue. Not "broken" or even significantly weak when used properly, but she's in the twlight years and it's time to send ma to the old folks home for some rest and green jello.
SHA1 isn't quite the matriach yet, but despite having miles to go before she sleeps, it is prudent to bring along the next generation so they can pay the medical bills when a bout of breast cancer stikes her out of the blue. Where the hell was I? Oh yeah... +1 on tossin' in sha256() and sha256_file(). As for sha384 and sha512, I've got two reservations about making them core functions: (1) Illusion of security. The advantage of 384 or 512 bits over 256 is (based on current computing resources) negligible. I'd hate to have people going sha512 over sha256 simply because they think it'll make their app "impossible to craxx0r!" (2) Speed. This is tied into #1 since those same people going sha512() because they think it's "better" are, in all liklihood, working on 32bit procs which are fundamentally slower at handling sha384/sha512 which use 64bit registers internally. Of course, these reservations are just about dulling down the scissor edges for little Sammy Scripter who doesn't know any better. If I'm going to avoid being hypocritcal then I have to toss out those arguments at the end of the day and say I'm +0 on 'em. That is, if there's a strong push to include them, I'll dig out my 384/512 implementations (which are straight math, no library deps) and toss 'em in with Steffan's sha256(), but only for PHP 6.0 (or PHP 5.1.1 if the RM feels that's appropriate). -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
