SHA1 collisions in key names was more exploitable than I thought
Yesterday's SHA1 collision attack could be used to generate eg: SHA256-sfoo--whatever.good SHA256-sfoo--whatever.bad Such that they collide. A repository with the good one could have the bad one swapped in and signed commits would still verify. I've already mitigated this.
This commit is contained in:
parent
27eca014be
commit
6b52fcbb7e
3 changed files with 10 additions and 13 deletions
5
Key.hs
5
Key.hs
|
@ -127,12 +127,11 @@ file2key s
|
|||
| otherwise = Nothing
|
||||
|
||||
{- When a key HasExt, the length of the extension is limited in order to
|
||||
- mitigate against SHA1 collision attacks (specifically, chosen-prefix
|
||||
- attacks).
|
||||
- mitigate against SHA1 collision attacks.
|
||||
-
|
||||
- In such an attack, the extension of the key could be made to contain
|
||||
- the collision generation data, with the result that a signed git commit
|
||||
- including such keys would not be secure.
|
||||
- including such keys would not be secure.
|
||||
-
|
||||
- The maximum extension length ever generated for such a key was 8
|
||||
- characters; 20 is used here to give a little future wiggle-room.
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue