This research obviously demonstrates the importance of <a href="http://en.wikipedia.org/wiki/Nothing_up_my_sleeve_number" rel="nofollow">http://en.wikipedia.org/wiki/Nothing_up_my_sleeve_number</a> This is why the SHA-1 round constants were chosen from a simple operation (square root) on a series of nondescript numbers:<p><pre><code> √2 = 0x5A827999
√3 = 0x6ED9EBA1
√5 = 0x8F1BBCDC
√10 = 0xCA62C1D6
$ python -c 'for i in (2,3,5,10): print hex(int(i**.5*2**30))'
0x5a827999
0x6ed9eba1
0x8f1bbcdc
0xca62c1d6
</code></pre>
However, it is a little bit strange that the designers chose √10 instead of √7 which would be the next logical number. Think about how many sets of constants can be generated in a nondescript way: for example they could have replaced √/2,3,5,10 with cos()/1,2,3,4, or sin()/2,4,8,16, etc. If there are, say, a million ways to generate sets of constants "above suspicion", but if 1 in a million exhibits a flaw, then in theory they could have carefully selected the one that introduces a flaw in SHA-1. (Personally I do not think it was malicious selected, but it is a fun thought experiment...)
<p><pre><code> We also build colliding JPEG files, which can be any two
images, as in the example below (images were chosen at
random): https://malicioussha1.github.io/img/collision.png
</code></pre>
Haha. Brilliant. Almost RdRand-om!
Sooo... does this leave the door open for the possibility of SHA1 to be backdoored like this? The FAQ says it's only "unlikely" by assuming NIST didn't have the skills to pull it off?
I've never heard of proprietary systems "customizing" SHA-1 "…to personalize the cryptography for a given customer, while retaining the security guarantees of the original algorithm".<p>Are there any examples, prominent or obscure?<p>(Who the hell would buy something with "SHA-1, but different"?)