diff options
| author |  Joey Hess <joeyh@joeyh.name> | 2017-02-24 00:21:58 -0400 |
|---|---|---|
| committer | Joey Hess <joeyh@joeyh.name> | 2017-02-24 00:21:58 -0400 |
| commit | 7c97656dda76c83383554005bd0f7b5e24993efa (patch) | |
| tree | 43c908aff1a4b8b0a767398f09b29850e7b54128 | |
| parent | 24115d7fe885e3c15603daca9c2bd5e25c7c5a14 (diff) | |
update
| -rw-r--r-- | doc/todo/sha1_collision_embedding_in_git-annex_keys.mdwn | 10 |
1 files changed, 4 insertions, 6 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 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. |