Re: [commits] Horde branch master updated. 0ab877c762ed591254793fdeb8840a27087b0c5e
Jan Schneider <[email protected]>
| Newsgroups | gmane.comp.horde.devel |
|---|---|
| Message-ID | <[email protected]> |
Zitat von Michael M Slusarz <[email protected]>: > Quoting Jan Schneider <[email protected]>: > >> Zitat von Michael M Slusarz <[email protected]>: >> >>> Quoting Michael M Slusarz <[email protected]>: >>> >>>> commit 2d91444b8cb4a63a67355fcd3eb28af6b497b4c0 >>>> Author: Michael M Slusarz <[email protected]> >>>> Date: Wed Mar 12 02:27:59 2014 -0600 >>>> >>>> Another place to change hash algorithm >>>> >>>> framework/Imap_Client/lib/Horde/Imap/Client/Base.php | 5 ++++- >>>> 1 files changed, 4 insertions(+), 1 deletions(-) >>>> >>>> http://github.com/horde/horde/commit/2d91444b8cb4a63a67355fcd3eb28af6b497b4c0 >>>> http://git.horde.org/horde-git/-/commit/2d91444b8cb4a63a67355fcd3eb28af6b497b4c0 >>> >>> I have mentioned this before in commit messages ... but MD5 has >>> been proven to be inadequate for hashing purposes due to collision >>> issues. >>> >>> See, e.g.: >>> >>> http://www.mscs.dal.ca/~selinger/md5collision/ >>> >>> I've personally changed code to use either SHA-1 (unfortunately >>> much slower than MD5, and larger output, but collision resistant >>> and should always be available in PHP) or FNV-1(32 bit) (only >>> available on PHP 5.4+, faster than MD5, designed specifically as >>> non-crpytographic hash, low collision rate). >>> >>> Would be better to use FNV-1a than FNV-1, but due to oversight >>> this was left out of hash() and my patch to add won't show up >>> until PHP 5.6. Even better would be xxhash, but this would >>> require the installation of a PHP module. >> >> We should wrap and abstract this into a Horde_Util method, so the >> best hashing method available will always be used. > > Sure, but what is the use-case? All the places where you already added a PHP version check. > For things like caching it is not very useful since this leads to > the potential that hashes may change without warning. That could > cause issues with cache expiration (i.e. avalanche effect when > rebuilding caches all at once). > > Also, there is no guarantee of hash length. Normalizing hash > length, at least truncating, potentially destroys collision > resistance. Lengthening is just wasting space for hashes with > lesser length. > > michael > > ___________________________________ > Michael Slusarz [[email protected]] -- Jan Schneider The Horde Project http://www.horde.org/ https://www.facebook.com/hordeproject -- dev mailing list Frequently Asked Questions: http://wiki.horde.org/FAQ To unsubscribe, mail: [email protected]