Everything

php

PHP 5.1.0 - sha256() and sha256_file() support

php.internals

Stefan Esser

20 years ago

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
--------------------------------------------------------------------------

Ilia A.

20 years ago

Stefan,

There will be another RC, but I'd prefer to reserve this feature till
PHP 5.1.1.

Ilia

Jacques Marneweck

20 years ago

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/

Sebastian Nohn

20 years ago

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

Sara Golemon

20 years ago

>> with MD5 and SHA1 more or less broken
>>

Overstatement much?

>> I have hacked together sha256() and sha256_file(),
>>

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

Ilia A.

20 years ago

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

Stefan Esser

20 years ago

>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
--------------------------------------------------------------------------

William A. Rowe, Jr.

20 years ago

Sara Golemon wrote:

>>>with MD5 and SHA1 more or less broken
>
> 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.

Jochem Maas

20 years ago

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?

Stefan Esser

20 years ago

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

Ron Korving

20 years ago

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" <sesser@php.net> wrote in message
news:437B0C46.3080809@php.net...

Ilia A.

20 years ago

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

Ron Korving

20 years ago

"Ilia Alshanetsky" <ilia@prohost.org> wrote in message
news:437B7B73.602@prohost.org...

> 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

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

Sara Golemon

20 years ago

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

Jacques Marneweck

20 years ago

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/

Sara Golemon

20 years ago

> > Right, so bottom line, MD5 is showing signs of fatigue.  Not "broken" or
> > even significantly weak when used properly
> >
> 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

Roman Ivanov

20 years ago

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

Ants Aasma

20 years ago

Roman Ivanov wrote:

> 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
>

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