SHA-1 produces a 160 bit hash. Hashing any file longer than 160 bits (20 octets) will therefore necessarily lose information and makes reconstruction impossible. In theory, that is.
On the other hand, hashing files shorter than 20 octets is highly likely (practically guaranteed) to produce a 1:1 mapping. A 1:1 mapping means that without salt, it is trivial to revert the hash to the original contents with a readily existing rainbow table. Even with a typical non-secret salt, it is very possible to run a brute-force attack on very short files, so if you are concerned about that, you should add a salt that is sufficiently long (say, 128 bits) and keep the salt secret (this is not how you would normally use a salt, but you have a different situation, too). You could further add each file's name to the salt (unless what you are trying to do is deduplication), so different files with identical contents have different hashes.
In practice, although the hash cannot be reversed for files larger than 20 octets, small files (but larger than 20 octets) may still be reversed if the attacker is sufficiently persistent. For example, there exist 65536 files with 22 octets that have the same SHA-1, and you cannot prove which is the correct one. Or can you?
Unluckily the answer is "yes". Although each single of those 65k different files is an equally valid solution from the point of view of the hash, only one of them (or maybe two) will be something that isn't nonsensical random binary garbage. Which is trivial to identify by using a general purpose compression program (plaintext files are compressable, random garbage isn't). Moreover, if a file's name is known, it is usually relatively easy to check its contents against some magic bytes or a particular structure. The attacker only needs to consider files which have magic bytes that correspond to their type.
Luckily, this attack quickly becomes impractical. There are already 1028 files of length 32 which map to the same hash, and the vast majority of files on every computer is longer than that!
And now here is a surprise: The "more secure" SHA-512 is actually less secure in that respect. Since it ouputs 512 bits, it will do a 1:1 mapping for files up to 64 bytes.
My recommendation would be:
- If you really don't want to (or can't) use TLS/SSH (you know that
rsync will do the whole comparing hashes stuff including SSH connection for you, don't you?), use an encryption container such as e.g. Truecrypt. That will prevent someone else from accessing the hashes even if you put the container on the internet publicly on an untrusted server, or if you send them by email.
This makes every other consideration obsolete. No need to worry about whether the hashes can be reverted if the attacker doesn't know them!
- Do not use a hash that is bigger than necessary. The chance of one random hash collision in 1016 files (that's 10 billion times the number files presently on my desktop computer!) with a 160-bit hash is about 10-15. For ten thousand files, it's 10-22. In other words, it won't happen in your lifetime. Revision control sets like e.g. Git rely on the fact that collisions simply don't happen. Bigger hashes do not make anything better in your scenario, but they quite possibly make things worse (for small files).
- Salt file contents with file names and with a sufficiently long random salt that you keep secret.
- Consider hashing file names as well, since file names alone may convey important information.
- Don't transmit file lengths. It doesn't give you an advantage, but it may give one to an attacker.
Actually, if you don't tell the attacker the file's length, there are even a few more: there are also 256 files with 21 octets and one with 20 or fewer.