aboutsummaryrefslogtreecommitdiff
path: root/Key.hs
diff options
context:
space:
mode:
authorGravatar Joey Hess <joeyh@joeyh.name>2017-02-24 19:54:36 -0400
committerGravatar Joey Hess <joeyh@joeyh.name>2017-02-24 19:54:36 -0400
commita091af71fc8161427f8d9553042d0bc41507fff7 (patch)
tree69cf2785559ef7600ce4402abdaee4a6071fae36 /Key.hs
parent1630f299751d4e8b186cd176c8219f11257586d8 (diff)
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.
Diffstat (limited to 'Key.hs')
-rw-r--r--Key.hs5
1 files changed, 2 insertions, 3 deletions
diff --git a/Key.hs b/Key.hs
index 5eaf3d56b..d1669bf05 100644
--- a/Key.hs
+++ b/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.