In 2020, SHA-1 practically broken in chosen-prefix collision (CP-collision). Can double SHA-1 hashing prevent CP-collision?

Question

In a recent study SHA-1 is a Shambles - First Chosen-Prefix Collision on SHA-1 and Application to the PGP Web of Trust by Gaëtan Leurent and Thomas Peyrin. 2020, they showed the first practical chosen-prefix collision attack that required two months of computations using 900 Nvidia GTX 1060 GPUs.

Chosen-prefix collision (CP- collision)¹: two message prefixes $P$ and $P'$ are first given as challenge to the adversary, and his goal is to compute two messages $M$ and $M'$ such that $H(P \mathbin\| M) = H(P' \mathbin\| M')$ where $\mathbin\|$ denotes concatenation.

They worked for two kinds of attacks;

They reduced the use of neutral bits BCJ+05 and boomerangs JP07 from $2^{64.7}$ to $2^{61.2}$
Also, they improved graph-based technique (LP19) to compute CP-collision from $2^{67.1}$ to $2^{63.4}$.

Actually, the CP-collision attack enables attackers to create some meaningful messages; however, classical collisions are not.

To demonstrate the attack they achieved a PGP/GnuPG impersonation (CVE-2019-14855).

The list of attacks on SHA-1

2005, collision with complexity $2^{69}$, Finding collisions in the full SHA-1, Wang et. al.
2013, chosen-prefix collision with complexity $2^{77.1}$, New collision attacks on SHA-1 based on optimal joint local-collision analysis, Stevens et. al.
2013, collision with complexity $2^{64.7}$, from the previous article.
2016, free-start collision with complexity $2^{57.5}$, Freestart collision for full SHA-1. Stevens et. al.
2017, collision with complexity $2^{63.1}$, The first collision for full SHA-1., Steven et. al.
2019, chosen-prefix collision with $2^{67.1}$ complexity, From collisions to chosen-prefix collisions, Leurent et.al. application to full SHA-1
2020, collision with $2^{61.2}$ complexity, SHA-1 is a Shambles - First Chosen-Prefix Collision on SHA-1 and Application to the PGP Web of Trust, Leurent et. al. (The new article)
2020, chosen-prefix collision with $2^{63.4}$ complexity, same paper above.

Questions:

Can a double hashing $h= \operatorname{SHA-1}(\operatorname{SHA-1}(m))$ mitigate the CP-collision?^* It seems so, since the meaningful part will not exist for attackers as longs as they are not able to break double $\operatorname{SHA-1}$. This seems not feasible, yet.
An immediate follow-up question; if the answer is yes, should we design the new protocols based on double hashing?

^*^{There can be many variants of double hashing.}

score 30 · Accepted Answer · edited Jan 07 '20 at 23:28

30

a. No such double hashing doesn't do a bit of good. Anything which collides after a single hash will definetly collide after a double hash. It preserves all collisions and adds new ones.

We might consider other constructions which may provide some strength e.g $H(H(m) || m)$ however:

b. We have no need for any such double hashing of SHA1 as we have newer better hash functions. Most notably we have SHA3 which is by all accounts far from being broken

edited Jan 07 '20 at 23:28

kodlu

22,423
2
27
57

answered Jan 07 '20 at 17:50

Meir Maor

11,835
1
23
54

for part a) yes. the default construction is insecure. Alternatives are better. part b) I consider the other constructions as a fail-safe mechanism. As we can see, there are protocols still use SHA-1 although it is removed from recommendation. – kelalaka Jan 07 '20 at 18:05
6

In almost all places where we can replace SHA1 with the modified construction we could also replace with SHA3. We even have hardened SHA1 which gives some backwards comparability if required. – Meir Maor Jan 07 '20 at 18:08
Sorry, an incorrect sentence, I mean, if we start to use the alternatives from the beginning. In this case, there will be no need for replacement for single use hash attacks. Of course, this doesn't say about that there will no attack on $H(H(m)\mathbin|m)$ – kelalaka Jan 07 '20 at 18:13
1

@kelalaka: A possible more useful double-hash might be $H(m) || H("hello world" || m))$ or something, or combine those two hashes somehow other than concat, maybe XOR. They can both be computed with only a single pass over the data so it's still usable as a stream hash where you only have access to the data once on the fly. (No extra memory bandwidth required either, and interleaving computation on 2 hashes in parallel is probably good for throughput.) But even if you need a short 160-bit hash, that might not be better than truncating a SHA-256 or SHA-512. – Peter Cordes Jan 08 '20 at 03:34
17

I don't think constructing a new 160-bit hash function with SHA-1 as a building block makes a lot of sense for any use-case except maybe new firmware for existing embedded hardware that has a high-performance SHA-1 accelerator and can't run any other hashes acceptably fast. Otherwise if you can change the hash function, you can replace it entirely. – Peter Cordes Jan 08 '20 at 03:37
2

@PeterCordes Actually, NIST removed SHA-1 from the recommendation in 2011. The $2^{80}$ classical collision with 50% probability is not negligible, we should consider the lower probabilities, and there are already collective computing powers that can reach $\approx 2^{63}$ in a day, like Summit. Maybe the more interesting of this work is the use case. Truncating has one good side that prevents the extension attack that built-in SHA3. – kelalaka Jan 08 '20 at 08:52
15

"When you discover you’re riding a dead horse, the best strategy is to dismount." – tylo Jan 08 '20 at 10:10
1

HMAC is not vulnerable to collisions though. It is more than double hashing though. – Yuhong Bao Jul 05 '22 at 07:22

In 2020, SHA-1 practically broken in chosen-prefix collision (CP-collision). Can double SHA-1 hashing prevent CP-collision?

The list of attacks on SHA-1

Questions:

1 Answers1

Linked