Malicious SHA-1

This research obviously demonstrates the importance of <a href="http://en.wikipedia.org/wiki/Nothing_up_my_sleeve_number" rel="nofollow">http:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;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 &#x27;for i in (2,3,5,10): print hex(int(i**.5*2**30))&#x27; 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 √&#x2F;2,3,5,10 with cos()&#x2F;1,2,3,4, or sin()&#x2F;2,4,8,16, etc. If there are, say, a million ways to generate sets of constants &quot;above suspicion&quot;, 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:&#x2F;&#x2F;malicioussha1.github.io&#x2F;img&#x2F;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&#x27;s only &quot;unlikely&quot; by assuming NIST didn&#x27;t have the skills to pull it off?

I&#x27;ve never heard of proprietary systems &quot;customizing&quot; SHA-1 &quot;…to personalize the cryptography for a given customer, while retaining the security guarantees of the original algorithm&quot;.<p>Are there any examples, prominent or obscure?<p>(Who the hell would buy something with &quot;SHA-1, but different&quot;?)