PHP 5.1.0 - sha256() and sha256_file() support

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/

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

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

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.

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