update
This commit is contained in:
parent
102e04b30c
commit
44b9ac41a4
1 changed files with 13 additions and 2 deletions
|
@ -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.
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue