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 490753
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: RSA key example.
by Neolander on Mon 26th Sep 2011 05:35 UTC in reply to "RSA key example."
Neolander
Member since:
2010-03-08

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)

Edited 2011-09-26 05:48 UTC

Reply Parent Score: 2

RE[2]: RSA key example.
by nonoitall on Mon 26th Sep 2011 05:53 in reply to "RE: RSA key example."
nonoitall Member since:
2011-09-22

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:
2010-03-08

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[2]: RSA key example.
by Alfman on Mon 26th Sep 2011 17:08 in reply to "RE: RSA key example."
Alfman Member since:
2011-01-28

Neolander,

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

You are absolutely right about the hash. Furthermore, you might say the same thing about RSA itself. There are only a finite number of possibilities to try, which implies that it's not difficult to build algorithms to enumerate them.

The key to all digital cryptography is that all known algorithms to crack the numbers use exponential time. Every additional bit is exponentially more difficult crack.

However these problems also fit squarely into the class of parallel problems considered "embarrassingly parallel", with no IO/sync overhead. This means shorter bit lengths are vulnerable against massive specialized cracking clusters.

History shows us that we need to be much more conservative with our estimates of cryptographic security. I recall when the EFF deliberately build a DES cracking machine in 1998 to publicly embarrass the US government on it's legal policy of restricting international crypto products to algorithms known to be extremely weak.

http://news.cnet.com/Record-set-in-cracking-56-bit-crypto/2100-1017...

Now days that we routinely use far larger bit lengths, and our encryption is much more resilient to brute force attacks. 256 bit cryptography cannot be brute forced today or in the near future. But we are still occasionally finding flaws in the algorithms which mathematically etch away at their security.

It is an open question whether cryptographers will ever be able to place a lower boundary on the work needed to crack a code, or whether sufficiently clever algorithms will always exist to reduce the search space ever further.

Reply Parent Score: 2

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

I'm also wondering if it's possible to mathematically reverse a hash algorithm in a way that provides, say, all files within a size range between X and Y that result in a given hash Z when going through the hashing algorithm. This operation could be followed by analyzing those files in the hope of finding one which has some desirable properties (like, in the context of secure boot, some simple code which is able to load other code)

And if it is, whether such a "clever" approach would have the potential to beat brute force random data injection to a tampered binary until it gets the same hash, in terms of execution speed.

Edited 2011-09-26 17:41 UTC

Reply Parent Score: 1