[security] SHA-1 is shattered, but I have a question

Joshua Marsh joshua at themarshians.com
Thu Feb 23 11:37:02 MST 2017

On Thu, Feb 23, 2017 at 10:13 AM AJ ONeal (Home) <coolaj86 at gmail.com> wrote:

> It seems that over time we decide that the best way to make things more
> secure is just to come up with algorithms that need more and more bit
> entropy and more and more CPU processing power which seems like a false
> solution.

It generally works well. Crypto has a bit of statistics baked into it and
we recognize that most of what we are doing has a limited span of usability
before we need to move on. We used SHA1 for a while because it was highly
unlikely for anyone to force a collision for malicious purposes. We knew
it's time was coming though and that's why certs have been moving away from

Remember that the goal of crypto is to make it extremely unlikely that
someone can get your plain text (or in the case of a hash, cause a
collision). It's entirely possible that someone could guess your key on the
first try and get your data. Increasing the key size makes it harder and we
do it because there isn't a lot of known better ways to do it without
greatly reducing usability and performance.

> If 128-bits of entropy is enough entropy, why don't we just come up with
> algorithms that can handle 128-bits of entropy better?

We do use other algorithms. For example, the elliptic curve algorithms are
provably harder to solve than the traditional factorization algorithms and
therefore we can use smaller key sizes. There are dozens of hash algorithms
as well. We stick to industry standards because they are generally more
proven and better implemented. As they age, we move onto new ones or bigger
key sizes.

> Furthermore, instead of moving to algorithms in which flaws will also
> eventually be found that increase the CPU, memory, and storage requirements
> so drastically (there's a HUGE difference between MD5 and SHA-256 when
> you're computing on a phone or a raspberry pi), why don't we just pair to
> imperfect algorithms together?

This is a common notion but is often bemoaned in crypto courses. It usually
doesn't work well. It can get really mathy in these courses, especially at
the graduate level. The gist of it though is that the security of combining
two algorithms is usually not the sum of their parts.

We also use new algorithms for other reasons besides just security. SHA3 is
much faster than SHA2 and has similar security. Additionally newer
algorithms are often provably more resistant to attacks that reduce their

That's not to say the SHA3 will be the end-all cryptographic hash. It's
possible that an exploit will be found and reduce it's effectiveness. NIST
started looking for SHA3 because they thought SHA2 was broken. That ended
up not being the case but the longer the algorithms are out there and the
more research is done on them, the more vulnerable they become (another
reason not to combine algorithms).

Finally, I'll add that while its not generally done at a high level (e.g.
MD5+SHA1), the internal workings of crypto functions are sometimes
amalgamations from past functions with new twists. So in a sense we sort of
do what you are talking about already, the author or NIST just gives it a
new name.

More information about the PLUG mailing list