From eef17cf4bd229f4b692b5eda320f8d3d76d2c2dd Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Fri, 24 Feb 2017 01:21:54 -0400 Subject: update --- doc/todo/sha1_collision_embedding_in_git-annex_keys.mdwn | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 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 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. -- cgit v1.2.3