Crypto Algorithm Question - Using SHA1 for file-uniqueness check still ok?

I have a website with pictures and I'd like to SHA1 the pic files and use that as the filename for that picture.

Now, the goal is just for unique identification, and while SHA1 seems broken academically, I'm not trying to use it for signatures.. I just want a reasonable guarantee that no two pictures in my photo album will SHA1 to the same value.

Even at 160 bits and 80 bits being collision free, 2^80 is still a large number of photos, and I am not sure I can imagine two photos that hash to the same value while looking different.

I would pick something bigger like SHA512, but then the filename would get too long to manage.

Now I am thinking I'd pick SHA1 over RIPEMD-160 simply because I have more guarantees of compatibility as well as rightness of implementation.

In fact, I'd be happy with 128 bits, as that'd yield a filename that's only 16 bytes long instead of 20..

Just wanted to get some opinions..

for what you describe, SHA1 or even MD5 is fine.

Consider that happens if you get a collision? You disallow a photo or two? How likely is that? very low.

For the sore purpose of unique file names, you don't need to use a hash function rather a unique one. If you have PHP as a server side language, you may use the uniqid function, which output depends on milliseconds. I'm pretty confident there are similar functions in all other server-side languages.

Well..

Actually, I don't want to use something like uniqid, because I want the ID to be regenerateable from nothing but the file.

Thus, the hash of the file.

If the database is thrashed, having the file, I can regen the indexes..

Unique filenames aren't the goal, primary keys in the database that correspond to the files themselves are.

Right now, most of the galleries out there have a disconnect between the relationship (in the database) and the action item you are relating (the files).

I'm trying to cheat to bridge this gap.

I think you are on the right track. You'll handle 'identical' files well.

There are interesting philosophical questions about 'near identical' files. a Crypto hash will yield radically different values for tiny changes.

A little cropping changes the hash, but not the picture that human eyeballs interpret. A little softening of the image, or pushing the color, and its totally different. Except its not.

Absolutely..

HASH will give me a boolean, either it's EXACTLY the same, or not the same. Off by one pixel, is off by one byte or more, which will give me a radically different hash.

This will prevent file redundancy, as I'll have a db of pointers pointing to the same file, only need to keep one copy instead of keeping a dozen of the exact same photo.

Yes, I agree. Having a unique name depending on file content is certainly nice and bridges the gap to the DB.

Using the birthday paradox and google you'll need about 5.05693754 * 10^9 pictures to have 50% chance of collision with MD5.

This concept has been utilized before. phpbb (at least for version 2, not sure about 3) uses md5's of user's avatars as the image's filename.