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 Michael M Slusarz <[email protected]>: > >> Quoting Jan Schneider <[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. >> >> 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. > > To elaborate: still not seeing the use-case for a generic > "best-available" hashing class. Simply because there are a bunch of > variables -- length, cryptographic-strength, existing hash type -- > that go into this determination that are not easily abstracted. > > Maybe if you had a more elaborate Base class/driver system that took > into account hash length and/or current hash preference. But having > a generic hash method that you pass in a string and get a value out > is not useful IMHO. And at this point, the overhead is destroying > the usefulness. > > Maybe a method that lists acceptable hash formats by key size would > be useful. But in the end, the calling code still needs to > explicitly make decisions about its hashing use case. > > Compare this with Horde_Pack where the output string is ALWAYS > useable (at least if you don't remove PHP features) since it > contains the compression/serialization format embedded in the > output, and the output is not expected to conform to a given length. Comparison with Horde_Pack is actually a good idea. Obviously such a hashing method/class cannot be used where hashes must persist and being recreated/rechecked on a regular basis. In any other cases, like cache keys, the worst can happen if the hashing method changes, is that a cache is invalidated and needs to be propagated again. For in-session hashes, worst case is users having to re-authenticate. Both is true if Horde_Pack is using a different method too, as long as Horde_Pack is used under such circumstances at all. Storing the pack method doesn't help if the packing extension is removed for some reason. Length shouldn't be a problem either as client has to intentionally opt into using this hash method and can adapt storage fields accordingly. I'm not strongly advocating for creating such a method, but seeing a lot of identical or similar PHP version comparisons sounds like screaming for some abstraction/shortcut. Just thinking. -- 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]