2
"brute force a PBKDF2-HMAC-SHA1" is not about collisions (at least, if a single hash is targeted, or if there's salt at the input of the password hash). It's a preimage attack.
The hash output by SHA-1 is 160-bit. That's 20 bytes (not characters; these are different notions, and why we have character encodings). It can take $2^{160}$ values. The ...
2
Even collision resistance is not sufficient to make HMAC unforgeable, so neither is second-preimage resistance.
Let $H : \{0,1\}^* \to \{0,1\}^n$ be a collision resistant hash function. We define the hash function $H' : \{0,1\}^* \to \{0,1\}^{n+1}$ as
$$H'(m\Vert b) = H(m)\Vert b,$$
where $|b|=1$.
Since for any $m_0\Vert b_0$ and $m_1\Vert b_1$, it holds ...
1
(1) Yes, it would be a concern. Once upon a time, Dropbox did this. When synchronizing the files, it checked the hashes before uploading. Thus, if the file was already in their servers, they just linked it and the transfer was instantaneous. Then people started using it for sharing content. By having the hash of e.g. a movie, they could "claim" to ...
1
It's indeed a genuine concern.
How to fight this?
Well, once client had provided the SHA256 hash of the file (to quickly index the file on the server), your server then provide a random one-time key and ask the client to hash the file again with HMAC and the key. Since the key is one-time and random, adversaries have little chance at guessing the key and ...
Only top voted, non community-wiki answers of a minimum length are eligible
