[dev] [commits] Horde branch master updated. 0ab877c762ed591254793fdeb8840a27087b0c5e

[Jan Schneider]

Zitat von Michael M Slusarz <slusarz at horde.org>:

> Quoting Jan Schneider <jan at horde.org>:
>
>> Zitat von Michael M Slusarz <slusarz at horde.org>:
>>
>>> Quoting Michael M Slusarz <slusarz at horde.org>:
>>>
>>>> commit 2d91444b8cb4a63a67355fcd3eb28af6b497b4c0
>>>> Author: Michael M Slusarz <slusarz at horde.org>
>>>> 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 [slusarz at horde.org]


-- 
Jan Schneider
The Horde Project
http://www.horde.org/
https://www.facebook.com/hordeproject