Yes, that looks like a fantastic piece of legislation -- it basically says that the DMCA can't outlaw actions which don't infringe copyright (which now it does, since any "circumvention" is deemed illegal, whether the resulting copying was or was not allowed by copyright law), which if frankly common sense. And the bigger part of the bill says that copyprotected disks have to be clearly labeled as such -- gee, you have to present your product honestly, how controversial can that be?
Anyway, I'd personally like to see this taken further -- that the law should guarantee that companies don't use technological measures to take away fair use acts. Saying circumvention is OK is a baby step, but why should we be required to hack something in order to re-gain our rights? Unfortunately, I don't see such a bill having a snowballs chance of making it through Congress, where common-sense isn't in great supply.
everything you do is directed at reducing Liberty for the users, owners and free developers of free (as in Liberty) software
And there's the most fundamental difference. I personally see the technology as potentially very empowering, and in fact increasing Liberty for the users. You believe the exact opposite. And that's why we'll probably never see eye-to-eye on this, but maybe in another 20 years we can compare notes.
I'm done with the point by point responses -- this really isn't making any progress at all. That you can't seem to follow what I'm saying, and say that you've read other publications on trusted platforms and find them "self-contradictory and obfusatory", really says a lot more about your ability to grasp the facts than it does about my explanations or the documentation that's out there (some of which is pretty good, in fact).
The bottom line is this: Trusted platforms allow you to have a verifiable executation environment that can be verified by a remote party in a distributed application. Nothing more, and nothing less. You decide what applications you trust and which ones you want to run. On a hardware box with trusted platform support, you could (a) opt out entirely and it would work just like today's computers, (b) run only one or two trusted applications and leave the rest of the system open to tinkering and modification, (c) dual-boot between a trusted and traditional system, or (d) have a completely locked down box. The main point being, this choice is entirely up to you, and the hardware will let you make whatever choice you want.
Is is also possible to make an operating system such that, if you chose to run that O.S. then it would only allow programs that some external party has said are OK, and you wouldn't be allowed to modify anything or run any of your own applications. You seem to be hung up on this, thinking it's inevitable, even though all the plans that have been announced about using trusted platforms say specifically that they're not going to do this.
Here's something to ponder about that: It is entirely possible to do a decent job of creating a system like that today, even with no hardware support. The system is still ultimately hackable without hardware support, but it can be made very, very difficult. And yet, such protections exist in only a few places: online game verification and DRM are two that come to mind. Ever wonder why they don't do this system-wide, even though they clearly could? Because it doesn't make sense, and wouldn't be accepted by the public at large. That won't change at all with the introduction of trusted platforms -- it isn't a workable system now, and it won't be in the future either.
Microsoft could set it up so that it is very difficult for anyone else to connect to a Windows file server except for a Windows client. But they haven't. In fact, they've put the file sharing protocol through an open standards process, and it's out there as CIFS (the Common Internet File System) and freely available to all. They encourage this interoperability, and don't try to make it impossible. Another example: despite your claim earlier, Microsoft has not tried to make the MS Word.DOC file format unusable by others, such as OpenOffice. They clearly could do that, locking it down similar to the protections on media files made by their DRM system. But they haven't. They haven't been terribly cooperative in making sure there was interoperability, but they haven't tried to stop it either.
So I think you're just a little on the paranoid side when you go off into ravings about how this will lock everything up and lead to control over computers and/or the Internet. Neither the publicly stated plans of the companies nor the history of their actions supports your beliefs at all on this.
Your inability to follow the technical issues and to understand how certain isolated applications could be trusted while the vast majority of the system is open to tinkering and modification probably colors your view of the control companies will have over trusted platforms.
And I think I'll leave it at that. Unless you reply with something that I really just can't pass up responding to, that's it for me.
Well, this is getting tiresome. You still don't seem to have a grasp on the technical issues of trusted platforms. When I point out that you're mistaken, on simple and easily verifiable facts, you say things like: "you were simply attempting to create deliberately false impressions of how things are supposed to work". The only reason you find these to be "false impressions" is because they disagree with your own notions of how you think things work. Has it not even crossed your mind to consider that this is because it is your notions that are incorrect? Because that's the case.
I will point out that one of the things that has changed over the last few years is that the TCG has gotten much more open. A few years ago (when they were called the "Trusted Computing Platform Alliance), they were incredibly closed and secretive, as was Microsoft with what was then known as the Palladium project. That's probably what caused a lot of the original scare, because people were speculating about things they didn't have information on. However, since that time they have become very transparent. The full and detailed technical specs are on the TCG web site -- everything from the TPM functionality spec to the hardware interface to the PC BIOS and higher level software issues (the trusted software stack). You don't even have to register to get the stuff. Unfortunately, it is many hundreds of pages specifications, which if you've ever read through can be not a terribly thrilling thing to read. However, I have read the specs, and you could learn something what I've written, but you keep going off on odd tangents because of your misconceptions, and so I'm not sure you've learned much of anything. There are also some books out there, one by some people with HP and one by Sean Smith of Dartmouth, but I have to say that these aren't the most stellar examples of clear writing that I've ever seen.
I'm only going to respond to a few things here, which I think are either your better points or your more serious misunderstandings. Going around in circles like this isn't a particularly good use of anyone's time....
A real Black Hat would use the modified malloc() to allocate memory blocks outside the protected memory area and then manipulate them.
So one misunderstanding is that apparently you think the TCG members are complete idiots and would leave the design to allow something like this. They're not, and this wouldn't be possible. A trusted app would either handle it's own memory allocation (statically linked) or use a trusted library [Hmmm.. that sounds familiar... maybe because I said this in an earlier posting too -- maybe you weren't paying attention]. It wouldn't use your modified malloc(). I'll also point out that the fact that a trusted app needs a trusted library doesn't in any way stop you from having your own completely hacked up libc for use in untrusted apps, which would work exactly as they do now. I have "compatibility libraries" installed on my system right now because some apps require different versions of libraries. That's the same basic idea.
This is also one place where the Microsoft design and the more simple TCG design differ. In the TCG design, you would be required to run an OS that didn't allow you modify the kernel memory management code. Now stop your ranting -- that could be a Linux kernel or a Windows kernel or a FreeBSD kernel -- but the kernel does have to be able to enforce the protected memory area. The Microsoft design, on the other hand, adds extra hardware to provide additional hardware isolation of memory regions, so that existing operating systems (Windows is what they're worried about of course) wouldn't have to be modified or restricted at all.
If the TPM is not verifying the signatures of the processes it is asked to load, what is to stop me, the evil hacker, from loading a completely fake, but skillfully crafted client which would take over the entire process of communication with the other people's clients, while r
You are new to this Black Hat hacking gig, aren't you? DOS attack?! How about a fancy version of malloc() or memcpy()? What about fopen() or fread()? Bye bye goes the integrity of the P2P client, unless it has a whole duplicate OS embedded in it, complete with its own custom filesystem and storage device drivers.
New to this? No. I'd bet I was doing this kind of stuff before you were even born. But you're right: you can indeed make the P2P client go bye bye. That's what I meant by a DoS attack. But it can't do any damage to the rest of the P2P network. That one client will simply stop working and being an active participant in the network.
Really? How would you then "certify" my signature for my funky new P2P package? Clearly I cannot make it up myself for any hacker could do it too, pretending he is me. Someone has to arbitrate between us. Like Verisign and Thawte do for SSL certificates, or PGP servers do for PGP signatures. Except that now there is a secret hardware key involved not accessible to anyone but the TC consortium. And they do not do it for free.
AAAG! How many times have I said this? No one has to "certify" your signature. The only thing that's necessary is that I'm (me, not the TPM) convinced that I've got an authentic public key for you. Who certifies the Fedora keys now? Answer: No one. It exactly the same. I trust them because I trust the channel I got them through. Once again for emphasis: it will be exactly the same with a TPM.
And to get to the keys again -- yes, the hardware key is certified by some authority. And no, they don't do it for free. It's all of a dollar or two. Yes, literally. The entire cost of a TPM, with an embedded, certified endorsement key, is a few bucks. You can, right now, go get an Intel motherboard from Newegg that is very modern, with an Intel D945 chipset and a TPM, for $126. The TPM is a tiny piece of that.
And once you've done that, you've got the endorsement key. You can have a fully functional trusted platform, and never have even a single other interaction with the TCG. No software maker has to have any interaction with the TCG. The TCG is completely out of the picture once you buy the TPM from one of their members.
That means free software makers, would have to submit their certificates for signing to some TC consortium who happens to know the secret private key embedded in the TPM, so that the TPM can verify the authenticity of the signature, no?
No. No one has to submit anything to any TC consortium member. I've said that over and over, and I'm honestly not sure why you don't believe this. And in fact, no one, not even the TC consortium, knows the private key embedded in the TPM. That would pretty much violate the whole model.
What about if that embedded, super-secret, private hardware key gets compromised? You get to have a mandatory update of your hardware or throw away your PC, which would be a brilliant corollary to this idiotic TPM scheme, no?
That much is true. If your private key is somehow compromised, that would mean the hardware has been compromised, and so if this was known then your endorsement key would be revoked. Then yes, you'd need to get a new system (or at least a new motherboard) if you wanted to be recognized as a valid trusted platform. Any thoughts on how your private key would be compromised? I guarantee it wouldn't be an easy thing to do.
Which implies that you have no clue how this whole Linux community thing works. Variety and freedom of choice are the key elements here. Anything that runs on a particular version of glibc on Fedora and does not run on home glued derivative of Debian is not acceptable to Linux community. Period.
Oh, bull. That's just silly. Any idea how many people use "home glued" versions of libc? It would be in the hundredths of one percent of Linux users. I've been part of the "whole Linux community thing" since the early pre-1.0 kernels, and yes I under
If you were a true scientist, you would realize that what counts is an ability to logically prove your point.
Actually, I have proved my point, many times over. You don't realize it because it contradicts your concept of what trusted platforms do and how they work, so you think it's B.S. The contradiction is there, but only because it is your concept of trusted platforms that's wrong.
As I pointed out already, this would not work on its own without a complete host OS lockdown. For the "isolated" process would have to still make OS calls (most likely via system library ones) and thus be exposed to a hacker poisoning/manipulating those.
Yes, you're right -- the isolated process does make OS calls. Standard OS calls through a standard OS interface and through potentially untrusted software. Yes, those calls are subject to manipulation, and in fact I have already said exactly this when I pointed out that you (outside the isolated process) have complete control over the inputs and outputs of that process. So in the P2P example, when the trusted process asks the OS to send a certain packet to 1.2.3.4 it could indeed be intercepted and be sent to 10.20.30.40 instead. Or it could in fact just throw out the packet altogether. The effect of both of those is basically a denial-of-service attack, which trusted platforms are vulnerable to, exactly like this.
It does not take him more then a few sentences to contradict himself. So which is it? Does the TPM have no key or does it have "a key for my hardware" (externally certified, no less)?
Sigh. If you're going to argue with me, at least try to pay attention to what I say. I have said (repeatedly) that trusted platforms don't depend on software signatures or certified keys for software. They do depend (quite strongly) on keys for the hardware, and in particular for what called an "endorsement key" for the TPM. This is what I've been saying all along. If you have a TPM you have an endorsement key, independent of whatever operating system or other software you want to run. No need for anyone to approve any software you decide to run.
If the OS would be not completely and utterly locked down prior to this setup, I would be merrily feeding the P2P software fake files and what not via my own hand crafted "system" libraries.
So what? If you've gotten a file from a P2P network, and want to re-distribute it to the network, the P2P program would associate a cryptographic checksum with the file. Any attempt to modify the file you provide to the P2P program would be detected and not accepted. So the result is, once again, a DoS, but not a corrupted file or corrupted P2P network.
To prevent that, the P2P software would have to "certify" the libraries and the OS kernel, thus requiring that everyone under the sun has ones belonging to the same limited list, a list that TPM-based software can trust. Yes Dr. Weasel, that means no GPLed system kernel/libraries which have literally thousands of versions and can be patched or modified by the user (thus changing their signatures resulting in the P2P client's refusal to cooperate).
Yes, you're right about this -- the libraries and OS kernel would have to be ones that the P2P software has determined that it's OK running under. If you have your own custom libc, and the P2P software was designed so that it requires a certain certified libc (say the standard Fedora distribution libc), then the P2P software would refuse to run on such a system (or rather, it wouldn't be able to attest to its authenticity to remote systems). The options then are (a) you could make the P2P program statically linked to remove as many of these dependencies as possible, or (b) require everyone in the P2P network to use a certain system configuration. But let me stress once again, it's the P2P program that decides what resources it's sensitive to, and only works under those conditions. And it's you that decides whether you want to restrict yourself to th
Thanks for the kind words, Alan. The whole trusted platform issue has people so worked up that they unfortunately jump to a lot of conclusions based on very little information.
If you're ever out in this area again, stop by and visit. We've got a nice new building and research facility with new offices and labs. I'll give you the "grand tour"....
You simply have absolutely no idea how public key cryptography works nor how it is supposed to be applied in the context of Trusted Computing.
Gee, maybe I should go out and study some on the subject. Seriously, I haven't been the most polite in my postings to you, so I can forgive the rudeness, but just so you know a little more about who you're talking to, I am an expert in public key cryptography, and outside of the industry TCG people there are probably fewer than 10 people on the planet who understand trusted platforms as well as I do.
To get at some of your specific points:
If Bob self-signed the P2P client, as you suggested, all John has to do is to generate his own signature and post the modified P2P client somewhere on the web. If we are trusting the TPM to substitute for public PGP signature system (which is what you seem to suggest) then the entire certification process happens offline and thus the TPM chip, having the same keyset in both Bob's and John's computers, would be simply unable to tell the difference as to validity of the different signatures.
First, the TPM doesn't hold the keys. It can protect the integrity of the set of trusted public keys, but they are stored outside of the TPM. And the key misunderstanding here is in the statement about "the same keyset in both Bob's and John's computers". At some point, you would have had to obtain my public key, and enter it into your system as a trusted key. This works exactly as things do today -- I load in the Fedora distribution public key from their web site, mark it as trusted, and then my system accepts things signed by the corresponding private key. Once you've decided that you trust me (or more precisely my key), and have entered that into your system, then John is out of luck because he can't forge a signature using the key that I've said I trust. The only way a trusted platform differs from the current (non-TPM) methods for signed software distribution is that I can use the TPM to "seal" my set of trusted keys so they can't be tampered with. As it stands right now, someone could break into my system, and replace the Fedora public key (or just add new "trusted keys") -- it's just stored in a regular file (/etc/pki/rpm-gpg/RPM-GPG-KEY-fedora). That wouldn't be possible with a TPM-enabled system (or at least, it would be much, much harder).
In other words we get a convoluted version of PGP signature system with no gain of any kind as far as the verification of integrity is concerned.
Right. Very little gain in the signed software distribution phase -- we in fact have good techniques for this right now, as long as the set of trusted keys can be protected, which is why trusted platforms don't have any real new functionality as far as signed software. I said earlier that software signatures and keys for signing software really don't have anything to do with trusted platforms, but apparently you don't believe that for some reason.
If Bob indeed used a centralized authority, the TC consortium or its lackey, for an inevietable fee
The only benefit of having a central authority for authenticating keys would be if you were willing to trust someone else to determine what was safe software and what wasn't. For example, a lot of people will probably say they trust all software from Microsoft, but this is just another example of you (the user) deciding who you want to trust -- you can check all your software yourself, or you can specify that you trust someone (or multiple someones) to do that either in place of or in addition to you. But you're still in complete control of saying what you consider trusted, and what you don't consider trusted.
Additional possibilities present themselves: the P2P software could attempt encryption of the packets, using its certificates. Which is futile since the P2P software cannot guarantee that the packets are not modified by John, in-memory, before encryption. The only way that could happen is if th
That is only because the TPM in your present equipment is not used in the way which makes TPM anything close to functional.
Wrong. It's quite functional.
The very fact that your Thinkpad (I assume) still runs non-TPM authorized software, nixes the whole concept, right there, as that software can be used to do all sorts of stuff, including virtualization of the TPM hardware, for the purpose of circumventing it.
It does not nix anything at all, just shows that you don't really understand what TPMs do and how they are supposed to be used. There is absolutely no need to restrict software in any way, or to dis-allow "non-TPM authorized software". That's not the part of any present of planned technology (but it doesn't stop people from mis-representing it this way). I can indeed simulate the TPM hardware entirely, and have in fact worked on software which does exactly that. The only thing missing is that I don't have access to a proper private key (or more accurately to a certificate for the corresponding public key). And, once again, for proper functioning of a trusted platform, there is no need -- and no plan for that matter -- to restrict non-TPM software at all. If you look at Microsoft's NGSCB design (which is more restrictive than the TCG design), even they show quite clearly that they have "untrusted software" running side-by-side with "trusted software."
for a platform to be "trusted" by people other then the owner of the computer (regardless of its "collaborative" merits), that person, not the purported owner, has to have complete control over the functions of the said computer and to be able to severely restrict the types of operations allowed
That's just completely and totally wrong. In the example of the trusted peer-to-peer network that I gave before, I'm not giving control over any part of my computer other than the one process that is the peer-to-peer software. And while I do have to give control in the sense that I allow exactly and precisely that software to run, I completely control what that process has access to, so I'm not turning over control to something that could perform actions I don't want (like accessing files outside my file sharing area, for example).
In your inane examples, for the "collaborative" system to work, the members of the P2P network would have to all relinquish control of their computers to some other party whom they all "trust" implicitely, unquestioningly, unconditionally and completely.
No, again that's entirely incorrect. First, in a trusted platform, you would never, ever give any control whatsoever to "some other party." Software, yes. Party, no. That means that I could produce an open source P2P package, which is carefully audited by anyone who wants to, and then people can say whether they want to trust that software on their machine. But guess what? People do that already -- any time you install and run a piece of software, you've turned over control to that software. It is not even a single iota of "extra control" that you're giving up when you do the same thing on a trusted platform. But you (as well as the people you interact with) are simply getting a strong assurance that this software hasn't been tampered with and is running un-impeded.
A Dear Leader or Big Brother of some kind.
Or a Linus Torvalds -- I give control of my computers over to his software every day. Anything scare you about that? How is it possibly any different here?
the globe-spanning consortium of Trusted Computing founding conglomerates, holding all the digital keys to the equipment and throttling the funcionality.
Yep, they control the keys (or the certificates). They don't control or throttle any functionality at all.
That consortium of course deciding whose software is allowed to run and extracting a licence fee for the issuance of appropriate keys after the software and its maker have been deemed "acceptable" to them.
Hmmm... I didn't notice your pseudonym before. Maybe you're just playing a personna and trying to sound as ignorant as possible?
Anyway, to your final questions: You are precisely correct that secure DRM is impossible without TPM-like technology, and that TPMs will enable the ability to make secure DRM. I never said anything that would contradict that.
My point was that TPMs also enable many other very useful things. And even with a TPM chip in your system, YOU have full control over what applications you run or don't run. I have two systems with TPM chips in them. One is the laptop I'm typing on right now, and the other is a desktop system with an Intel motherboard. Both run Linux, both allow me to run any and all programs that I can run on non-TPM systems. It restricts absolutely nothing. I can rip CDs, listen to my MP3s, etc., etc. Open source software will ALWAYS be able run on any system that implements the TCG specifications. And in fact, it will still run on all systems that implement Microsoft's more powerful NGSCB ideas.
Your dismissal of the importance of being able to build trust in distributed, collaborative settings reminds me of people who think anarchy is a workable society. It isn't, and most people realize this by the time they leave their teen years. And the ability to build trust allows you to do things that you simply wouldn't be able to do otherwise.
I find it so amusing when people get so worked up about this. And I love the irony that many of the same people who scream about the evils of "Treacherous Computing" are exactly the same people who, when the topic is changed to peer-to-peer technologies and the RIAA efforts against those, make the argument that you shouldn't argue against a technology just because it has some bad uses.
Your own very examples of "positive" use of DRM were.... all about the "contents producer"
First, I didn't use even a single example of DRM. Perhaps you don't understand what DRM is. The two main examples I used were examples of building trust amongst a group of users who are trying to do something in a distributed, collaborative setting. They had zip to do with "content." Second, think about any group setting and the fact that for almost any group activity, you do accept restrictions on doing whatever you please. It's not about "fighting the man" or being subjugated by a stronger power -- it's about allowing groups of users to have a functional setup where they can trust each other.
It seems that you cannot even keep your appologisms for the DRM guild internally consistent
My views are entirely consistent, and hardly "appologisms" -- and as far as that goes I can absolutely guarantee you that my anti-DRM credentials put yours to shame.
You know, for a technology that's starting to be quite wide-spread, it's amazing the amount of mis-information spread about trusted platforms -- by both the pro and the con side. I've worked quite a bit with the technology, and it's not all THAT complicated.
Over-stating what a TPM can do is common from the pro-trusted computing industry. Statements like "It should prevent the phone world from being hit by the same virus and hacking issues that face computers" are just ridiculous (I saw a press release one time that claimed they'd protect people from phishing too!).
Simply put, a TPM does nothing -- nada, zilch -- to prevent viruses or external threats that you can't do in software with no hardware trusted platform additions. OK, you might make the argument that you're just adding another layer for defense in depth, but how about making the software better in the first place?
The only -- yes, only -- extra capability given by a TPM is the ability to protect from local attacks. Meaning attacks from people with physical control over the hardware. Now before the "anti" side runs off and raves about how the TCG is trying to take over their computer, keep in mind that (a) it's optional and (b) there are applications where this makes complete sense. Ignore the DRM side of the issue, and there are still good applications. Imagine playing on-line games and having some assurance that your opponents aren't using hacked up clients that allow them to cheat. Imagine connecting to a peer-to-peer network where the peer you're connecting to can give assurance that it's not a hacked, fake RIAA node. For the cell phone, the obvious point is that it makes cell phone cloning exteremely difficult. None of those are bad things.
If you don't like DRM, then don't accept stores or software that enforce it. And don't mistake every single issue as content providers trying to restrict what you can do.
While my comments were meant in jest, the slight bit of seriousness there seems to have been mistaken 100%.
I love different food. I don't like bland and over-fatty food. Yes, I've had "bangers and mash" in London, and have had many kinds of British cheddar. Neither are exactly the height of culinary excellence. 'course I don't touch Velveeta with a stick, and only my kids eat Oscar Mayer. Personally, I prefer French cheeses, and just am not a big sausage fan (refer back to the "over-fatty" statement above).
As an Expat I am sick of people saying that Britain is a lousy place, with lousy weather, food, beer, women etc.
No, no, no. No one has claimed the beer is lousy. In fact, the beer is excellent. I figure it's the only way you guys can deal with the weather, food, and women...
And then you "counter" criticism of the food by mentioning.... British cheeses, sausages, yorkshire pudding, and meat pies???? 'scuse me, but which side of this argument are you trying to take?
You're not paying the IRS anything, as far as I know. You're paying the TaxACT people, who developed the web app and maintain and support the web site.
Check out TaxACT. The basic "fill in the forms" version is free -- you print the resulting forms and mail them in, and it doesn't cost you anything. You can e-file for $7.95. No, it's not free, but come on -- under $8? You can barely see a movie for that these days.
The deluxe edition is only $9.95, and it is more thorough if you have things that can give you tax breaks. I'm doing the deluxe version this year, but did the standard one last year -- I started out thinking I'd print and just do it for free, but then realized that the convenience of e-file for $8 really can't be beat...
Since it's web-based, it works fine from Linux. One problem I had (and I've had with another web site as well): for some bizarre reason, the first screen, with the user agreement, looked entirely blank -- it was really just white text rendered on a white background. Strange. It came up fine in konqueror and firefox though, and once you get past that first screen everything seems to work fine in Mozilla (it did force me to install Firefox though, which is actually a good thing).
Anyway, sorry to sound like an ad, but I like it, and I like that I can use it under Linux. It gives my sense of privacy a bit of the willies, but I think you're pretty well protected by law as far as that goes...
Just until the BIOS uses Treacherous Computing to determine wether you're launching an approved operating system.
The BIOS can already do this, with or without the extra hardware. The BIOS is in complete control until it passes off control to your boot loader. If they wanted to give monopoly control to one OS, they could do that now, without any problems at all.
So the TPM offers no additional abilities in this regard. What does it do? Well, it can "seal" data to a particular configuration -- in other words, it can encrypt data so that it can only be decrypted if you're running the "right" OS and the "right" applications. But you are always in control of what is "right". If you want to seal your PGP keys to a Linux configuration so that it can only be opened when running Evolution under Linux, you can do that. If Microsoft wants to seal data so that it can only be opened when running their "trusted" version of Windows while it's running the Windows Media Player, they can do that. Or lock a.doc file to MS word (so there's no way it could be opened by OpenOffice, for instance) -- that they can do.
But again, you're in complete control with the way the hardware is currently designed. The only real danger comes when content (music, software, documents, whatever) comes locked to a particular configuration. Then your only choice is to use that configuration, or do the Nancy Reagan and "just say no." Personally, I'd just say no to most things like this, but if you don't think something along these lines (technically) isn't inevitable, then you're dreaming....
The MD5 hash collision that was also reported took several orders of magnitude less work than 80000 CPU hours. If you believe them, it took only a little over one hour (on an IBM P690 -- sorry, don't know exactly what that is) to find the (almost) MD5 collision. That's a very practical attack.
And if you look at my example, there was a part with meaningless, random gibberish (the "confirmation number"). This is the only part that needs to be manipulated, and since it's random it doesn't have to be a "meaningful message."
Yes, you're right. Most protocols these days have both sides generate a random nonce, for a variety of reasons. If Joe adds his own randomly chosen junk to the message, then we're down to what the original poster listed as the second kind of attack, which is certainly much harder. But just because that's the way all good protocols work doesn't mean that's the way they do. Imagine a case where I send you a contract, and say "sign this if you agree." Would an "average Joe":-) think to add random junk at the end?
You can sign an entire message rather than just its hash. It's certainly possible to just sign hashes too and that saves tons of space, but signing the full message is an option.
Of course you can do this, but the question is what do people actual do. In every single case I know of where digital signatures are actually used (including X.509 certificates, signed e-mail, etc.) it's a hash that's signed. For this to be secure, both the hash and the signature method has to be secure. If people just discovered a way to break the hash, then they can potentially break such a system.
First step is MATCHING some checksums (this has been done)
The next step is CHOOSING the chekcsum (aka DEADBEEF attack)
The next step is MANIPULATING, i.e. adding junk to a given binary file to allow you to choose the cheksum. that's the scary one!
Actually, you can do interesting and dangerous things with variants of your first step, not even progressing to step two. The MD5 collisions (well, almost collisions) are largely the same input data that has differences in only a few places. Now imagine that I have two messages that say something like this:
"Joe will send Dr. Blue $10. Confirmation number 1234567."
"Joe will send Dr. Blue $100000. Confirmation number 6451234."
Now lets say I can manipulate the confirmation numbers in those two messages so that they have the same hash value -- I don't care what the hash is, as long as it's the same in both cases. Then I send you the $10 message.
If you agree, you sign it. But you realize that digital signatures don't actually sign the message, right? They sign the hash of the message, so I can later produce the $100000 message, with your signature, and it will verify that you signed that message!
There's an arcade version of Tux Racer -- there's one in our local Chuckie Cheese. Surely they wouldn't commit the sin of putting Tux Racer on a Windows-based arcade platform, would they? Makes me think the claim of these people to be "the first" may not be 100% accurate.
At least NetZero is still offering free dialup, albeit limited. I use NetZero when I'm traveling and don't have other options (high-speed internet in the hotel, for instance).
You're limited to 10 hours/month in the free service, but really -- if you need it more than that you should be willing to pay for service. I've never used even half of that....
A lot of people seem to think income tax rates are much higher than they are. Here's the real info: a family of 4 (what the original poster described) making $45K per year, taking just the simple standard deduction pays a whopping $799 in federal income taxes. There's an additional $3442 in FICA, even assuming that NONE of the $45K is pre-tax (which it almost surely is). That means the total federal tax bill is $4241. To get up to $15K in taxes, California would have to take out over $10,000.
I've never lived in California, but I can't believe that they take out anywhere near that (my own state income tax is $0, but Texas is nice that way!). Even if CA took as big a bite as the federal government, you've got about $8K in total federal and state payroll taxes, which is about half of what you estimated....
Slashdot Mirror
Yes, that looks like a fantastic piece of legislation -- it basically says that the DMCA can't outlaw actions which don't infringe copyright (which now it does, since any "circumvention" is deemed illegal, whether the resulting copying was or was not allowed by copyright law), which if frankly common sense. And the bigger part of the bill says that copyprotected disks have to be clearly labeled as such -- gee, you have to present your product honestly, how controversial can that be?
Anyway, I'd personally like to see this taken further -- that the law should guarantee that companies don't use technological measures to take away fair use acts. Saying circumvention is OK is a baby step, but why should we be required to hack something in order to re-gain our rights? Unfortunately, I don't see such a bill having a snowballs chance of making it through Congress, where common-sense isn't in great supply.
And there's the most fundamental difference. I personally see the technology as potentially very empowering, and in fact increasing Liberty for the users. You believe the exact opposite. And that's why we'll probably never see eye-to-eye on this, but maybe in another 20 years we can compare notes.
I'm done with the point by point responses -- this really isn't making any progress at all. That you can't seem to follow what I'm saying, and say that you've read other publications on trusted platforms and find them "self-contradictory and obfusatory", really says a lot more about your ability to grasp the facts than it does about my explanations or the documentation that's out there (some of which is pretty good, in fact).
.DOC file format unusable by others, such as OpenOffice. They clearly could do that, locking it down similar to the protections on media files made by their DRM system. But they haven't. They haven't been terribly cooperative in making sure there was interoperability, but they haven't tried to stop it either.
The bottom line is this: Trusted platforms allow you to have a verifiable executation environment that can be verified by a remote party in a distributed application. Nothing more, and nothing less. You decide what applications you trust and which ones you want to run. On a hardware box with trusted platform support, you could (a) opt out entirely and it would work just like today's computers, (b) run only one or two trusted applications and leave the rest of the system open to tinkering and modification, (c) dual-boot between a trusted and traditional system, or (d) have a completely locked down box. The main point being, this choice is entirely up to you, and the hardware will let you make whatever choice you want.
Is is also possible to make an operating system such that, if you chose to run that O.S. then it would only allow programs that some external party has said are OK, and you wouldn't be allowed to modify anything or run any of your own applications. You seem to be hung up on this, thinking it's inevitable, even though all the plans that have been announced about using trusted platforms say specifically that they're not going to do this.
Here's something to ponder about that: It is entirely possible to do a decent job of creating a system like that today, even with no hardware support. The system is still ultimately hackable without hardware support, but it can be made very, very difficult. And yet, such protections exist in only a few places: online game verification and DRM are two that come to mind. Ever wonder why they don't do this system-wide, even though they clearly could? Because it doesn't make sense, and wouldn't be accepted by the public at large. That won't change at all with the introduction of trusted platforms -- it isn't a workable system now, and it won't be in the future either.
Microsoft could set it up so that it is very difficult for anyone else to connect to a Windows file server except for a Windows client. But they haven't. In fact, they've put the file sharing protocol through an open standards process, and it's out there as CIFS (the Common Internet File System) and freely available to all. They encourage this interoperability, and don't try to make it impossible. Another example: despite your claim earlier, Microsoft has not tried to make the MS Word
So I think you're just a little on the paranoid side when you go off into ravings about how this will lock everything up and lead to control over computers and/or the Internet. Neither the publicly stated plans of the companies nor the history of their actions supports your beliefs at all on this.
Your inability to follow the technical issues and to understand how certain isolated applications could be trusted while the vast majority of the system is open to tinkering and modification probably colors your view of the control companies will have over trusted platforms.
And I think I'll leave it at that. Unless you reply with something that I really just can't pass up responding to, that's it for me.
I will point out that one of the things that has changed over the last few years is that the TCG has gotten much more open. A few years ago (when they were called the "Trusted Computing Platform Alliance), they were incredibly closed and secretive, as was Microsoft with what was then known as the Palladium project. That's probably what caused a lot of the original scare, because people were speculating about things they didn't have information on. However, since that time they have become very transparent. The full and detailed technical specs are on the TCG web site -- everything from the TPM functionality spec to the hardware interface to the PC BIOS and higher level software issues (the trusted software stack). You don't even have to register to get the stuff. Unfortunately, it is many hundreds of pages specifications, which if you've ever read through can be not a terribly thrilling thing to read. However, I have read the specs, and you could learn something what I've written, but you keep going off on odd tangents because of your misconceptions, and so I'm not sure you've learned much of anything. There are also some books out there, one by some people with HP and one by Sean Smith of Dartmouth, but I have to say that these aren't the most stellar examples of clear writing that I've ever seen.
I'm only going to respond to a few things here, which I think are either your better points or your more serious misunderstandings. Going around in circles like this isn't a particularly good use of anyone's time....
A real Black Hat would use the modified malloc() to allocate memory blocks outside the protected memory area and then manipulate them.
So one misunderstanding is that apparently you think the TCG members are complete idiots and would leave the design to allow something like this. They're not, and this wouldn't be possible. A trusted app would either handle it's own memory allocation (statically linked) or use a trusted library [Hmmm.. that sounds familiar... maybe because I said this in an earlier posting too -- maybe you weren't paying attention]. It wouldn't use your modified malloc(). I'll also point out that the fact that a trusted app needs a trusted library doesn't in any way stop you from having your own completely hacked up libc for use in untrusted apps, which would work exactly as they do now. I have "compatibility libraries" installed on my system right now because some apps require different versions of libraries. That's the same basic idea.
This is also one place where the Microsoft design and the more simple TCG design differ. In the TCG design, you would be required to run an OS that didn't allow you modify the kernel memory management code. Now stop your ranting -- that could be a Linux kernel or a Windows kernel or a FreeBSD kernel -- but the kernel does have to be able to enforce the protected memory area. The Microsoft design, on the other hand, adds extra hardware to provide additional hardware isolation of memory regions, so that existing operating systems (Windows is what they're worried about of course) wouldn't have to be modified or restricted at all.
If the TPM is not verifying the signatures of the processes it is asked to load, what is to stop me, the evil hacker, from loading a completely fake, but skillfully crafted client which would take over the entire process of communication with the other people's clients, while r
New to this? No. I'd bet I was doing this kind of stuff before you were even born. But you're right: you can indeed make the P2P client go bye bye. That's what I meant by a DoS attack. But it can't do any damage to the rest of the P2P network. That one client will simply stop working and being an active participant in the network.
Really? How would you then "certify" my signature for my funky new P2P package? Clearly I cannot make it up myself for any hacker could do it too, pretending he is me. Someone has to arbitrate between us. Like Verisign and Thawte do for SSL certificates, or PGP servers do for PGP signatures. Except that now there is a secret hardware key involved not accessible to anyone but the TC consortium. And they do not do it for free.
AAAG! How many times have I said this? No one has to "certify" your signature. The only thing that's necessary is that I'm (me, not the TPM) convinced that I've got an authentic public key for you. Who certifies the Fedora keys now? Answer: No one. It exactly the same. I trust them because I trust the channel I got them through. Once again for emphasis: it will be exactly the same with a TPM.
And to get to the keys again -- yes, the hardware key is certified by some authority. And no, they don't do it for free. It's all of a dollar or two. Yes, literally. The entire cost of a TPM, with an embedded, certified endorsement key, is a few bucks. You can, right now, go get an Intel motherboard from Newegg that is very modern, with an Intel D945 chipset and a TPM, for $126. The TPM is a tiny piece of that. And once you've done that, you've got the endorsement key. You can have a fully functional trusted platform, and never have even a single other interaction with the TCG. No software maker has to have any interaction with the TCG. The TCG is completely out of the picture once you buy the TPM from one of their members.
That means free software makers, would have to submit their certificates for signing to some TC consortium who happens to know the secret private key embedded in the TPM, so that the TPM can verify the authenticity of the signature, no?
No. No one has to submit anything to any TC consortium member. I've said that over and over, and I'm honestly not sure why you don't believe this. And in fact, no one, not even the TC consortium, knows the private key embedded in the TPM. That would pretty much violate the whole model.
What about if that embedded, super-secret, private hardware key gets compromised? You get to have a mandatory update of your hardware or throw away your PC, which would be a brilliant corollary to this idiotic TPM scheme, no?
That much is true. If your private key is somehow compromised, that would mean the hardware has been compromised, and so if this was known then your endorsement key would be revoked. Then yes, you'd need to get a new system (or at least a new motherboard) if you wanted to be recognized as a valid trusted platform. Any thoughts on how your private key would be compromised? I guarantee it wouldn't be an easy thing to do.
Which implies that you have no clue how this whole Linux community thing works. Variety and freedom of choice are the key elements here. Anything that runs on a particular version of glibc on Fedora and does not run on home glued derivative of Debian is not acceptable to Linux community. Period.
Oh, bull. That's just silly. Any idea how many people use "home glued" versions of libc? It would be in the hundredths of one percent of Linux users. I've been part of the "whole Linux community thing" since the early pre-1.0 kernels, and yes I under
Actually, I have proved my point, many times over. You don't realize it because it contradicts your concept of what trusted platforms do and how they work, so you think it's B.S. The contradiction is there, but only because it is your concept of trusted platforms that's wrong.
As I pointed out already, this would not work on its own without a complete host OS lockdown. For the "isolated" process would have to still make OS calls (most likely via system library ones) and thus be exposed to a hacker poisoning/manipulating those.
Yes, you're right -- the isolated process does make OS calls. Standard OS calls through a standard OS interface and through potentially untrusted software. Yes, those calls are subject to manipulation, and in fact I have already said exactly this when I pointed out that you (outside the isolated process) have complete control over the inputs and outputs of that process. So in the P2P example, when the trusted process asks the OS to send a certain packet to 1.2.3.4 it could indeed be intercepted and be sent to 10.20.30.40 instead. Or it could in fact just throw out the packet altogether. The effect of both of those is basically a denial-of-service attack, which trusted platforms are vulnerable to, exactly like this.
It does not take him more then a few sentences to contradict himself. So which is it? Does the TPM have no key or does it have "a key for my hardware" (externally certified, no less)?
Sigh. If you're going to argue with me, at least try to pay attention to what I say. I have said (repeatedly) that trusted platforms don't depend on software signatures or certified keys for software. They do depend (quite strongly) on keys for the hardware, and in particular for what called an "endorsement key" for the TPM. This is what I've been saying all along. If you have a TPM you have an endorsement key, independent of whatever operating system or other software you want to run. No need for anyone to approve any software you decide to run.
If the OS would be not completely and utterly locked down prior to this setup, I would be merrily feeding the P2P software fake files and what not via my own hand crafted "system" libraries.
So what? If you've gotten a file from a P2P network, and want to re-distribute it to the network, the P2P program would associate a cryptographic checksum with the file. Any attempt to modify the file you provide to the P2P program would be detected and not accepted. So the result is, once again, a DoS, but not a corrupted file or corrupted P2P network.
To prevent that, the P2P software would have to "certify" the libraries and the OS kernel, thus requiring that everyone under the sun has ones belonging to the same limited list, a list that TPM-based software can trust. Yes Dr. Weasel, that means no GPLed system kernel/libraries which have literally thousands of versions and can be patched or modified by the user (thus changing their signatures resulting in the P2P client's refusal to cooperate).
Yes, you're right about this -- the libraries and OS kernel would have to be ones that the P2P software has determined that it's OK running under. If you have your own custom libc, and the P2P software was designed so that it requires a certain certified libc (say the standard Fedora distribution libc), then the P2P software would refuse to run on such a system (or rather, it wouldn't be able to attest to its authenticity to remote systems). The options then are (a) you could make the P2P program statically linked to remove as many of these dependencies as possible, or (b) require everyone in the P2P network to use a certain system configuration. But let me stress once again, it's the P2P program that decides what resources it's sensitive to, and only works under those conditions. And it's you that decides whether you want to restrict yourself to th
Thanks for the kind words, Alan. The whole trusted platform issue has people so worked up that they unfortunately jump to a lot of conclusions based on very little information.
If you're ever out in this area again, stop by and visit. We've got a nice new building and research facility with new offices and labs. I'll give you the "grand tour"....
Gee, maybe I should go out and study some on the subject. Seriously, I haven't been the most polite in my postings to you, so I can forgive the rudeness, but just so you know a little more about who you're talking to, I am an expert in public key cryptography, and outside of the industry TCG people there are probably fewer than 10 people on the planet who understand trusted platforms as well as I do.
To get at some of your specific points:
If Bob self-signed the P2P client, as you suggested, all John has to do is to generate his own signature and post the modified P2P client somewhere on the web. If we are trusting the TPM to substitute for public PGP signature system (which is what you seem to suggest) then the entire certification process happens offline and thus the TPM chip, having the same keyset in both Bob's and John's computers, would be simply unable to tell the difference as to validity of the different signatures.
First, the TPM doesn't hold the keys. It can protect the integrity of the set of trusted public keys, but they are stored outside of the TPM. And the key misunderstanding here is in the statement about "the same keyset in both Bob's and John's computers". At some point, you would have had to obtain my public key, and enter it into your system as a trusted key. This works exactly as things do today -- I load in the Fedora distribution public key from their web site, mark it as trusted, and then my system accepts things signed by the corresponding private key. Once you've decided that you trust me (or more precisely my key), and have entered that into your system, then John is out of luck because he can't forge a signature using the key that I've said I trust. The only way a trusted platform differs from the current (non-TPM) methods for signed software distribution is that I can use the TPM to "seal" my set of trusted keys so they can't be tampered with. As it stands right now, someone could break into my system, and replace the Fedora public key (or just add new "trusted keys") -- it's just stored in a regular file (/etc/pki/rpm-gpg/RPM-GPG-KEY-fedora). That wouldn't be possible with a TPM-enabled system (or at least, it would be much, much harder).
In other words we get a convoluted version of PGP signature system with no gain of any kind as far as the verification of integrity is concerned.
Right. Very little gain in the signed software distribution phase -- we in fact have good techniques for this right now, as long as the set of trusted keys can be protected, which is why trusted platforms don't have any real new functionality as far as signed software. I said earlier that software signatures and keys for signing software really don't have anything to do with trusted platforms, but apparently you don't believe that for some reason.
If Bob indeed used a centralized authority, the TC consortium or its lackey, for an inevietable fee
The only benefit of having a central authority for authenticating keys would be if you were willing to trust someone else to determine what was safe software and what wasn't. For example, a lot of people will probably say they trust all software from Microsoft, but this is just another example of you (the user) deciding who you want to trust -- you can check all your software yourself, or you can specify that you trust someone (or multiple someones) to do that either in place of or in addition to you. But you're still in complete control of saying what you consider trusted, and what you don't consider trusted.
Additional possibilities present themselves: the P2P software could attempt encryption of the packets, using its certificates. Which is futile since the P2P software cannot guarantee that the packets are not modified by John, in-memory, before encryption. The only way that could happen is if th
Wrong. It's quite functional.
The very fact that your Thinkpad (I assume) still runs non-TPM authorized software, nixes the whole concept, right there, as that software can be used to do all sorts of stuff, including virtualization of the TPM hardware, for the purpose of circumventing it.
It does not nix anything at all, just shows that you don't really understand what TPMs do and how they are supposed to be used. There is absolutely no need to restrict software in any way, or to dis-allow "non-TPM authorized software". That's not the part of any present of planned technology (but it doesn't stop people from mis-representing it this way). I can indeed simulate the TPM hardware entirely, and have in fact worked on software which does exactly that. The only thing missing is that I don't have access to a proper private key (or more accurately to a certificate for the corresponding public key). And, once again, for proper functioning of a trusted platform, there is no need -- and no plan for that matter -- to restrict non-TPM software at all. If you look at Microsoft's NGSCB design (which is more restrictive than the TCG design), even they show quite clearly that they have "untrusted software" running side-by-side with "trusted software."
for a platform to be "trusted" by people other then the owner of the computer (regardless of its "collaborative" merits), that person, not the purported owner, has to have complete control over the functions of the said computer and to be able to severely restrict the types of operations allowed
That's just completely and totally wrong. In the example of the trusted peer-to-peer network that I gave before, I'm not giving control over any part of my computer other than the one process that is the peer-to-peer software. And while I do have to give control in the sense that I allow exactly and precisely that software to run, I completely control what that process has access to, so I'm not turning over control to something that could perform actions I don't want (like accessing files outside my file sharing area, for example).
In your inane examples, for the "collaborative" system to work, the members of the P2P network would have to all relinquish control of their computers to some other party whom they all "trust" implicitely, unquestioningly, unconditionally and completely.
No, again that's entirely incorrect. First, in a trusted platform, you would never, ever give any control whatsoever to "some other party." Software, yes. Party, no. That means that I could produce an open source P2P package, which is carefully audited by anyone who wants to, and then people can say whether they want to trust that software on their machine. But guess what? People do that already -- any time you install and run a piece of software, you've turned over control to that software. It is not even a single iota of "extra control" that you're giving up when you do the same thing on a trusted platform. But you (as well as the people you interact with) are simply getting a strong assurance that this software hasn't been tampered with and is running un-impeded.
A Dear Leader or Big Brother of some kind.
Or a Linus Torvalds -- I give control of my computers over to his software every day. Anything scare you about that? How is it possibly any different here?
the globe-spanning consortium of Trusted Computing founding conglomerates, holding all the digital keys to the equipment and throttling the funcionality.
Yep, they control the keys (or the certificates). They don't control or throttle any functionality at all.
That consortium of course deciding whose software is allowed to run and extracting a licence fee for the issuance of appropriate keys after the software and its maker have been deemed "acceptable" to them.
B
Hmmm... I didn't notice your pseudonym before. Maybe you're just playing a personna and trying to sound as ignorant as possible?
Anyway, to your final questions: You are precisely correct that secure DRM is impossible without TPM-like technology, and that TPMs will enable the ability to make secure DRM. I never said anything that would contradict that.
My point was that TPMs also enable many other very useful things. And even with a TPM chip in your system, YOU have full control over what applications you run or don't run. I have two systems with TPM chips in them. One is the laptop I'm typing on right now, and the other is a desktop system with an Intel motherboard. Both run Linux, both allow me to run any and all programs that I can run on non-TPM systems. It restricts absolutely nothing. I can rip CDs, listen to my MP3s, etc., etc. Open source software will ALWAYS be able run on any system that implements the TCG specifications. And in fact, it will still run on all systems that implement Microsoft's more powerful NGSCB ideas.
Your dismissal of the importance of being able to build trust in distributed, collaborative settings reminds me of people who think anarchy is a workable society. It isn't, and most people realize this by the time they leave their teen years. And the ability to build trust allows you to do things that you simply wouldn't be able to do otherwise.
Your own very examples of "positive" use of DRM were .... all about the "contents producer"
First, I didn't use even a single example of DRM. Perhaps you don't understand what DRM is. The two main examples I used were examples of building trust amongst a group of users who are trying to do something in a distributed, collaborative setting. They had zip to do with "content." Second, think about any group setting and the fact that for almost any group activity, you do accept restrictions on doing whatever you please. It's not about "fighting the man" or being subjugated by a stronger power -- it's about allowing groups of users to have a functional setup where they can trust each other.
It seems that you cannot even keep your appologisms for the DRM guild internally consistent
My views are entirely consistent, and hardly "appologisms" -- and as far as that goes I can absolutely guarantee you that my anti-DRM credentials put yours to shame.
You know, for a technology that's starting to be quite wide-spread, it's amazing the amount of mis-information spread about trusted platforms -- by both the pro and the con side.
I've worked quite a bit with the technology, and it's not all THAT complicated.
Over-stating what a TPM can do is common from the pro-trusted computing industry. Statements like "It should prevent the phone world from being hit by the same virus and hacking issues that face computers" are just ridiculous (I saw a press release one time that claimed they'd protect people from phishing too!).
Simply put, a TPM does nothing -- nada, zilch -- to prevent viruses or external threats that you can't do in software with no hardware trusted platform additions. OK, you might make the argument that you're just adding another layer for defense in depth, but how about making the software better in the first place?
The only -- yes, only -- extra capability given by a TPM is the ability to protect from local attacks. Meaning attacks from people with physical control over the hardware. Now before the "anti" side runs off and raves about how the TCG is trying to take over their computer, keep in mind that (a) it's optional and (b) there are applications where this makes complete sense. Ignore the DRM side of the issue, and there are still good applications. Imagine playing on-line games and having some assurance that your opponents aren't using hacked up clients that allow them to cheat. Imagine connecting to a peer-to-peer network where the peer you're connecting to can give assurance that it's not a hacked, fake RIAA node. For the cell phone, the obvious point is that it makes cell phone cloning exteremely difficult. None of those are bad things.
If you don't like DRM, then don't accept stores or software that enforce it. And don't mistake every single issue as content providers trying to restrict what you can do.
OK, I know they want that parsed as "Dream", but who else in the context of DRM read that as "D-Ream"?
While my comments were meant in jest, the slight bit of seriousness there seems to have been mistaken 100%.
I love different food. I don't like bland and over-fatty food. Yes, I've had "bangers and mash" in London, and have had many kinds of British cheddar. Neither are exactly the height of culinary excellence. 'course I don't touch Velveeta with a stick, and only my kids eat Oscar Mayer. Personally, I prefer French cheeses, and just am not a big sausage fan (refer back to the "over-fatty" statement above).
No, no, no. No one has claimed the beer is lousy. In fact, the beer is excellent. I figure it's the only way you guys can deal with the weather, food, and women...
And then you "counter" criticism of the food by mentioning.... British cheeses, sausages, yorkshire pudding, and meat pies???? 'scuse me, but which side of this argument are you trying to take?
You're not paying the IRS anything, as far as I know. You're paying the TaxACT people, who developed the web app and maintain and support the web site.
Check out TaxACT. The basic "fill in the forms" version is free -- you print the resulting forms and mail them in, and it doesn't cost you anything. You can e-file for $7.95. No, it's not free, but come on -- under $8? You can barely see a movie for that these days.
The deluxe edition is only $9.95, and it is more thorough if you have things that can give you tax breaks. I'm doing the deluxe version this year, but did the standard one last year -- I started out thinking I'd print and just do it for free, but then realized that the convenience of e-file for $8 really can't be beat...
Since it's web-based, it works fine from Linux. One problem I had (and I've had with another web site as well): for some bizarre reason, the first screen, with the user agreement, looked entirely blank -- it was really just white text rendered on a white background. Strange. It came up fine in konqueror and firefox though, and once you get past that first screen everything seems to work fine in Mozilla (it did force me to install Firefox though, which is actually a good thing).
Anyway, sorry to sound like an ad, but I like it, and I like that I can use it under Linux. It gives my sense of privacy a bit of the willies, but I think you're pretty well protected by law as far as that goes...
The BIOS can already do this, with or without the extra hardware. The BIOS is in complete control until it passes off control to your boot loader. If they wanted to give monopoly control to one OS, they could do that now, without any problems at all.
So the TPM offers no additional abilities in this regard. What does it do? Well, it can "seal" data to a particular configuration -- in other words, it can encrypt data so that it can only be decrypted if you're running the "right" OS and the "right" applications. But you are always in control of what is "right". If you want to seal your PGP keys to a Linux configuration so that it can only be opened when running Evolution under Linux, you can do that. If Microsoft wants to seal data so that it can only be opened when running their "trusted" version of Windows while it's running the Windows Media Player, they can do that. Or lock a .doc file to MS word (so there's no way it could be opened by OpenOffice, for instance) -- that they can do.
But again, you're in complete control with the way the hardware is currently designed. The only real danger comes when content (music, software, documents, whatever) comes locked to a particular configuration. Then your only choice is to use that configuration, or do the Nancy Reagan and "just say no." Personally, I'd just say no to most things like this, but if you don't think something along these lines (technically) isn't inevitable, then you're dreaming....
The MD5 hash collision that was also reported took several orders of magnitude less work than 80000 CPU hours. If you believe them, it took only a little over one hour (on an IBM P690 -- sorry, don't know exactly what that is) to find the (almost) MD5 collision. That's a very practical attack.
And if you look at my example, there was a part with meaningless, random gibberish (the "confirmation number"). This is the only part that needs to be manipulated, and since it's random it doesn't have to be a "meaningful message."
Yes, you're right. Most protocols these days have both sides generate a random nonce, for a variety of reasons. If Joe adds his own randomly chosen junk to the message, then we're down to what the original poster listed as the second kind of attack, which is certainly much harder. But just because that's the way all good protocols work doesn't mean that's the way they do. Imagine a case where I send you a contract, and say "sign this if you agree." Would an "average Joe" :-) think to add random junk at the end?
Of course you can do this, but the question is what do people actual do. In every single case I know of where digital signatures are actually used (including X.509 certificates, signed e-mail, etc.) it's a hash that's signed. For this to be secure, both the hash and the signature method has to be secure. If people just discovered a way to break the hash, then they can potentially break such a system.
Actually, you can do interesting and dangerous things with variants of your first step, not even progressing to step two. The MD5 collisions (well, almost collisions) are largely the same input data that has differences in only a few places. Now imagine that I have two messages that say something like this:
- "Joe will send Dr. Blue $10. Confirmation number 1234567."
- "Joe will send Dr. Blue $100000. Confirmation number 6451234."
Now lets say I can manipulate the confirmation numbers in those two messages so that they have the same hash value -- I don't care what the hash is, as long as it's the same in both cases. Then I send you the $10 message.If you agree, you sign it. But you realize that digital signatures don't actually sign the message, right? They sign the hash of the message, so I can later produce the $100000 message, with your signature, and it will verify that you signed that message!
There's an arcade version of Tux Racer -- there's one in our local Chuckie Cheese. Surely they wouldn't commit the sin of putting Tux Racer on a Windows-based arcade platform, would they? Makes me think the claim of these people to be "the first" may not be 100% accurate.
At least NetZero is still offering free dialup, albeit limited. I use NetZero when I'm traveling and don't have other options (high-speed internet in the hotel, for instance).
You're limited to 10 hours/month in the free service, but really -- if you need it more than that you should be willing to pay for service. I've never used even half of that....
That's way over the top in terms of taxes paid.
A lot of people seem to think income tax rates are much higher than they are. Here's the real info: a family of 4 (what the original poster described) making $45K per year, taking just the simple standard deduction pays a whopping $799 in federal income taxes. There's an additional $3442 in FICA, even assuming that NONE of the $45K is pre-tax (which it almost surely is). That means the total federal tax bill is $4241. To get up to $15K in taxes, California would have to take out over $10,000.
I've never lived in California, but I can't believe that they take out anywhere near that (my own state income tax is $0, but Texas is nice that way!). Even if CA took as big a bite as the federal government, you've got about $8K in total federal and state payroll taxes, which is about half of what you estimated....