The story behind that was actually pretty funny. JOannopolous originally wrote a long dissertation effectively "proving" that creating a near-perfect dielectric mirror was impossible. Then he turned around and proved himself wrong by making one. =) Given the usefulness of it though, I'm sure he wasn't all that disappointed.
Re:What I don't understand is...
on
Linus on DRM
·
· Score: 1
Not Correct,
If you have a SIGNED kernel binary, the owner of the key used to sign the binary will have included a checksum in the signature that requires the binary to match what was originally signed. If it does not, the binary is not authentic to the signing source. This is quite common even today.
Now you introduce a hardware level scheme that checks the signiture on the binary against a authentication key stored in hardware (probably in the BIOS). The hardware of the CPU forces any code ran on it to first pass the authentication step. If it does not, the CPU simply ceases to operate. Therefore, you have ensured that no one other than the binary signer can run the kernel on a DRM machine.
Now let's assume that you get the source for the binary and try to "spoof" to the CPU that you're running DRM. The CPU will do a comparison of the signiture against it's harware key. Since you modified the binary, the checksum stored in the signature will NOT match that of the actual binary. The CPU will stop functioning and you cannot do anything about it.
The problem I currently see with DRM (and the reason I think it will never work reliably) lies in the fact that to function, DRM MUST STORE A COPY OF THE CORRECT KEY SOMEWHERE IN THE HARDWARE. Let's address pirated software as an example. You buy a program that you want to give to other people for free but that is protected by DRM. You take the binary and put it on a non-DRM protected computer (Yes there's use for that old Pentium 66 that you have laying around.) and you snip out the section that contains the signiture block. In it's place you put a signiture that contains the correct checksum, but the rest of the signiture is for a key that you have full knowledge of. You then bypass on the motherboard the connections to the correct key, and in it's place put your dummy key and you're in business. You now have full access to that machine.
The only exception to this would be if the CPU hardware manufacturer put the key on the CPU itself, which would make it completely opaque to you, since you could not intercept the signals easily (as you could with a BIOS or other motherboard type chip). Then you'd be screwed.
However, doing this is NOT possible. Can you imagine having to get CPU maker 'X' to sign each kernel you wanted to run? It'd be suicide for them. They'd have to audit all source you sent them, compile it themselves, and then distribute it back to you. If they made a mistake the RIAA would sue them for signing a non-secure kernel. =) Anything short of putting the key on the CPU itself is doomed to failure.
You are, however, correct in your statement that "Client-side security never works in the end."
The US isn't concerned that Israel will sell or use WMD on the world or their neighbors either.
Israel doesn't have a regime in power that has killed, starved, or gased more than 200,00 of it's people either.
Seems to me to be a pretty big distinction.
>Just pointing out that the cabling is hardly the bottleneck..
You're mistaken in the assumption leading to this statement. What they're offering is a change to TCP, which is a transport level network stack. This makes it vastly useful for the basic switching that the internet relies on. What you're assuming here is that it's an increase in the network and physical layer. Since the article even talks about medium utilization, they are clearly implying that the increases in speed have to do with efficiency of transfer, AKA the transport layer.
I see...
So when a country forces the UN to pass 4 resolutions requiring it to disarm, kicks out inspectors no less than 4 times, and only even comes back to the table (and half-heartedly at that) it means they're disarming? Maybe you should smoke less crack and wake up to this little place I like to call ReeAlitee....
Regardless of which corporations or media powerhouses come out on top in this and what laws are passed, it's not over until the Supreme Court Rules. Period.
While IANAL, it is clear that some very basic rights are trampled by these types of initiatives, and I can guarantee that once your average joe realizes that they can't use the content that they've bought in a useful manner, the courts will be full of class action lawsuits. (Granted it will be the lawyers who figure this out first.) Several of those lawsuits will reach the Supreme Court, which has a history of supporting user rights when it comes to purchased content(think back the whole playstation game burning fiasco where the courts decided that it is legal and lawful to burn backup copies of purchased games).
My guess is that regardless of what happens in the short term, in the long term things will bounce back.
Slashdot Mirror
The story behind that was actually pretty funny. JOannopolous originally wrote a long dissertation effectively "proving" that creating a near-perfect dielectric mirror was impossible. Then he turned around and proved himself wrong by making one. =) Given the usefulness of it though, I'm sure he wasn't all that disappointed.
Not Correct, If you have a SIGNED kernel binary, the owner of the key used to sign the binary will have included a checksum in the signature that requires the binary to match what was originally signed. If it does not, the binary is not authentic to the signing source. This is quite common even today. Now you introduce a hardware level scheme that checks the signiture on the binary against a authentication key stored in hardware (probably in the BIOS). The hardware of the CPU forces any code ran on it to first pass the authentication step. If it does not, the CPU simply ceases to operate. Therefore, you have ensured that no one other than the binary signer can run the kernel on a DRM machine. Now let's assume that you get the source for the binary and try to "spoof" to the CPU that you're running DRM. The CPU will do a comparison of the signiture against it's harware key. Since you modified the binary, the checksum stored in the signature will NOT match that of the actual binary. The CPU will stop functioning and you cannot do anything about it. The problem I currently see with DRM (and the reason I think it will never work reliably) lies in the fact that to function, DRM MUST STORE A COPY OF THE CORRECT KEY SOMEWHERE IN THE HARDWARE. Let's address pirated software as an example. You buy a program that you want to give to other people for free but that is protected by DRM. You take the binary and put it on a non-DRM protected computer (Yes there's use for that old Pentium 66 that you have laying around.) and you snip out the section that contains the signiture block. In it's place you put a signiture that contains the correct checksum, but the rest of the signiture is for a key that you have full knowledge of. You then bypass on the motherboard the connections to the correct key, and in it's place put your dummy key and you're in business. You now have full access to that machine. The only exception to this would be if the CPU hardware manufacturer put the key on the CPU itself, which would make it completely opaque to you, since you could not intercept the signals easily (as you could with a BIOS or other motherboard type chip). Then you'd be screwed. However, doing this is NOT possible. Can you imagine having to get CPU maker 'X' to sign each kernel you wanted to run? It'd be suicide for them. They'd have to audit all source you sent them, compile it themselves, and then distribute it back to you. If they made a mistake the RIAA would sue them for signing a non-secure kernel. =) Anything short of putting the key on the CPU itself is doomed to failure. You are, however, correct in your statement that "Client-side security never works in the end."
The US isn't concerned that Israel will sell or use WMD on the world or their neighbors either. Israel doesn't have a regime in power that has killed, starved, or gased more than 200,00 of it's people either. Seems to me to be a pretty big distinction.
>Just pointing out that the cabling is hardly the bottleneck.. You're mistaken in the assumption leading to this statement. What they're offering is a change to TCP, which is a transport level network stack. This makes it vastly useful for the basic switching that the internet relies on. What you're assuming here is that it's an increase in the network and physical layer. Since the article even talks about medium utilization, they are clearly implying that the increases in speed have to do with efficiency of transfer, AKA the transport layer.
I see... So when a country forces the UN to pass 4 resolutions requiring it to disarm, kicks out inspectors no less than 4 times, and only even comes back to the table (and half-heartedly at that) it means they're disarming? Maybe you should smoke less crack and wake up to this little place I like to call ReeAlitee....
Regardless of which corporations or media powerhouses come out on top in this and what laws are passed, it's not over until the Supreme Court Rules. Period.
While IANAL, it is clear that some very basic rights are trampled by these types of initiatives, and I can guarantee that once your average joe realizes that they can't use the content that they've bought in a useful manner, the courts will be full of class action lawsuits. (Granted it will be the lawyers who figure this out first.) Several of those lawsuits will reach the Supreme Court, which has a history of supporting user rights when it comes to purchased content(think back the whole playstation game burning fiasco where the courts decided that it is legal and lawful to burn backup copies of purchased games).
My guess is that regardless of what happens in the short term, in the long term things will bounce back.
In Soviet Russia, Supreme Court Rules You!