The story about how secure boot for Windows 8, part of UEFI, will hinder the use of non-signed binaries and operating systems, like Linux, has registered at Redmond as well. The company posted about it on the Building Windows 8 blog - but didn't take any of the worries away. In fact, Red Hat's Matthew Garrett, who originally broke this story, has some more information - worst of which is that Red Hat has received confirmation from hardware vendors that some of them will not allow you to disable secure boot.

"Which properties of a hash algorithm make it cryptographically secure ?"

This isn't the answer you want, but probably the one which is closest to the truth: The property of having been seriously analyzed by thousands of cryptographers in public and still remaining standing.

Haha...ok I wont avoid the question. In principal, the the hash bits must not reveal any information about the input bits. In practice, this means:

Any single bit change must, on average, effect 50% of the hash. There must be no calculable correlation between any input bit and output bit. Linearly sequencing through input values must not produce any pattern in output values. Any bias whatsoever indicates a weakness.

All else being equal, a slower hash function is theoretically more secure than a faster one (after both having been optimized as much as possible). If the faster one requires X operations to brute force, the slower one may take X*100 operations to brute force.

As you were saying, even the ideal hash function is vulnerable to deliberate collisions every 1/(2^bit) iterations, therefor the bit length must be chosen such that the fastest conceivable cracking machine will be unlikely to uncover any collisions in it's lifetime.

Some research is being done to make cryptographic primitives which are not only computationally hard, but also "memory hard". Most hash functions today don't need more than a few hundred bytes of ram, which hypothetically makes it possible to brute force millions of instances simultaneously on a single chip. If a hash function uses 50MB of state, then clearly the parallelism potential of these chips is sharply reduced.

Also something worth noting. Anyone can build a database of forward hashes regardless of the algorithm, and then lookup the reverse hashes on demand. For this reason, it is unwise to hash secret data without random salt.