# PHP 5.1.0 - sha256() and sha256_file() support - Thread: https://externals.io/message/20034 - Original archive: https://news-web.php.net/php.internals/20034 - Started by Stefan Esser on 2005-11-15T22:11:43+00:00 - Messages: 18 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #20034 — Stefan Esser — 2005-11-15T22:11:43+00:00 URL: https://externals.io/message/20034#20034 Hello, with MD5 and SHA1 more or less broken, I have hacked together sha256() and sha256_file(), because people want a secure hashing function in plain PHP without the need for 3rd party libraries like mhash. Both functions are already available to users of the PHP Hardening-Patch for quite a while. Actually it is too late in the release process to add it, although it just adds new files and only adds a few things in some tables. It is more or less impossible to break something but you never know. If we for some reasons need another 5.1.0 RC, we can maybe add the patch. (It doesn't need more than a few compile tests ;) Patch: http://www.suspekt.org/php-5.1.0-sha256.patch (So ilia... It is maybe up to your judgement only if I should do a last minute feature commit ;) Stefan -- -------------------------------------------------------------------------- Stefan Esser sesser@php.net Hardened-PHP Project http://www.hardened-php.net/ GPG-Key gpg --keyserver pgp.mit.edu --recv-key 0x15ABDA78 Key fingerprint 7806 58C8 CFA8 CE4A 1C2C 57DD 4AE1 795E 15AB DA78 --- ## #20037 — Ilia Alshanetsky — 2005-11-16T00:04:33+00:00 URL: https://externals.io/message/20034#20037 · In reply to: #20034 Stefan, There will be another RC, but I'd prefer to reserve this feature till PHP 5.1.1. Ilia --- ## #20043 — Sara Golemon — 2005-11-16T01:30:46+00:00 URL: https://externals.io/message/20034#20043 · In reply to: #20034 > > […] Overstatement much? > > […] The more the merrier I say... > There will be another RC, but I'd prefer to reserve > this feature till PHP 5.1.1. > I've had implementations of sha256,384, and 512 lying about for months now (possibly over a year), but was told they didn't have a place in core since mhash provided the functionality (A statement I recall agreeing with at the time fwiw). What changed? -Sara --- ## #20045 — Ilia Alshanetsky — 2005-11-16T01:38:08+00:00 URL: https://externals.io/message/20034#20045 · In reply to: #20043 Sara Golemon wrote: > I've had implementations of sha256,384, and 512 lying about for months now > (possibly over a year), but was told they didn't have a place in core since > mhash provided the functionality (A statement I recall agreeing with at the > time fwiw). What changed? Didn't you hear md5/sha1 are cracked in seconds by evil governments and corporations, put on your tin foil hat TODAY! I think the issue is that mhash is a relatively rare extension due to a dependency on a library that is rarely available. I think that perhaps for 6.0 we need to look into a php extension that could provide some commonly used hashes without any decencies. Ilia --- ## #20046 — Stefan Esser — 2005-11-16T01:43:42+00:00 URL: https://externals.io/message/20034#20046 · In reply to: #20043 >I've had implementations of sha256,384, and 512 lying about for months now >(possibly over a year), but was told they didn't have a place in core since >mhash provided the functionality (A statement I recall agreeing with at the >time fwiw). What changed? > > Since a year a lot of things have changed. The progress in md5 and sha1 collision generation have been huge. And it is really not needed to have every single hash function in core because then you can really use mhash, but we should have atleast one in the core, that is fit enough to survive the next months/years. Otherwise the majority of people will not have access to it, because their hoster does not provide mhash. (and many big open source PHP project simply don't use functions that are not in the core) Stefan -- -------------------------------------------------------------------------- Stefan Esser sesser@php.net Hardened-PHP Project http://www.hardened-php.net/ GPG-Key gpg --keyserver pgp.mit.edu --recv-key 0x15ABDA78 Key fingerprint 7806 58C8 CFA8 CE4A 1C2C 57DD 4AE1 795E 15AB DA78 --- ## #20048 — William A. Rowe — 2005-11-16T02:15:35+00:00 URL: https://externals.io/message/20034#20048 · In reply to: #20043 Sara Golemon wrote: > > […] > > Overstatement much? > > I've had implementations of sha256,384, and 512 lying about for months now > (possibly over a year), but was told they didn't have a place in core since > mhash provided the functionality (A statement I recall agreeing with at the > time fwiw). What changed? One consideration, if one wanted to deploy PHP in a FIPS compliant manner, is that reimplementations of these algorithms is not acceptable. One clean solution if linked against OpenSSL is to dispatch sha256/384/512 to those certified algorithms. But in any case, all three certainly make sense. Adding sha256 alone sure seems like a false start. --- ## #20060 — Jochem Maas — 2005-11-16T10:24:08+00:00 URL: https://externals.io/message/20034#20060 · In reply to: #20034 Stefan Esser wrote: > Hello, > > with MD5 and SHA1 more or less broken, I have hacked together sha256() and sha256_file(), > because people want a secure hashing function in plain PHP without the need for 3rd party > libraries like mhash. assuming this is true then the built in session handler is pretty vulnerable right now no? one only has the choice of md5 or sha1 for the hashing mechanism of the session handlers id as far as I can see ... if php gets a sha256 in the core it would possibly be a good thing to make that available as an option for session.hash_function? > > Both functions are already available to users of the PHP Hardening-Patch for quite a while. > Actually it is too late in the release process to add it, although it just adds new files > and only adds a few things in some tables. It is more or less impossible to break something > but you never know. > > If we for some reasons need another 5.1.0 RC, we can maybe add the patch. (It doesn't need > more than a few compile tests ;) > > Patch: http://www.suspekt.org/php-5.1.0-sha256.patch > > (So ilia... It is maybe up to your judgement only if I should do a last minute feature commit ;) > > Stefan --- ## #20061 — Stefan Esser — 2005-11-16T10:39:02+00:00 URL: https://externals.io/message/20034#20061 · In reply to: #20060 Hello, > assuming this is true then the built in session handler is pretty > vulnerable right now no? > one only has the choice of md5 or sha1 for the hashing mechanism of > the session handlers id > as far as I can see ... if php gets a sha256 in the core it would > possibly be a good thing > to make that available as an option for session.hash_function? I did not want to cause some "panic". MD5 and SHA1 are not completely broken yet. I think people usually only call a hash function completely broken when preimage attacks are possible. This means for a given startvector you can create some input to get a desired endvector. During the last year there have been various reports about much faster attacks in normal collision generation, which means the time needed to you just try to find 2 collisions. (you never know how fast it will be possible in 1 year from now) The session handler on the other hand is not really vulnerable to this, even if there are preimage attacks. In the session handler MD5/SHA1 are merely used to convert a random number into some other format. Even if there are preimage attacks on MD5 and SHA1 the "security" of the session handler relies on not guessable random numbers. (However it would not be much work to use sha256 in the session extension as another option once it is in core) Stefan --- ## #20071 — Ron Korving — 2005-11-16T18:21:19+00:00 URL: https://externals.io/message/20034#20071 · In reply to: #20061 I just read this news that an MD5 collision can now be done by anyone in 45 minutes (avg) on a P4 1.6 GHz: http://it.slashdot.org/article.pl?sid=05/11/15/2037232&threshold=-1&tid=172&tid=93&tid=228 http://www.stachliu.com.nyud.net:8090/collisions.html MD5 as the standard for hashing is definately history. All the more reason for sha256- and alike-functions. Ron "Stefan Esser" wrote in message news:437B0C46.3080809@php.net... > Hello, > > > […] > > I did not want to cause some "panic". MD5 and SHA1 are not completely > broken yet. I think people usually only call a hash function completely > broken when preimage attacks are possible. This means for a given > startvector you can create some input to get a desired endvector. During > the last year there have been various reports about much faster attacks > in normal collision generation, which means the time needed to you just > try to find 2 collisions. (you never know how fast it will be possible > in 1 year from now) > > The session handler on the other hand is not really vulnerable to this, > even if there are preimage attacks. In the session handler MD5/SHA1 are > merely used to convert a random number into some other format. Even if > there are preimage attacks on MD5 and SHA1 the "security" of the session > handler relies on not guessable random numbers. > (However it would not be much work to use sha256 in the session > extension as another option once it is in core) > > Stefan --- ## #20072 — Ilia Alshanetsky — 2005-11-16T18:33:23+00:00 URL: https://externals.io/message/20034#20072 · In reply to: #20071 Ron Korving wrote: > I just read this news that an MD5 collision can now be done by anyone in 45 > minutes (avg) on a P4 1.6 GHz: > http://it.slashdot.org/article.pl?sid=05/11/15/2037232&threshold=-1&tid=172&tid=93&tid=228 > http://www.stachliu.com.nyud.net:8090/collisions.html > > MD5 as the standard for hashing is definately history. All the more reason > for sha256- and alike-functions. If you've read the article closely you'll know that while an impressive trick, collisions cannot be generated arbitrarily. The program generates both of the values that result in the same md5 hash . You cannot give it an md5 and have it generate you a string with the same md5 hash, so md5 is still relatively safe. Ilia --- ## #20073 — Ron Korving — 2005-11-16T18:37:02+00:00 URL: https://externals.io/message/20034#20073 · In reply to: #20072 "Ilia Alshanetsky" wrote in message news:437B7B73.602@prohost.org... > Ron Korving wrote: > > […] 45 > > […] http://it.slashdot.org/article.pl?sid=05/11/15/2037232&threshold=-1&tid=172&tid=93&tid=228 > > […] reason > > […] > > If you've read the article closely you'll know that while an impressive > trick, collisions cannot be generated arbitrarily. The program generates > both of the values that result in the same md5 hash . You cannot give it > an md5 and have it generate you a string with the same md5 hash, so md5 > is still relatively safe. > > Ilia Perhaps... for now... I'm no crypto expert and don't aim to be one, but when I read the /. responses, a lot of people find MD5 dead and gone. Even if they're wrong, the public will expect functions in PHP to replace the md5 functions. Just my 2 cents, I'm not even trying to start an argument here ;) Ron --- ## #20076 — Sara Golemon — 2005-11-16T19:03:35+00:00 URL: https://externals.io/message/20034#20076 · In reply to: #20073 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 --- ## #20085 — Jacques Marneweck — 2005-11-16T23:05:13+00:00 URL: https://externals.io/message/20034#20085 · In reply to: #20037 Ilia Alshanetsky wrote: > Stefan, > > There will be another RC, but I'd prefer to reserve this feature till > PHP 5.1.1. > > Ilia > Hi Guys, Are there any chances of getting this implemented in the next releases of PHP 5.0.X and 4.4.X? Regards --jm -- Jacques Marneweck http://www.powertrip.co.za/blog/ --- ## #20086 — Jacques Marneweck — 2005-11-16T23:45:58+00:00 URL: https://externals.io/message/20034#20086 · In reply to: #20076 Sara Golemon wrote: > 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. > Also there are sites hosting md5 hashes and the equivalent text for password cracking. > 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. > lol > Where the hell was I? Oh yeah... +1 on tossin' in sha256() and > sha256_file(). > +1 *snip* > 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). > Might be useful to squeeze it into 5.1.0, seeing that new features are normally not allowed to sneak in during a maintenance release? Regards --jm > -Sara > -- Jacques Marneweck http://www.powertrip.co.za/blog/ --- ## #20087 — Sara Golemon — 2005-11-17T00:28:49+00:00 URL: https://externals.io/message/20034#20087 · In reply to: #20086 > > […] > Also there are sites hosting md5 hashes and the equivalent text for > password cracking. > This is exactly what I meant by "used properly" the problem you're describing becomes significantly less prone to cracking attempts when simply paired with a key. -Sara --- ## #20099 — Sebastian Nohn — 2005-11-17T07:33:08+00:00 URL: https://externals.io/message/20034#20099 · In reply to: #20085 Jacques Marneweck wrote: > Are there any chances of getting this implemented in the next releases > of PHP 5.0.X and 4.4.X? I don't think there will be any further 5.0.x release. Sebastian --- ## #20100 — Roman Ivanov — 2005-11-17T21:02:34+00:00 URL: https://externals.io/message/20034#20100 · In reply to: #20072 Ilia Alshanetsky wrote: > You cannot give it > an md5 and have it generate you a string with the same md5 hash, so md5 > is still relatively safe. http://www.google.com/search?q=md5+hash+lookup&start=0&start=0&ie=utf-8&oe=utf-8&client=firefox-a&rls=org.mozilla:en-US:official --- ## #20138 — Ants Aasma — 2005-11-18T09:13:00+00:00 URL: https://externals.io/message/20034#20138 · In reply to: #20100 Roman Ivanov wrote: > Ilia Alshanetsky wrote: > > > […] > > > http://www.google.com/search?q=md5+hash+lookup&start=0&start=0&ie=utf-8&oe=utf-8&client=firefox-a&rls=org.mozilla:en-US:official > I'd take that link with a grain of salt. :) Dictionary attack is dangerous regardless of which hash function you use. That is when you don't use a salt. But md5 safeness depends on the purpose. It's use as a one way function hasn't been compromised (yet), but the ability to generate collisions means that it cannot be used to generate a fingerprint to detect malicious tampering. In my country we have legally binding digital signatures that currently use sha-1 to generate the fingerprint to sign and the weakening of sha-1's collision generation resistance is a bit unnerving. Fortunately the attacks are still too expensive to be useful, but I'm currently lobbying to have better hashes implemented. It would be nice to have the default PHP install be able to atleast verifiy digitally signed files. Ants Aasma