diff options
| -rw-r--r-- | doc/todo/sha1_collision_embedding_in_git-annex_keys.mdwn | 15 |
1 files changed, 13 insertions, 2 deletions
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 dc3dccdc5..1a73a279d 100644 --- a/doc/todo/sha1_collision_embedding_in_git-annex_keys.mdwn +++ b/doc/todo/sha1_collision_embedding_in_git-annex_keys.mdwn @@ -23,10 +23,21 @@ is enabled) A few other potential problems: * `*E` backends could embed sha1 collision data in a long filename - extension. It might be worth limiting the length + 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 prefix attack; it does not allow creating two colliding + keys that contain two different SHA2 checksums. That would need a + preimage attack to be feasible. + + It might be worth 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 attacks. + be less than the size of the data needed for current SHA1 collision + attacks. Presumably aa preimage attack would need a similar amount of + data. + * It might be possible to embed colliding data in a specially constructed key name with an extra field in it, eg "SHA256-cXXXXXXXXXXXXXXX-...". Need to review the code and see if such extra fields are allowed. |