From a091af71fc8161427f8d9553042d0bc41507fff7 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Fri, 24 Feb 2017 19:54:36 -0400 Subject: 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. --- doc/todo/sha1_collision_embedding_in_git-annex_keys.mdwn | 13 +++++-------- 1 file changed, 5 insertions(+), 8 deletions(-) (limited to 'doc/todo') diff --git a/doc/todo/sha1_collision_embedding_in_git-annex_keys.mdwn b/doc/todo/sha1_collision_embedding_in_git-annex_keys.mdwn index 7bb23a007..97f7b4f22 100644 --- a/doc/todo/sha1_collision_embedding_in_git-annex_keys.mdwn +++ b/doc/todo/sha1_collision_embedding_in_git-annex_keys.mdwn @@ -74,13 +74,10 @@ A few other potential problems: * `*E` backends could embed sha1 collision data in a long filename extension in a key. - Impact is limited, because even if an attacker does this, the key also - contains the checksum (eg SHA2) of the annexed data. The current SHA1 - attack is only a common-prefix attack; it does not allow creating two - colliding keys that contain two different SHA2 checksums. That would - need a chosen-prefix attack. - - It might be worth limiting the length + The recent SHA1 common-prefix attack could be used to exploit this; + the result would be two keys that have the same SHA1. + + This can be fixed by limiting the length of an extension allowed in such a key to the longest such extension git-annex has ever supported (probably < 20 bytes or so), which would be less than the size of the data needed for current SHA1 collision @@ -92,7 +89,7 @@ A few other potential problems: Need to review the code and see if such extra fields are allowed. Update: All fields are numeric, but could contain arbitrary data - after the number. Could have been used in a chosen-prefix attack. + after the number. Could have been used in a common-prefix attack. This has been fixed; git-annex refuses to parse such fields, so it won't work with files that try to exploit this. -- cgit v1.2.3