How is this not already true? Huge taxes on cigarettes to disincentivize smoking, tax deduction for paying mortgage interest to encourage home buying, etc. The government has, and will continue to, use taxes to alter behavior it likes/dislikes.
There was talk about this in the original Red Hat article. They said that this was totally possible but that no organization wanted to step forward and take the responsibility it would require to manage the "Linux root of trust". If the bootloader just loads anything then it is useless, it probably will only load signed kernels. One organization can hold the keys for this secured bootloader and give out subkeys for other distros to sign their kernels, but then they have to deal with all the verification and revokation headaches that go along with it.
On the other hand, Microsoft might sign a generic bootloader that would load unsigned kernels if it had some big warning that said something to that effect every time you booted your machine. Remember, their goal in all this (supposedly) is to stop rootkits and hypervisor malware that could live at a higher boot level than the OS. They only want it to be impossible for an attacker to silently subvert the chain of trust. If a bootloader loads unsigned kernels, then it could be used for an attack, but if it announces itself quite loudly then the problem is solved (depending on your definition of solved).
I imagine they are only going to grant keys to large Linux vendors that can be verified. I'm not sure what your solution would even do, how would generating a random signing key when you start do anything?
Pairing based cryptography is a relatively new kind of crypto that can be thought of as public-key plus some extra useful properties (makes Identity Based Encryption possible for instance). It does not say in the article which particular scheme they are using, but one of the big ones is Boneh-Franklin. Just as the security of RSA is based on the hardness of factoring, most pairing schemes are based on the hardness of something called the Bilinear Diffie-Hellman problem.
It may be tempting to deride this scheme for the fact that it was broken so quickly, but there are extenuating circumstances to consider. Unlike a symmetric cipher like AES, where an arbitrary key is essentially just as good as any other key, asymmetric ciphers have a much more nuanced keyspace. To start with, not every value in the keyspace can actually be used as a key. Using AES as an example again, you can choose any 128-bit value and it will work as a key for AES-128. In contrast, for RSA to work the key (modulus) must be a product of two large primes. In the space of all 1028-bit numbers, there are many such numbers but they are very sparsely distributed. This means that you need a much larger key size for RSA than AES to get the same amount of security. To complicate things further, the two factors cannot be too close together (lest they be broken with Fermat's factorization algorithm) nor can they be one larger than a number with many small factors (broken by Pollard's p-1 algorithm). In short, there are many things to consider and, although it is accepted that larger keys will be more secure, it is often not straightforward to figure out exactly how large a key should be to provide adequate security.
Now, the reason I digressed a bit there was to show that, although asymmetric encryption has proven security (which widely used block ciphers do not), it is often difficult to judge how secure certain keys and key sizes are without years or decades of researchers examining the cipher. Pairing based cryptography is a relatively new field and it is quite possible that researchers have underestimated the key size needed for adequate security, even though the underlying system is still secure. The information given in the article seems to point to that as being the case since they have not discovered any major theoretical break, only a way to speed up checking of possible keys.
The key can be any size, just like in RSA. They likely chose 923 as a number they thought they could reasonably break. This is similar to the RSA contests where they try to find the largest semi-prime that they can factor (it is never a round number).
This is completely wrong. They are using a pairing based crypto system which you can think of as public key plus extra useful properties. The security of these schemes is based on the bilinear diffie Hellman assumption which is very recent and has not been thoroughly tested. It is very likely that it is still secure but at larger key sizes than previously thought.
Only some asymmetric ciphers (those based on factoring or discrete logs) are broken by quantum computers. Lattice-based cryptosystems are believed to be resistant to quantum algorithms. If we pick the key size to be large enough, and there is not some unforeseen explosion in classical computing speeds, then existing cryptographic techniques should suffice for many years.
Depends on what area of computer science you are in. For every field you point out that uses calculus I can point you to two more active areas of research that focus on discrete. Personally, I am in cryptography (which no one can argue as being "solved") where modern research still relies on new developments in the areas you downplay i.e number theory and graph theory (check out the new biclique attack on AES for an example).
I agree, it sucks pretty hard from a consumer standpoint but I can also see why it might have been (emphasis might) necessary in this case. That thing is crazy thin and if you look at the teardown they don't really have any room to mess around in there. Looks like they made it possible by taking all the things that used to be self contained (RAM, hard drive, etc.), pulling out their guts and soldering/plugging them directly onto the main board. Think about the space you save over having to include hard drive enclosures and sockets for the RAM. Again, not saying I like this, but I would sooner attribute it to a desire to make this thing as streamlined as possible rather than assuming they were trying to screw people over. In fact, the new non-retina Macbook Pros are still totally user replaceable.
You are making the assumption that EVERY person that pirated it would pay this $12/month, which is ridiculous. If you look at the list, there are lots of shows that are available on Amazon on iTunes at reasonable prices but people still pirate the hell out of them.
If they wanted what they already had then there was no problem to begin with as express 2010 will still be able to develop desktop applications. The quote accurately captures the belief (not saying it is true) that developers want the new features in 2012 but applied to desktop apps and not metro.
What kind of qualifier is that? If the computing power was "almost unlimited" you could crack any password you want since it is essentially unbounded in its parallelism. They are obviously making some concrete assumption about computing resources (which the article does not specify, as far as I can tell).
Actually quite the opposite. It has been stated by antivirus folks that its large size and structure actually helped it hide for longer. AV software is used to viruses being super-optimized and obfuscated. Flame on the other hand looks like any other desktop application, complete with included runtimes.
We wouldn't even need ASLR if people would code in safe languages. But around here C/C++ is god and everyone thinks it is impossible for there to be buffer overflows in their code because they are GOOD programmers...
They have chosen suffix attacks on MD5 that would work for this but you have to have the freedom to add some large amount of data (many bytes) to the front of the input, which would most likely be rejected from any reasonable login system.
The attack on multiple encryption relies on two things:
1) Input and output space are both finite
2) You can invert encryption under possible key values to "meet in the middle"
Neither of these is true for hash functions (although in this specific password case you can put reasonable bounds on the size of the password to get (1) under assumptions).
Would it be cost-effective for Microsoft to buy specially made systems (read: expensive) for all its developers just to screw the.001% of people that like to hack their own kernel?
As others have said, you just generate strings until you get one that matches the hash. It is possible that the string you generated does not match the original password, but if you are generating "reasonable" passwords then that probability is so small as to be negligible. For instance, if the hashes are 128-bits and you are trying all alphanumeric passwords up to 10 digits (upper and lower case) then you have less than 2^60 combinations. The probability that you find a collision with the target hash that is not the actual password used is 1/2^(128-60) = 2^-68 i.e. infinitesimally small. If the password space you are checking is very large (somewhere in the range of 20 digit case-sensitive alphanumeric plus symbols) then the probability that you have found a password that hashes but was not the user's password becomes non-negligible.
Most definitely, as this is indistinguishable from a kernel rootkit or hypervisor-based malware. Sucks but how else would you deal with it? You can turn off secure boot and do whatever you want, but then you aren't protected from things like this.
As it says in the Red Hat report, this situation is mostly because nobody in the Linux community will step up to act as the root of trust. If there was someone willing to do that, they could pay the one time Microsoft fee and then verify and sign any other distro's kernel. Unfortunately that is too much work and responsibility for a volunteer organization, and nobody around here wants to pay for anything these days. You have to trust somebody with secure boot and the Linux landscape is too fractured for any one organization to act as the root. Also, there is no reason that you could not have two root keys (so dual booting windows is still possible) or even just have your Linux bootloader with your Linux root key run Windows regularly. Once you have control of the root you can do anything you want. I agree that most users will not be able to mess with UEFI, but that is precisely the reason Red Hat is doing this.
Maybe I just have faith in the whole hacker/maker scene. There is too much momentum going to let something like this stop people who are really determined to run their own stuff. Either Microsoft, Red Hat, etc are going to keep it open to the point where we can do what we want, or they will lock it up like you say and we will figure out something else. TBH I would love to see what would happen if they DID lock down machines like this. Imagine what kind of cool open source hardware people would come up with. Right now we don't need anything like that, but if we did? The kind of creative, imaginative, resourceful people that are making things these days would probably come up with something great. At the very least, someone like Geohot will find a way to hack motherboards to let you run what you want (pertaining to your "other os" comment). There are just too many smart people to be stopped by stupid crap like that.
Slashdot Mirror
How is this not already true? Huge taxes on cigarettes to disincentivize smoking, tax deduction for paying mortgage interest to encourage home buying, etc. The government has, and will continue to, use taxes to alter behavior it likes/dislikes.
I find that's usually how lazy, entitled people react, but if you say so.
What is this mysterious federal plan? The public option was removed from the bill before it passed years ago.
There was talk about this in the original Red Hat article. They said that this was totally possible but that no organization wanted to step forward and take the responsibility it would require to manage the "Linux root of trust". If the bootloader just loads anything then it is useless, it probably will only load signed kernels. One organization can hold the keys for this secured bootloader and give out subkeys for other distros to sign their kernels, but then they have to deal with all the verification and revokation headaches that go along with it. On the other hand, Microsoft might sign a generic bootloader that would load unsigned kernels if it had some big warning that said something to that effect every time you booted your machine. Remember, their goal in all this (supposedly) is to stop rootkits and hypervisor malware that could live at a higher boot level than the OS. They only want it to be impossible for an attacker to silently subvert the chain of trust. If a bootloader loads unsigned kernels, then it could be used for an attack, but if it announces itself quite loudly then the problem is solved (depending on your definition of solved).
I imagine they are only going to grant keys to large Linux vendors that can be verified. I'm not sure what your solution would even do, how would generating a random signing key when you start do anything?
Pairing based cryptography is a relatively new kind of crypto that can be thought of as public-key plus some extra useful properties (makes Identity Based Encryption possible for instance). It does not say in the article which particular scheme they are using, but one of the big ones is Boneh-Franklin. Just as the security of RSA is based on the hardness of factoring, most pairing schemes are based on the hardness of something called the Bilinear Diffie-Hellman problem.
It may be tempting to deride this scheme for the fact that it was broken so quickly, but there are extenuating circumstances to consider. Unlike a symmetric cipher like AES, where an arbitrary key is essentially just as good as any other key, asymmetric ciphers have a much more nuanced keyspace. To start with, not every value in the keyspace can actually be used as a key. Using AES as an example again, you can choose any 128-bit value and it will work as a key for AES-128. In contrast, for RSA to work the key (modulus) must be a product of two large primes. In the space of all 1028-bit numbers, there are many such numbers but they are very sparsely distributed. This means that you need a much larger key size for RSA than AES to get the same amount of security. To complicate things further, the two factors cannot be too close together (lest they be broken with Fermat's factorization algorithm) nor can they be one larger than a number with many small factors (broken by Pollard's p-1 algorithm). In short, there are many things to consider and, although it is accepted that larger keys will be more secure, it is often not straightforward to figure out exactly how large a key should be to provide adequate security.
Now, the reason I digressed a bit there was to show that, although asymmetric encryption has proven security (which widely used block ciphers do not), it is often difficult to judge how secure certain keys and key sizes are without years or decades of researchers examining the cipher. Pairing based cryptography is a relatively new field and it is quite possible that researchers have underestimated the key size needed for adequate security, even though the underlying system is still secure. The information given in the article seems to point to that as being the case since they have not discovered any major theoretical break, only a way to speed up checking of possible keys.
The key can be any size, just like in RSA. They likely chose 923 as a number they thought they could reasonably break. This is similar to the RSA contests where they try to find the largest semi-prime that they can factor (it is never a round number).
This is completely wrong. They are using a pairing based crypto system which you can think of as public key plus extra useful properties. The security of these schemes is based on the bilinear diffie Hellman assumption which is very recent and has not been thoroughly tested. It is very likely that it is still secure but at larger key sizes than previously thought.
Only some asymmetric ciphers (those based on factoring or discrete logs) are broken by quantum computers. Lattice-based cryptosystems are believed to be resistant to quantum algorithms. If we pick the key size to be large enough, and there is not some unforeseen explosion in classical computing speeds, then existing cryptographic techniques should suffice for many years.
Depends on what area of computer science you are in. For every field you point out that uses calculus I can point you to two more active areas of research that focus on discrete. Personally, I am in cryptography (which no one can argue as being "solved") where modern research still relies on new developments in the areas you downplay i.e number theory and graph theory (check out the new biclique attack on AES for an example).
I agree, it sucks pretty hard from a consumer standpoint but I can also see why it might have been (emphasis might) necessary in this case. That thing is crazy thin and if you look at the teardown they don't really have any room to mess around in there. Looks like they made it possible by taking all the things that used to be self contained (RAM, hard drive, etc.), pulling out their guts and soldering/plugging them directly onto the main board. Think about the space you save over having to include hard drive enclosures and sockets for the RAM. Again, not saying I like this, but I would sooner attribute it to a desire to make this thing as streamlined as possible rather than assuming they were trying to screw people over. In fact, the new non-retina Macbook Pros are still totally user replaceable.
You are making the assumption that EVERY person that pirated it would pay this $12/month, which is ridiculous. If you look at the list, there are lots of shows that are available on Amazon on iTunes at reasonable prices but people still pirate the hell out of them.
Slightly more people pirate it than actually watch it legitimately. http://gizmodo.com/5916885/more-people-pirate-game-of-thrones-than-watch-game-of-thrones-on-hbo
If they wanted what they already had then there was no problem to begin with as express 2010 will still be able to develop desktop applications. The quote accurately captures the belief (not saying it is true) that developers want the new features in 2012 but applied to desktop apps and not metro.
Agreed, but it can't be considered a failure by the team developing Flame when they accurately assessed this weakness in existing AV and exploited it.
What kind of qualifier is that? If the computing power was "almost unlimited" you could crack any password you want since it is essentially unbounded in its parallelism. They are obviously making some concrete assumption about computing resources (which the article does not specify, as far as I can tell).
Actually quite the opposite. It has been stated by antivirus folks that its large size and structure actually helped it hide for longer. AV software is used to viruses being super-optimized and obfuscated. Flame on the other hand looks like any other desktop application, complete with included runtimes.
We wouldn't even need ASLR if people would code in safe languages. But around here C/C++ is god and everyone thinks it is impossible for there to be buffer overflows in their code because they are GOOD programmers...
They have chosen suffix attacks on MD5 that would work for this but you have to have the freedom to add some large amount of data (many bytes) to the front of the input, which would most likely be rejected from any reasonable login system.
The attack on multiple encryption relies on two things: 1) Input and output space are both finite 2) You can invert encryption under possible key values to "meet in the middle" Neither of these is true for hash functions (although in this specific password case you can put reasonable bounds on the size of the password to get (1) under assumptions).
Would it be cost-effective for Microsoft to buy specially made systems (read: expensive) for all its developers just to screw the .001% of people that like to hack their own kernel?
As others have said, you just generate strings until you get one that matches the hash. It is possible that the string you generated does not match the original password, but if you are generating "reasonable" passwords then that probability is so small as to be negligible. For instance, if the hashes are 128-bits and you are trying all alphanumeric passwords up to 10 digits (upper and lower case) then you have less than 2^60 combinations. The probability that you find a collision with the target hash that is not the actual password used is 1/2^(128-60) = 2^-68 i.e. infinitesimally small. If the password space you are checking is very large (somewhere in the range of 20 digit case-sensitive alphanumeric plus symbols) then the probability that you have found a password that hashes but was not the user's password becomes non-negligible.
Most definitely, as this is indistinguishable from a kernel rootkit or hypervisor-based malware. Sucks but how else would you deal with it? You can turn off secure boot and do whatever you want, but then you aren't protected from things like this.
As it says in the Red Hat report, this situation is mostly because nobody in the Linux community will step up to act as the root of trust. If there was someone willing to do that, they could pay the one time Microsoft fee and then verify and sign any other distro's kernel. Unfortunately that is too much work and responsibility for a volunteer organization, and nobody around here wants to pay for anything these days. You have to trust somebody with secure boot and the Linux landscape is too fractured for any one organization to act as the root. Also, there is no reason that you could not have two root keys (so dual booting windows is still possible) or even just have your Linux bootloader with your Linux root key run Windows regularly. Once you have control of the root you can do anything you want. I agree that most users will not be able to mess with UEFI, but that is precisely the reason Red Hat is doing this.
Maybe I just have faith in the whole hacker/maker scene. There is too much momentum going to let something like this stop people who are really determined to run their own stuff. Either Microsoft, Red Hat, etc are going to keep it open to the point where we can do what we want, or they will lock it up like you say and we will figure out something else. TBH I would love to see what would happen if they DID lock down machines like this. Imagine what kind of cool open source hardware people would come up with. Right now we don't need anything like that, but if we did? The kind of creative, imaginative, resourceful people that are making things these days would probably come up with something great. At the very least, someone like Geohot will find a way to hack motherboards to let you run what you want (pertaining to your "other os" comment). There are just too many smart people to be stopped by stupid crap like that.