We believe this is unlikely, for
- Our results rely on state-of-the-art differential cryptanalysis research, as of 2014, based on techniques that were only publicly developed since around 2004"
I'm not a cryptographer but I wonder how they truly can believe that's unlikely since it's entirely possible for the NSA to be 10 years ahead of what was "publicly developed".
Frankly, that's also the most plausible situation independent of what we've learned anyway - it would be fantastically hard to advance technology by ten years entirely in secret. They wouldn't have the benefit of any of the literature released in those 10 years. All their computers and other equipment would be 10 years older, and the sheer number of cryptographers working on these sorts of things at the NSA is almost certainly much smaller than the number working on them outside of these contexts. It would be pretty difficult to pull off, particularly since they can get away with just cheating.
There are however known issues with real SHA1 which is why it's not recommended for future development.
http://blogs.technet.com/b/srd/archive/2013/11/12/security-a...
Are there any examples, prominent or obscure?
(Who the hell would buy something with "SHA-1, but different"?)
As for why? Intentional incompatibility with the standard hash usually, often as security-by-obscurity or to lock users into using their products.
I've personally worked with NIH SSL systems based on the idea of XOR'ing the messages with the 3rd byte of a header field called 'CryptoKey' or something like that. There are all sorts of homebrew crypto systems out there in the wild, if you're lucky it's based on an actual algorithm, but mostly it's worst than an enigma machine.
In the case of the system I was working with the 3rd byte of the message was always a : so I ditched the whole look at the header thing, and just XOR'd the 3rd byte with : to derived the 'key'.
√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
One example of this is the BADA55 curves[0]:
> The name "BADA55" (pronounced "bad-ass") is explained by the appearance of the string BADA55 near the beginning of each BADA55 curve. This string is underlined in the Sage scripts above
> We actually chose this string in advance and then manipulated the curve choices to produce this string. The BADA55-VR curves illustrate the fact that, as pointed out by Scott in 1999, "verifiably random" curves do not stop the attacker from generating a curve with a one-in-a-million weakness. The BADA55-VPR curves illustrate the fact that "verifiably pseudorandom" curves with "systematic" seeds generated from "nothing-up-my-sleeve numbers" also do not stop the attacker from generating a curve with a one-in-a-million weakness.
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