From 7c97656dda76c83383554005bd0f7b5e24993efa Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Fri, 24 Feb 2017 00:21:58 -0400 Subject: update --- doc/todo/sha1_collision_embedding_in_git-annex_keys.mdwn | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-) (limited to 'doc/todo/sha1_collision_embedding_in_git-annex_keys.mdwn') 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 069fef85b..7acbfde13 100644 --- a/doc/todo/sha1_collision_embedding_in_git-annex_keys.mdwn +++ b/doc/todo/sha1_collision_embedding_in_git-annex_keys.mdwn @@ -23,12 +23,10 @@ is enabled) A few other potential problems: * `*E` backends could embed sha1 collision data in a long filename - extension. That this is much harder to exploit because git-annex - checks the hash of the data when it enters the repository, and git-annex - fsck also verifies it. It still might be worth limiting the length - of an extension 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. + extension. 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. * 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