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:
|
A few other potential problems:
|
||||||
|
|
||||||
* `*E` backends could embed sha1 collision data in a long filename
|
* `*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
|
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
|
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
|
* It might be possible to embed colliding data in a specially constructed
|
||||||
key name with an extra field in it, eg "SHA256-cXXXXXXXXXXXXXXX-...".
|
key name with an extra field in it, eg "SHA256-cXXXXXXXXXXXXXXX-...".
|
||||||
Need to review the code and see if such extra fields are allowed.
|
Need to review the code and see if such extra fields are allowed.
|
||||||
|
|
Loading…
Add table
Add a link
Reference in a new issue