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

[Michael M Slusarz]

Quoting Jan Schneider <jan at horde.org>:

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

This doesn't address the 2nd issue below (and doesn't address the 1st  
issue either if you are not upgrading PHP major versions).

So still not seeing the use-case.

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