Linked by Thom Holwerda on Fri 23rd Sep 2011 22:22 UTC, submitted by kragil
Windows 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.
Thread beginning with comment 490754
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[2]: RSA key example.
by nonoitall on Mon 26th Sep 2011 05:53 UTC in reply to "RE: RSA key example."
Member since:

Isn't it possible to defeat hash signing by producing a binary which has the same hash, but different code ? After all, the transformation which turns a multi-MB binary into a small, easy to compute and check hash, loses so much information that there's a huge number of possible binaries associated to a given hash.

(It is my understanding that this is what happened with MD5, and is potentially also happening with SHA-1... Breaking hashes this way seems to be purely a matter of time, given that you have some skilled mathematicians at hand)

For cryptographically secure hash algorithms, it's not really feasible time-wise to do this.

Reply Parent Score: 2

RE[3]: RSA key example.
by Neolander on Mon 26th Sep 2011 17:17 in reply to "RE[2]: RSA key example."
Neolander Member since:

Which properties of a hash algorithm make it cryptographically secure ?

(Fascinating discussion, by the way... I've been wondering about this since the first time I've heard about the concept of digital signing)

Reply Parent Score: 1

RE[4]: RSA key example.
by Alfman on Mon 26th Sep 2011 18:27 in reply to "RE[3]: RSA key example."
Alfman Member since:


"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.

Lookup this sha1hash value at

Edited 2011-09-26 18:31 UTC

Reply Parent Score: 2