update

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.