note 95523 added to function.md5

I like this approach, based on the site below: function doublehash1($s){ $md5_hash=md5($s); $sha1_hash=sha1($s); return md5($md5_hash . $s . $sha1_hash); } function doublehash2($s){ $md5_hash=md5($s); $sha1_hash=sha1($s); return sha1($md5_hash . $s . $sha1_hash); } http://www.schneier.com/blog/archives/2005/02/sha1_broken.html "Having actually implemented both SHA-1 and MD5 in assembly (while I was in college, in a calculus class), the length of the actual data is appended to the last null-padded block. So, even small changes in the size have a significant impact on the final sum, and cannot be covered up by any blocks of data coming after it (except for man-in-the-middle, but that is useless in most situations). Other meta-data should be used as a signature, where it is included in the original data, outside the data, where it is hashed, and then both hashes are hashed (basically what PGP does). In the message "Hi, I'm Victor" there are 12 different characters. If only these 12 characters are allowed, there are 12**14 = 1283918464548864 or 1.28e+15 possibilities that could satisfy all the meta-data. The total possibilities for a SHA-1 sum is 2**160 ~= 1.46e+48. Using 1 bit as a flag for each sum would require 2**160 /8 ~= 1.83e+47 ~= 1.62e+32 PB (1PB= 1024*1TB= 1024*1024*1GB, I think) of storage. In the much reduced 12**14 number of possibilites, this would still require a minimum of 12**14 *20 ~= 2.57e+16 ~= 23,914,845 GB ~= 22.8 PB of storage, if each sum was unique (we cannot use the 1 bit mapping in this reduction). Using the techniques of this not yet published paper could reduce the storage requirement, but the only messages that could be proved to have a unique hash are those that are shorter in length than the hash. In the case of SHA-1, this is 20 bytes. Using the vulnerabilities to prove the authenticity of a short message is not yet too practical. A pretty secure hash method would be something like the following: fast: d1= hash1(message); d2= hash2(message); d3= hash1((message+d1)+d2); slow: d1= hash1(message); d2= hash2(message); d3= hash1((d1+message)+d2); The 2 hash functions MUST be different to a good degree (I believe SHA-1 and MD5 suffice, from my experience). The + operator is equivalent to appending the right operand onto the left, i.e. "a"+"b"="ab". d1, d2, and d3 are the message digests. All three digests MUST be distributed, along with what format the digests are in (hexadecimal or base64), along with what hash functions were used, along with the designation "slow" if the slow method is used ("fast" is default). The fast method could be computed fairly quickly by doing the 2 hashes on each block (making use of the processor cache), except for the final blocks. The slow method should be more secure, as only d1 and d2 could take advantage of the cache effect (d3 would have to be computed from scratch). Creating a collision on d1 and d2 would be pretty difficult, d3 would be much more. d1 and d2 MUST be hashes of only the original message, as hash2(mesage+d1) could make it easier to find a collision (as the effective message would then be different). I am not a cryptographer, but this scheme seems obviuosly much harder to crack for many reasons. As far as I know, this scheme is original, but is similar to PGP and 3DES. I think this is an obvious possible solution, and as such cannot be patented. Tell me what you think." ---- Server IP: 64.71.164.2 Probable Submitter: 63.249.115.87 ---- Manual Page -- http://www.php.net/manual/en/function.md5.php Edit -- https://master.php.net/note/edit/95523 Del: integrated -- https://master.php.net/note/delete/95523/integrated Del: useless -- https://master.php.net/note/delete/95523/useless Del: bad code -- https://master.php.net/note/delete/95523/bad+code Del: spam -- https://master.php.net/note/delete/95523/spam Del: non-english -- https://master.php.net/note/delete/95523/non-english Del: in docs -- https://master.php.net/note/delete/95523/in+docs Del: other reasons-- https://master.php.net/note/delete/95523 Reject -- https://master.php.net/note/reject/95523 Search -- https://master.php.net/manage/user-notes.php