Correct on the double-checking... It is trivial, if they try, to notice people sending back unchecked-negatives. And it's also a good test to make sure the system is working properly.
The problem is false-negatives. I hadn't even thought of the economic benefits involved in this, just from the cracker angle of people wanting to screw up the project.
The only way I can see to solve this is cryptographically... bear with me.
The point of the contest is to find the *1* key that will turn the cyphertext into the plaintext. Both are (obviously) known to the client and, most likely, hardcoded in. (I mean, the cyphertext changes once per contest, and the plaintext doesn't change at all, right?)
So, it's impossible to send a fake winning key to a client because you'd have to send a new cyphertext as well. Even if the cyphertext is sent with every block, it would be the same for the other 999 of 1000 blocks, so the client just watches for the cyphertext to change and then calculates properly for a while to catch the fake winning key and then continues cheating.
The other way to cheat is to crack properly, and thus pass all tests, but halt when the winning key is found, without telling d.net. Then just silently return a fake CRC and hope it doesn't get checked, or stop cracking, turn in the answer, and try to say that you were running a personal cracking attempts, which though unlikely to succeed, has to be allowable...
So, it's impossible to send fake winning keys without having already solved the contest, and cheaters don't have to report a win...
So, what to do? Well, I didn't invent RC5 so I don't know how something like this would work, but...
Is there a way to hash the cyphertext AND the plaintext in such a way that the same key will decrypt then as worked on the unhashed pair?
This would allow d.net to send a plaintext and cyphertext pair to each client that the client would be unable to determine as the real cypertext/plaintext pair. The client would still determine for itself if the key was correct or not, but it wouldn't know if it found the real k/c/p, or a dummy. This would make them return all positive results, because most (if not all) positives that any client generated would be tests, not the real thing...
But, just eliminating unchecked negatives (via some dual testing) drop the number of cracked significantly. I mean, how many crackers are going to bother running the rc5 client for months, just for a one in a few million chance of being able to screw it up? I think most crackers would want slightly more gratification. Especially since it's not like they could even take credit for it later if it was (by some huge fluke) them who missed the key the first time around. There's no payoff at all, either positive or negative attention.
On the subject of people finding better ways to crack... It's the algorithm, as interpretted on the computer, that would be enhanced, not the actual algorithm. It's always possible to tweak something with some hand-coded assembly.
Also, to quickly answer a thread about crypto checking the client... Neat idea, but it doesn't work. It's just more layers to be hacked through, and if you make it that interesting, you'll attract more hackers looking for a challenge along with the crackers. The only way crypto can be used to verify the client is if both end users (d.net and the person running the client) are cooperating to stop a hypothetical third party in the middle, and in this case, MD5 hashes of the client keep hacked clients from being substituted for the real thing.
Well, if there's only one correct key, and they're searching for it, it may be a bit hard to send that key to multiple machines...
I believe that the test is done by encrypting known plaintext, which is always the same, with a secret key, so the plaintext and cyphertext would be wired into the client, or at least sent infrequently.
The only way to include a known correct key would be to include a new plaintext of cyphertext with the keys so that one of them would properly decrypt it, but a 'smart' cracked client could simply watch for the plaintext or cyphertext to change and then actually start doing the work properly...
You have to point out all the relevant articles you found, and then explain how your product is different than those.
But, if you just don't point them out...
The patent office doesn't have nearly the resources it should if it wanted to actually investigate the patent aplications.
Bleh, the whole fscking process is corrupt and useless, we need another.
The patent office should only issue patents that are truly unique and innovative, and they should bear the costs of the initial investigation if new evidence should come to light. I mean, they fuck up and some else foots the multi-million dollar bill for it. Pathetic. It's yet another institution that doesn't actually do anything except keep the big (and court-experienced) companies in place and crush start-ups.
It would be much more accurate to compare the Pentium to a very fast 386, because nothing revolutionary has been added since (MMX and SIMD aside)...
But, not only are current x86 chips much faster at the individual instructions, but they are capable of doing multiple instructions at once.
The basic instruction set is the same, but that's like comparing a third-grade vocabulary to a university vocabulary. Sure, the univ. one has all the same words as the elementary one, but it uses them more efficiently, and has many other ones.
1) You can get one on (it seems) nearly anything, simply by wording it so that it seems somewhat new to the examiner, and then use this patent, and the implied threat of lawsuit, to extort money from rival companies.
2) Patents need to be (from what I remember) on something that wouldn't be deemed trivial to a compotent member of the profession. (ie, if processors all had six registers, adding one or two, while new, wouldn't be that great of a conceptual leap). But, due to the secret nature of patent proceedings, the idea is not presented to knowledgable members of the profession, so someone less skilled gets to judge what is worthy of a patent.
Now, specifically about the Transmeta patent...
I read the patent and it described a current caching system, but using registers, presumably instead of very fast static ram located on the cpu...
Well, registers aren't very well defined, nor is their use, either in the patent, or in technical literature. In fact, pretty well anything that the CPU can access without an idle cycle can be refered to as a register. Does it matter if your CPU has 128 128b renamable GP registers, or if it has 2k of cache RAM that is addressable as registers with no more delay than an actual register, or in fact, just has 2k of cache ram with no more delay than a register? No, it doesn't. Either way, you're essentially getting 'free' reads of cached data.
Especially since the Transmeta patent doesn't say that those registers will be program addressable. It's not like they said that the program will be able to look in then to determine what is cached (which would be handy), simply that they are stored as 'registers' instead of 'l1 cache' (Level-n cache being a 'flexible' term itself...)
Considering that all cache ram works by having some area set asside to hold the data, and some set asside to hold the addresses that the data belongs at, and then some logic to make sure that any data changed gets updated in both ram and cache...
The only thing they did was call this storage 'registers' instead of 'cache RAM'.
That sure seems like an example of patenting the blatantly obvious. This sure inspires confidence in the usefulness of the patent system.
This was essentially my suggestions (farther up in the thread).
Compared to RC5 cracking, CRCing is relatively free. So simply have the client CRC the last four bytes of the message they decrypt for all the keys in the block.
By requiring a CRC for all the tried-decryptions keeps someone from only doing every fifth key (or whatever) and by requiring the CRC to be of the *last* bytes in the string, you force them to decrypt the whole thing (or at least as far as the regular client does to report a failure).
Then yes, record the CRCs you get on every hundredth packet or so, and send it out to someone else to check. When the results come back, if they don't match, one of the people is a cheater.
This sort of double-checking should have been in there from the beginning, to guard against bugs, if not cheaters. Only makes good sense to spend a little time making sure you're not wasting a lot.
But, if you checked even 1% of the keys by reissuing then to check their validity, you'd detect cheaters before they made the project miss the real key and have to start all over again, possible taking two or three times as long as otherwise.
So, 1-2% more cpu for security vs 100-n00% more for failure.
Security would be fairly simple. Simply require a CRC of the results of each block. CRCs are fast, and wouldn't slow the clients much. Then, d.net would redistribute a certain percentage of keys at random and check that both users returned the same CRC. If they didn't match, then d.net itself would crack that block and kick out the user whose CRC theirs didn't match.
Something like this (basing a CRC on the results of the proper cracking, like CRCing the first 4 bytes of the resulting 'plaintext') would force people to actually try the keys, and since there's no faster way to crack than by running the client (that we've yet discovered, or the client would be using it) you guarantee that people are actually doing the work.
And this method wouldn't depend at all on security by obscurity, and would allow them to open-source the client, if they desired.
And here we have Something For Nothing Boy. And what's he saying? "Make sure you don't include a license on your work that would prevent me from stealing it, cause I can't code, but I need to release a commercial version!"
The only reason people hate the GPL is 1) they can't code and want to be able to steal code (ie MS's TCP/IP == BSD's TCP/IP) or 2) They're easily excitable, and blinded by stupid anti-commie propoganda into thinking that 'bad for companies' == 'communism' instead of 'bad for companies' == 'good for users'.
How would you feel if you wrote a nice platform independant messaging client, with plugin modules to easily add support for AIM, or ICQ, or any future protocol, etc, and then MS came, took the code, released it in future versions of windows, and sold banner space, increasing their revenues while denying users the benefits of the OSS that you wrote, and without even paying you for it? That's what you'll get with BSDL.
If you allow spam, perhaps if it says "Spam:" in the subject, then we'll still have this problem. People will be sending out advertising and expecting us to pay for it.
The ONLY solution for spam is to make it either against the law, or to put anti-spam clauses in EVERYONE's TOS (even the backbone providers) and then we can remove spammers, and spam friendly companies from the net.
Allowing ANY spam is like having telemarketers phone you collect.
Hmmm. Makes you wish someone would leak the information. I wonder if they do anything to the documentation for each person to identify where leaked copies come from.
What would the legalities be if a driver was written that used information that was leaked from NDA. What if there was no proof that it was from that leak, if they could concievably have reverse-engineered it.
Encryption stuff like this sucks. If DVDs weren't encrypted, we could use them on more OSes, hack together players, etc.
If someone like RedHat makes money from Linux, it's because they contribute to the effort while doing it. If someone like MS makes money from something, it's because they 'force' the market to buy it, regardless of true worth.
I'd definately rather have a value-added company making money with something I wrote than evil monopolists.
(Not that I write anything that's going to make MS green with envy, but...)
1) The GPL gives you the ability to share code with someone, without them using it in a proprietary project against your will. If they want to use it in a closed-source project they can talk to you, and get you to release it to them under a different license, perhaps for some payment. With the BSD license, that company could use your code without either paying you, or releasing it as open source. That may be a certain kind of freedom, but it's like the freedom to personally fund Microsoft's R&D.
2) Microsoft. Remember the big exploit flurry a year or two back, with most OSes being hit at the same time. This was all tracable back to the BSD source code they used. With Linux, this source code was still open, and not only contributing to the community, but also available to be fixed. With Windows, they had used the BSD source code, instead of writing their own, but they used it in the ugliest closed-source project on the market, and the one that makes the most money for them, which they use to kill projects like Linux and BSD. So, the BSD license allowed MS to get something without developing it, or buying it.
3) Communism. Get a clue. Not wanting someone to steal your work has nothing to do with being a communist. The reason I wouldn't want MS using code I wrote in Win2k wouldn't be that I'm anti-corporation, but because I want my due. If they code is so great they've got to have it, then they should fork over a few $$$. If it's not that good, then they can bloody well write their own if they want to put it in their evil closed-source monstrosities.
The way the world works 101.
If you release source code under license A, then later decide to use license B, everyone who downloaded that code when license A was attached can use it under the terms of license A. This means that if you release something under a permisive license, you've lost the ability to put it under a more restrictive license later, because the old copies are out there. But if you start with a restrictive license, you can always release it under a permisive license later on.
So, if you want to have a say in how people use your source code, release it under a license that restricts their ability to close the source, and later, if they can provide you with a good reason, or enough money, you can release it to them with a different license.
In my opinion, a geek movie would be one that got the tech right. In this sense, Hackers was not a geek movie because while it had some realistic characters (Joey, trying to come up with a psuedo was the most realistic) it bulloxed everything else. Not to say that Hackers or The Matrix were bad movies, they weren't, but that they are generic action flicks with a techno premise.
The Matrix had a whole list of flaws. Some are provably wrong, and some just ring untrue.
The first flaw was the power source. This is just plain wrong in so many ways. The easiest way to pick this apart is to look at efficiency. No system has 100% efficiency. If you put energy into something, you get less out the other end. Humans were being fed. If the AIs had just used this food directly to generate heat, they'd have gotten more out of it. Not only are humans inneficient engines, but we 'waste' energy on things irrelevant to producing heat. We grow large bodies, etc. This is a waste from the machines point of view. The whole matrix exists only to keep people alive, so chopping out humans would only make it more sense because this big matrix wouldn't be needed.
The second flaw was about the date chosen for the sim. We're told it's because that's when the world supported the highest population. Sure, maybe. But, why not simulate a million seperate desert islands with barely-sentient cavemen on them? Then we're told that a utopian sim was first created, but people didn't believe it. So, don't create a utopia, but why recreate all the flaws in our society, especially if every needless death robs the machine of power? They could have introduced cars with pedestrian-avoidance fields, better medical, etc. If this makes people 'not believe the reality' then they're telling us people will suddenly start going insane because airbags save too many lives in collisions in the real world.
The other flaws just 'sound' wrong.
There's the big one, of the AIs not being in complete control of the sim. They wrote it. It's like playing a MUD and expecting to change the game through the force of your will.
Then there's the thing about the AIs needing to combat the humans via agents. If being unplugged is fatal, all they have to do is stop sending data updates to 'bad humans' and they'll die. Data is being sent over a network that they control, so all they need to do is stop it at any hop, and that's easy. Thus no more agents. No need for them to play-by-the-rules, sort-of... If agents can jump fifty feet across roofs, dodge bullets, etc, then why can't they shoot lasers from their eyes, or anything slightly more useful? After all, the AIs control the reality.
Third, why is being uplugged fatal? This would only happen through bad design. And I mean sub-microsoft design. If brains still work the same way they do now, then 'you' are always there. The only way to immerse you in a VR is to tap into your senses and pass in the virtual world. So why do you connect directly, without so much as a fuse between you, to the evil computer? Why not have a simple computer between you that you control? If the shock of switching worlds suddenly is fatal, then have the simple computer watch for a shutdown, then it freezes the world in the last state it got, and slowly fades you back into reality in a non-fatal way?
Honestly, if anyone would plug themselves into something where a winnuke would not only punt you from IRC, but kill you... Yeesh. Better hope a script kiddie in 2150 never gets your IP...
A techno movie with flaws doesn't honestly strike me as a geek movie. It was a kick-ass (literally) action movie, and as such, with the cool shoot-out and kung-fu scenes, was great fun to watch, and I'm not suprised that many geeks liked it, but it WASN'T a hacker movie. The most realistic 'hacker' scene it had was Neo, fallen asleep, getting a keyboard imprint on his face.
Not really... Most OSes are protected because the source is secret, not because of patents.
Think of short-term patents in something like portable music... MP3 isn't 'better' than all other proposed formats, it was simply the first to hit public conciousness. The music site mp3.com is an example of how people mistake the format for the content. This shows that 12-18 months of lead time for the company with the patent is more than enough to pimp their invention for all its worth.
In fact, having short patents would probably make software less buggy in the sense that a company couldn't rely on being a monopoly, and they'd have to compete on product. (or, in some cases, illegal trade practices...)
Side note: Win95/98/NT couldn't possibly be buggier... This isn't an anti-MS rant. If they were any buggier, people wouldn't use them. MS fixes just enough bugs to remain competetive layman-OS market, and ignores the rest.
The GPL perfectly protects the author. It ensures that people can use the code, but not make it their own.
The BSD license is nice, until someone makes some changes, and then releases the program as binaries only. Sure, they may be required to say that you wrote some of the early code, but that's a small benefit.
The reason the GPL applies to all future revisions of that source code is so that people can't steal your work.
You the author always have the ability to do anything you want with your source code. You are protected by the GPL because the GPL makes sure that you always do have the ability to keep someone from closing your open source project.
If BSD had such a clause, Microsoft couldn't have 'borrowed' network code from them and put it into the closed monstrosity that is Windows. They'd have had to either make the networking subsystem open source, or write their own code. I don't know about you, but if I write code, I want to make sure it won't be used by monopolistic jerks.
The *most important* part of the GPL is that it applies to all future versions. All of Stallman's other accomplishments pale before this. Keeping code free is the chief thing which makes people trust projects like Linux. (Who would dev for it, if MS could come along, make a few KDE themes, and call it Win 2000?)
Well, it also defeats the purpose of multiple top level domains.
It's like when 888 numbers became available. 40% or something (I heard the number secondhand) were immediately taken by the companies who had the same 800 number. Then a bunch more were no doubt taken by people like the whitehouse.com guy.
We need to introduce TLDs that are have vastly different meaning, and do NOT overlap. If.com is for companies, then for-profit companies shouldn't be able to register.org... There need to be categories for vastly different types of use, but not so many that companies will feel the need for more than one to cover their area of bussiness.
And I don't really see the need for multiple domains to point to the same place. It's all one big 'virtual' land grab, and we shouldn't put up with it.
I don't want to set limits on who can own domains. A.com should be as freely available for an 8yo with a lemonade stand, as for IBM. I do want to set limits on domains saying that if they aren't used, they are simply not renewed, and returned to the pool.
The main offenders are companies, registering everything they might ever want, and then pointing them all to the same page, or to a 'Coming soon' page dated from '89.
'We' invented this place. Anyone who has written open source code, or supported the diversity of the net has contributed to this. Should we now step back and hand control of our new world to those who sat back and watched, and now want us to give it to them?
I think not. When dealing with the masses, who haven't learned that good things come from cooperation, we need rules to keep them from simply fencing off as much as they can see and claiming it as theirs.
I suggest that a good way of regulating use of domains would be to revoke (at renewal time) any domains where more than two point to the same web page, or any domains that have no content past the initial screen.
If some company wants fifty domains, but is willing to generate fifty sets of content, then let them. If they just want to keep other people from using them, then we should step in.
Bush registers a bunch of domain names, Proctor and Gamble (?) registers another huge number, etc... And we wonder why we're running out of domain names. It's like giving a class C to every AOL user.
I would suggest a good rule for domain name registration authorities is that a company can have its domain name renewal denied if it hasn't made use of the name. If all a name does is point to a "Coming soon" or "Buy this domain" page for a year, then we should return it to the pile and let someone else have a go at it. Ditto when someone has a bunch of domain names point to the same page.
Bush isn't doing anything wrong, but he's still being a jerk by buying something just to keep someone else from having it. We should work for rules that stop this sort of land-grab behavior.
If he can't put up content on every domain name, and not just link them all to one page, then let him, but if he's just pissing all over stuff to keep other people away... Well, we don't need that bullshit on the net as well as in the physical world.
Shrinkwrap licenses are only enforcable if their existance is specifically pointed out before the store agrees to the purchase of the product.
The reasoning behind that decision went along the lines that it's usual to expect that if you BUY (not lease or rent) something, you have full and complete control over its usage. By offering some products for normal sale (mice, cables, etc) and some that has other limiting clauses (software) and not distinguishing between the two, the license has no effect.
I've never had a clerk at a store point this out (why should they? It doesn't benefit them) and I seriously doubt any do. The only recourse of the publisher is to get stores to agree to provide this warning.
Shrink-wrap licenses are also completely invalid if they aren't 100% visible through the shrink-wrap. Similarly, if you'd have to open the package to understand (ie, it refrences material inside the box, etc) the agreement, then you can open the shrinkwrap without agreeing...
There are so few cases in which a shrinkwrap license is valid that they're only included for the same reasons all sort of warning are included with products, buying more BMWs for lawyers.
>They may not be able to make you want it, but there are ways to make you "choose" it anyway. Right now, the major format is PCM (audio >CDs). All they have to do is sell SDMI music at $1 per song, and raise the price of a 10-song CD to $40. Which will you buy then
Heh. If they do, I'll simply use cash to buy a cd, or flash card, or whatever full of SDMI music, use one of the programs that nabs the digital audio before it becomes analog, make MP3s of it, and tada...
And if it's digitally watermarked and survives the MP3ing? Big whoop. They'll know an anonymous customer bought it at a certain store.
I will NEVER give my name when buying a product unless having to product tracked is in MY best interests.
If they try this, they'll just piss us off in a big way, and we'll pirate to hurt them, instead of to save money. If everyone sold collection CDs with 12h of music on them for $2 at bus stations, the industry would feel it in a hurry. If they make us really mad, they'll pay.
Not to mention that if I ever use a software product that intentionally disables another part of my computer in a provable way (they announce it as part of the strategy) then I'll sue them, and win. I use MP3s for distributing audio help files to my clients for the software I write. If they killed MP3s on my system, I'd have a nice lawsuit on the order of $50k. And if everyone jumped on...
On second thought, I really hope they are this stupid. They'll be broke in a year, and all the execs who okayed the sabotage decision will be in jail, or personally liable for the damages. (While you aren't normally liable for the debts of your company, if you break the law, acting for your company, you and the company are jointly liable.)
And those $200/hr consultant are going to have a solution for keeping private keys private? This either requires everyone to use certifiably secure computers to sign messages, or some sort of smart-card implementation which is only as trustworthy as the company that made it, etc.
Bussiness types get fightened easily, and throw a lot of money around to get solutions, but I'd hardly call them astute when it comes to judging the professionals they hire, the solutions they are given, or following the directions they're given. (Witness y2k and two digit dates... Good idea at the time, but the programmers back then all said "Oh, and replace this before 1999..." Did these "frighteningly astute" million-dollar-men listen? Nope. They had tossed around the big bucks, so their job was done.)
Digital signatures are fine, assuming everyone involved is trustworthy, intelligent, and not gullible. It'll never happen.
In public key crypto you have two keys, a public and a private. The public key you give out, and the private key you keep hidden. Messages can be encrypted with one key, and then are only decodable with the other key.
If someone sends you a message they encrypt the whole thing with your public key, and you decrypt it with the private key.
If you sign a message you usually want it to be world readable so you post the message in plain text, along with an MD5 hash of the message body that you encrypt with your private key. This lets anyone reas the message, and anyone with your public key decrypt the 'signature' and read the hash. They then perform the same hash on the message they read, and compare the values. If it's the same, they can be very sure the message hasn't been tampered with. (It's a 'hard' problem to find a message that has the same MD5 hash as a given message. And a 'very hard' problem to find one that makes sense (ie, not random characters.))
The private key is all that's needed to sign a message! Some programs like PGP use another layer on encryption to hide your private key from casual tampering, making you enter a password to decode your private key. This is not a part of the public-key signature process, but instead a PGP feature. This means that all someone needs to have is your private key and they can masquerade as you.
How do they capture it? Trojan horses. There are many ways, some of them include. 1) Rewrite PGP to send a 'plaintext' of the private key to the attacker. 2) PGP can be used in batch mode. Write a front-end that pretends to be PGP, then sends the data to the real PGP to do the work. Then emails your passcode and private key to the attacker. 3) Watch for PGP to be run and scan through its memory space to read the private key. Mail it off the the attacker.
Of the above methods, #2 is easiest, followed by #1, and then #3. #2 could be hacked together in an hour by anyone who can code in perl.
With your private key, anyone can post messages and sign them as you. Such messages will be identical to messages you have written and signed yourself.
It is true that the Signature can't just be stuck on any old message, but with the private key, you can create a signature for any old message.
PGP could be based on a provably uncrackable code, resistant to quantum computer of unimaginable power, and your signature would still only be as strong as your OS.
The same goes for smart cards. It's just that we can assume a smartcard designed explicitly for security would be more secure than Win95. Maybe not much more, but some. The problem with smart cards is that it's all security by obscurity. The companies *know* that anyone dedicated enough, who knows the chip details, can crack them. Thus you'll never see the details, and will have to trust a big corp telling you that you're safe. Dunno about you, but I'm not the trusting sort.
Even if you can trust the smart-card, what's to stop a simple pickpocket from stealing it, cracking the simple code, and signing things before the card is revoked? You doubt the code would be simple? How many consumers can remember more than a six digit code? Fingerprints would be no more secure unless everyone used windex on the sensor after each use.
The digital signature is a great idea, but remains very easy to forge.
What can we use? How about recording a 640x480@30fps video w/ 16b 44khz audio of yourself reading the document outloud, then signing physically. It'd be a lot harder to fake. And as long as the document you read matched the other, it shouldn't matter if you fax it, because someone could just download the signature video and see if it looked real... This is just a moderately silly suggestion, but it's also the most secure thing I can think of, at least until virtual actors get to the point someone can fake this.
MS will never port an app like Office to a platform where they don't have control of the API, or control of the company that does (Apple BEGGED for Office for the Mac).
Why not? Because their apps depend on undocumented API calls. If it wasn't for that advantage they'd have to compete on size/speed/stability/options and they know that they can't.
They use the OS (which doesn't make them much money directly) to give them a base to write aps for (which do make lots of money). They dump to OS on the market to get market share because then you're locked into buying other MS products. If WordPerfect gets too good, they just change some specific API call that it depends on a lot so that it will crash all the time, and make sure that none of their aps use that call. And nobody would believe it's NOT WordPerfect to blame.
They'll NEVER leave their comfy little OS in a big way. They might port a few things where it helps them. If they invent a new media format, they'll port a player, to help make the format take over, but they'll never do it without the intent of killing a competitor or whole market. Never.
Slashdot Mirror
Correct on the double-checking... It is trivial, if they try, to notice people sending back unchecked-negatives. And it's also a good test to make sure the system is working properly.
The problem is false-negatives. I hadn't even thought of the economic benefits involved in this, just from the cracker angle of people wanting to screw up the project.
The only way I can see to solve this is cryptographically... bear with me.
The point of the contest is to find the *1* key that will turn the cyphertext into the plaintext. Both are (obviously) known to the client and, most likely, hardcoded in. (I mean, the cyphertext changes once per contest, and the plaintext doesn't change at all, right?)
So, it's impossible to send a fake winning key to a client because you'd have to send a new cyphertext as well. Even if the cyphertext is sent with every block, it would be the same for the other 999 of 1000 blocks, so the client just watches for the cyphertext to change and then calculates properly for a while to catch the fake winning key and then continues cheating.
The other way to cheat is to crack properly, and thus pass all tests, but halt when the winning key is found, without telling d.net. Then just silently return a fake CRC and hope it doesn't get checked, or stop cracking, turn in the answer, and try to say that you were running a personal cracking attempts, which though unlikely to succeed, has to be allowable...
So, it's impossible to send fake winning keys without having already solved the contest, and cheaters don't have to report a win...
So, what to do? Well, I didn't invent RC5 so I don't know how something like this would work, but...
Is there a way to hash the cyphertext AND the plaintext in such a way that the same key will decrypt then as worked on the unhashed pair?
This would allow d.net to send a plaintext and cyphertext pair to each client that the client would be unable to determine as the real cypertext/plaintext pair. The client would still determine for itself if the key was correct or not, but it wouldn't know if it found the real k/c/p, or a dummy. This would make them return all positive results, because most (if not all) positives that any client generated would be tests, not the real thing...
But, just eliminating unchecked negatives (via some dual testing) drop the number of cracked significantly. I mean, how many crackers are going to bother running the rc5 client for months, just for a one in a few million chance of being able to screw it up? I think most crackers would want slightly more gratification. Especially since it's not like they could even take credit for it later if it was (by some huge fluke) them who missed the key the first time around. There's no payoff at all, either positive or negative attention.
On the subject of people finding better ways to crack... It's the algorithm, as interpretted on the computer, that would be enhanced, not the actual algorithm. It's always possible to tweak something with some hand-coded assembly.
Also, to quickly answer a thread about crypto checking the client... Neat idea, but it doesn't work. It's just more layers to be hacked through, and if you make it that interesting, you'll attract more hackers looking for a challenge along with the crackers. The only way crypto can be used to verify the client is if both end users (d.net and the person running the client) are cooperating to stop a hypothetical third party in the middle, and in this case, MD5 hashes of the client keep hacked clients from being substituted for the real thing.
Well, if there's only one correct key, and they're searching for it, it may be a bit hard to send that key to multiple machines...
I believe that the test is done by encrypting known plaintext, which is always the same, with a secret key, so the plaintext and cyphertext would be wired into the client, or at least sent infrequently.
The only way to include a known correct key would be to include a new plaintext of cyphertext with the keys so that one of them would properly decrypt it, but a 'smart' cracked client could simply watch for the plaintext or cyphertext to change and then actually start doing the work properly...
Perhaps, but not by much.
You have to point out all the relevant articles you found, and then explain how your product is different than those.
But, if you just don't point them out...
The patent office doesn't have nearly the resources it should if it wanted to actually investigate the patent aplications.
Bleh, the whole fscking process is corrupt and useless, we need another.
The patent office should only issue patents that are truly unique and innovative, and they should bear the costs of the initial investigation if new evidence should come to light. I mean, they fuck up and some else foots the multi-million dollar bill for it. Pathetic. It's yet another institution that doesn't actually do anything except keep the big (and court-experienced) companies in place and crush start-ups.
Not even close.
It would be much more accurate to compare the Pentium to a very fast 386, because nothing revolutionary has been added since (MMX and SIMD aside)...
But, not only are current x86 chips much faster at the individual instructions, but they are capable of doing multiple instructions at once.
The basic instruction set is the same, but that's like comparing a third-grade vocabulary to a university vocabulary. Sure, the univ. one has all the same words as the elementary one, but it uses them more efficiently, and has many other ones.
Patents have a few drawbacks.
1) You can get one on (it seems) nearly anything, simply by wording it so that it seems somewhat new to the examiner, and then use this patent, and the implied threat of lawsuit, to extort money from rival companies.
2) Patents need to be (from what I remember) on something that wouldn't be deemed trivial to a compotent member of the profession. (ie, if processors all had six registers, adding one or two, while new, wouldn't be that great of a conceptual leap). But, due to the secret nature of patent proceedings, the idea is not presented to knowledgable members of the profession, so someone less skilled gets to judge what is worthy of a patent.
Now, specifically about the Transmeta patent...
I read the patent and it described a current caching system, but using registers, presumably instead of very fast static ram located on the cpu...
Well, registers aren't very well defined, nor is their use, either in the patent, or in technical literature. In fact, pretty well anything that the CPU can access without an idle cycle can be refered to as a register. Does it matter if your CPU has 128 128b renamable GP registers, or if it has 2k of cache RAM that is addressable as registers with no more delay than an actual register, or in fact, just has 2k of cache ram with no more delay than a register? No, it doesn't. Either way, you're essentially getting 'free' reads of cached data.
Especially since the Transmeta patent doesn't say that those registers will be program addressable. It's not like they said that the program will be able to look in then to determine what is cached (which would be handy), simply that they are stored as 'registers' instead of 'l1 cache' (Level-n cache being a 'flexible' term itself...)
Considering that all cache ram works by having some area set asside to hold the data, and some set asside to hold the addresses that the data belongs at, and then some logic to make sure that any data changed gets updated in both ram and cache...
The only thing they did was call this storage 'registers' instead of 'cache RAM'.
That sure seems like an example of patenting the blatantly obvious. This sure inspires confidence in the usefulness of the patent system.
Well, Q3 will work through SOCKS, so yes, pretty well everything important will work... :)
This was essentially my suggestions (farther up in the thread).
Compared to RC5 cracking, CRCing is relatively free. So simply have the client CRC the last four bytes of the message they decrypt for all the keys in the block.
By requiring a CRC for all the tried-decryptions keeps someone from only doing every fifth key (or whatever) and by requiring the CRC to be of the *last* bytes in the string, you force them to decrypt the whole thing (or at least as far as the regular client does to report a failure).
Then yes, record the CRCs you get on every hundredth packet or so, and send it out to someone else to check. When the results come back, if they don't match, one of the people is a cheater.
This sort of double-checking should have been in there from the beginning, to guard against bugs, if not cheaters. Only makes good sense to spend a little time making sure you're not wasting a lot.
But, if you checked even 1% of the keys by reissuing then to check their validity, you'd detect cheaters before they made the project miss the real key and have to start all over again, possible taking two or three times as long as otherwise.
So, 1-2% more cpu for security vs 100-n00% more for failure.
Security would be fairly simple. Simply require a CRC of the results of each block. CRCs are fast, and wouldn't slow the clients much. Then, d.net would redistribute a certain percentage of keys at random and check that both users returned the same CRC. If they didn't match, then d.net itself would crack that block and kick out the user whose CRC theirs didn't match.
Something like this (basing a CRC on the results of the proper cracking, like CRCing the first 4 bytes of the resulting 'plaintext') would force people to actually try the keys, and since there's no faster way to crack than by running the client (that we've yet discovered, or the client would be using it) you guarantee that people are actually doing the work.
And this method wouldn't depend at all on security by obscurity, and would allow them to open-source the client, if they desired.
And here we have Something For Nothing Boy. And what's he saying? "Make sure you don't include a license on your work that would prevent me from stealing it, cause I can't code, but I need to release a commercial version!"
The only reason people hate the GPL is 1) they can't code and want to be able to steal code (ie MS's TCP/IP == BSD's TCP/IP) or 2) They're easily excitable, and blinded by stupid anti-commie propoganda into thinking that 'bad for companies' == 'communism' instead of 'bad for companies' == 'good for users'.
How would you feel if you wrote a nice platform independant messaging client, with plugin modules to easily add support for AIM, or ICQ, or any future protocol, etc, and then MS came, took the code, released it in future versions of windows, and sold banner space, increasing their revenues while denying users the benefits of the OSS that you wrote, and without even paying you for it? That's what you'll get with BSDL.
If you allow spam, perhaps if it says "Spam:" in the subject, then we'll still have this problem. People will be sending out advertising and expecting us to pay for it.
The ONLY solution for spam is to make it either against the law, or to put anti-spam clauses in EVERYONE's TOS (even the backbone providers) and then we can remove spammers, and spam friendly companies from the net.
Allowing ANY spam is like having telemarketers phone you collect.
Exactly right. Spam is *not* a free-speech issue.
People have the right to say what they want, but they don't have the right to demand that you buy them a soapbox to stand on.
Hmmm. Makes you wish someone would leak the information. I wonder if they do anything to the documentation for each person to identify where leaked copies come from.
What would the legalities be if a driver was written that used information that was leaked from NDA. What if there was no proof that it was from that leak, if they could concievably have reverse-engineered it.
Encryption stuff like this sucks. If DVDs weren't encrypted, we could use them on more OSes, hack together players, etc.
You read it right.
If someone like RedHat makes money from Linux, it's because they contribute to the effort while doing it. If someone like MS makes money from something, it's because they 'force' the market to buy it, regardless of true worth.
I'd definately rather have a value-added company making money with something I wrote than evil monopolists.
(Not that I write anything that's going to make MS green with envy, but...)
1) The GPL gives you the ability to share code with someone, without them using it in a proprietary project against your will. If they want to use it in a closed-source project they can talk to you, and get you to release it to them under a different license, perhaps for some payment. With the BSD license, that company could use your code without either paying you, or releasing it as open source. That may be a certain kind of freedom, but it's like the freedom to personally fund Microsoft's R&D.
2) Microsoft. Remember the big exploit flurry a year or two back, with most OSes being hit at the same time. This was all tracable back to the BSD source code they used. With Linux, this source code was still open, and not only contributing to the community, but also available to be fixed. With Windows, they had used the BSD source code, instead of writing their own, but they used it in the ugliest closed-source project on the market, and the one that makes the most money for them, which they use to kill projects like Linux and BSD. So, the BSD license allowed MS to get something without developing it, or buying it.
3) Communism. Get a clue. Not wanting someone to steal your work has nothing to do with being a communist. The reason I wouldn't want MS using code I wrote in Win2k wouldn't be that I'm anti-corporation, but because I want my due. If they code is so great they've got to have it, then they should fork over a few $$$. If it's not that good, then they can bloody well write their own if they want to put it in their evil closed-source monstrosities.
The way the world works 101.
If you release source code under license A, then later decide to use license B, everyone who downloaded that code when license A was attached can use it under the terms of license A. This means that if you release something under a permisive license, you've lost the ability to put it under a more restrictive license later, because the old copies are out there. But if you start with a restrictive license, you can always release it under a permisive license later on.
So, if you want to have a say in how people use your source code, release it under a license that restricts their ability to close the source, and later, if they can provide you with a good reason, or enough money, you can release it to them with a different license.
In my opinion, a geek movie would be one that got the tech right. In this sense, Hackers was not a geek movie because while it had some realistic characters (Joey, trying to come up with a psuedo was the most realistic) it bulloxed everything else. Not to say that Hackers or The Matrix were bad movies, they weren't, but that they are generic action flicks with a techno premise.
The Matrix had a whole list of flaws. Some are provably wrong, and some just ring untrue.
The first flaw was the power source. This is just plain wrong in so many ways. The easiest way to pick this apart is to look at efficiency. No system has 100% efficiency. If you put energy into something, you get less out the other end. Humans were being fed. If the AIs had just used this food directly to generate heat, they'd have gotten more out of it. Not only are humans inneficient engines, but we 'waste' energy on things irrelevant to producing heat. We grow large bodies, etc. This is a waste from the machines point of view. The whole matrix exists only to keep people alive, so chopping out humans would only make it more sense because this big matrix wouldn't be needed.
The second flaw was about the date chosen for the sim. We're told it's because that's when the world supported the highest population. Sure, maybe. But, why not simulate a million seperate desert islands with barely-sentient cavemen on them? Then we're told that a utopian sim was first created, but people didn't believe it. So, don't create a utopia, but why recreate all the flaws in our society, especially if every needless death robs the machine of power? They could have introduced cars with pedestrian-avoidance fields, better medical, etc. If this makes people 'not believe the reality' then they're telling us people will suddenly start going insane because airbags save too many lives in collisions in the real world.
The other flaws just 'sound' wrong.
There's the big one, of the AIs not being in complete control of the sim. They wrote it. It's like playing a MUD and expecting to change the game through the force of your will.
Then there's the thing about the AIs needing to combat the humans via agents. If being unplugged is fatal, all they have to do is stop sending data updates to 'bad humans' and they'll die. Data is being sent over a network that they control, so all they need to do is stop it at any hop, and that's easy. Thus no more agents. No need for them to play-by-the-rules, sort-of... If agents can jump fifty feet across roofs, dodge bullets, etc, then why can't they shoot lasers from their eyes, or anything slightly more useful? After all, the AIs control the reality.
Third, why is being uplugged fatal? This would only happen through bad design. And I mean sub-microsoft design. If brains still work the same way they do now, then 'you' are always there. The only way to immerse you in a VR is to tap into your senses and pass in the virtual world. So why do you connect directly, without so much as a fuse between you, to the evil computer? Why not have a simple computer between you that you control? If the shock of switching worlds suddenly is fatal, then have the simple computer watch for a shutdown, then it freezes the world in the last state it got, and slowly fades you back into reality in a non-fatal way?
Honestly, if anyone would plug themselves into something where a winnuke would not only punt you from IRC, but kill you... Yeesh. Better hope a script kiddie in 2150 never gets your IP...
A techno movie with flaws doesn't honestly strike me as a geek movie. It was a kick-ass (literally) action movie, and as such, with the cool shoot-out and kung-fu scenes, was great fun to watch, and I'm not suprised that many geeks liked it, but it WASN'T a hacker movie. The most realistic 'hacker' scene it had was Neo, fallen asleep, getting a keyboard imprint on his face.
Not really... Most OSes are protected because the source is secret, not because of patents.
Think of short-term patents in something like portable music... MP3 isn't 'better' than all other proposed formats, it was simply the first to hit public conciousness. The music site mp3.com is an example of how people mistake the format for the content. This shows that 12-18 months of lead time for the company with the patent is more than enough to pimp their invention for all its worth.
In fact, having short patents would probably make software less buggy in the sense that a company couldn't rely on being a monopoly, and they'd have to compete on product. (or, in some cases, illegal trade practices...)
Side note: Win95/98/NT couldn't possibly be buggier... This isn't an anti-MS rant. If they were any buggier, people wouldn't use them. MS fixes just enough bugs to remain competetive layman-OS market, and ignores the rest.
The GPL perfectly protects the author. It ensures that people can use the code, but not make it their own.
The BSD license is nice, until someone makes some changes, and then releases the program as binaries only. Sure, they may be required to say that you wrote some of the early code, but that's a small benefit.
The reason the GPL applies to all future revisions of that source code is so that people can't steal your work.
You the author always have the ability to do anything you want with your source code. You are protected by the GPL because the GPL makes sure that you always do have the ability to keep someone from closing your open source project.
If BSD had such a clause, Microsoft couldn't have 'borrowed' network code from them and put it into the closed monstrosity that is Windows. They'd have had to either make the networking subsystem open source, or write their own code. I don't know about you, but if I write code, I want to make sure it won't be used by monopolistic jerks.
The *most important* part of the GPL is that it applies to all future versions. All of Stallman's other accomplishments pale before this. Keeping code free is the chief thing which makes people trust projects like Linux. (Who would dev for it, if MS could come along, make a few KDE themes, and call it Win 2000?)
Well, it also defeats the purpose of multiple top level domains.
.com is for companies, then for-profit companies shouldn't be able to register .org... There need to be categories for vastly different types of use, but not so many that companies will feel the need for more than one to cover their area of bussiness.
.com should be as freely available for an 8yo with a lemonade stand, as for IBM. I do want to set limits on domains saying that if they aren't used, they are simply not renewed, and returned to the pool.
It's like when 888 numbers became available. 40% or something (I heard the number secondhand) were immediately taken by the companies who had the same 800 number. Then a bunch more were no doubt taken by people like the whitehouse.com guy.
We need to introduce TLDs that are have vastly different meaning, and do NOT overlap. If
And I don't really see the need for multiple domains to point to the same place. It's all one big 'virtual' land grab, and we shouldn't put up with it.
I don't want to set limits on who can own domains. A
The main offenders are companies, registering everything they might ever want, and then pointing them all to the same page, or to a 'Coming soon' page dated from '89.
'We' invented this place. Anyone who has written open source code, or supported the diversity of the net has contributed to this. Should we now step back and hand control of our new world to those who sat back and watched, and now want us to give it to them?
I think not. When dealing with the masses, who haven't learned that good things come from cooperation, we need rules to keep them from simply fencing off as much as they can see and claiming it as theirs.
I suggest that a good way of regulating use of domains would be to revoke (at renewal time) any domains where more than two point to the same web page, or any domains that have no content past the initial screen.
If some company wants fifty domains, but is willing to generate fifty sets of content, then let them. If they just want to keep other people from using them, then we should step in.
Bush registers a bunch of domain names, Proctor and Gamble (?) registers another huge number, etc... And we wonder why we're running out of domain names. It's like giving a class C to every AOL user.
I would suggest a good rule for domain name registration authorities is that a company can have its domain name renewal denied if it hasn't made use of the name. If all a name does is point to a "Coming soon" or "Buy this domain" page for a year, then we should return it to the pile and let someone else have a go at it. Ditto when someone has a bunch of domain names point to the same page.
Bush isn't doing anything wrong, but he's still being a jerk by buying something just to keep someone else from having it. We should work for rules that stop this sort of land-grab behavior.
If he can't put up content on every domain name, and not just link them all to one page, then let him, but if he's just pissing all over stuff to keep other people away... Well, we don't need that bullshit on the net as well as in the physical world.
Shrinkwrap licenses are only enforcable if their existance is specifically pointed out before the store agrees to the purchase of the product.
The reasoning behind that decision went along the lines that it's usual to expect that if you BUY (not lease or rent) something, you have full and complete control over its usage. By offering some products for normal sale (mice, cables, etc) and some that has other limiting clauses (software) and not distinguishing between the two, the license has no effect.
I've never had a clerk at a store point this out (why should they? It doesn't benefit them) and I seriously doubt any do. The only recourse of the publisher is to get stores to agree to provide this warning.
Shrink-wrap licenses are also completely invalid if they aren't 100% visible through the shrink-wrap. Similarly, if you'd have to open the package to understand (ie, it refrences material inside the box, etc) the agreement, then you can open the shrinkwrap without agreeing...
There are so few cases in which a shrinkwrap license is valid that they're only included for the same reasons all sort of warning are included with products, buying more BMWs for lawyers.
>They may not be able to make you want it, but there are ways to make you "choose" it anyway. Right now, the major format is PCM (audio
>CDs). All they have to do is sell SDMI music at $1 per song, and raise the price of a 10-song CD to $40. Which will you buy then
Heh. If they do, I'll simply use cash to buy a cd, or flash card, or whatever full of SDMI music, use one of the programs that nabs the digital audio before it becomes analog, make MP3s of it, and tada...
And if it's digitally watermarked and survives the MP3ing? Big whoop. They'll know an anonymous customer bought it at a certain store.
I will NEVER give my name when buying a product unless having to product tracked is in MY best interests.
If they try this, they'll just piss us off in a big way, and we'll pirate to hurt them, instead of to save money. If everyone sold collection CDs with 12h of music on them for $2 at bus stations, the industry would feel it in a hurry. If they make us really mad, they'll pay.
Not to mention that if I ever use a software product that intentionally disables another part of my computer in a provable way (they announce it as part of the strategy) then I'll sue them, and win. I use MP3s for distributing audio help files to my clients for the software I write. If they killed MP3s on my system, I'd have a nice lawsuit on the order of $50k. And if everyone jumped on...
On second thought, I really hope they are this stupid. They'll be broke in a year, and all the execs who okayed the sabotage decision will be in jail, or personally liable for the damages. (While you aren't normally liable for the debts of your company, if you break the law, acting for your company, you and the company are jointly liable.)
Yuh Huh.
And those $200/hr consultant are going to have a solution for keeping private keys private? This either requires everyone to use certifiably secure computers to sign messages, or some sort of smart-card implementation which is only as trustworthy as the company that made it, etc.
Bussiness types get fightened easily, and throw a lot of money around to get solutions, but I'd hardly call them astute when it comes to judging the professionals they hire, the solutions they are given, or following the directions they're given. (Witness y2k and two digit dates... Good idea at the time, but the programmers back then all said "Oh, and replace this before 1999..." Did these "frighteningly astute" million-dollar-men listen? Nope. They had tossed around the big bucks, so their job was done.)
Digital signatures are fine, assuming everyone involved is trustworthy, intelligent, and not gullible. It'll never happen.
In public key crypto you have two keys, a public and a private. The public key you give out, and the private key you keep hidden. Messages can be encrypted with one key, and then are only decodable with the other key.
If someone sends you a message they encrypt the whole thing with your public key, and you decrypt it with the private key.
If you sign a message you usually want it to be world readable so you post the message in plain text, along with an MD5 hash of the message body that you encrypt with your private key. This lets anyone reas the message, and anyone with your public key decrypt the 'signature' and read the hash. They then perform the same hash on the message they read, and compare the values. If it's the same, they can be very sure the message hasn't been tampered with. (It's a 'hard' problem to find a message that has the same MD5 hash as a given message. And a 'very hard' problem to find one that makes sense (ie, not random characters.))
The private key is all that's needed to sign a message! Some programs like PGP use another layer on encryption to hide your private key from casual tampering, making you enter a password to decode your private key. This is not a part of the public-key signature process, but instead a PGP feature. This means that all someone needs to have is your private key and they can masquerade as you.
How do they capture it? Trojan horses. There are many ways, some of them include. 1) Rewrite PGP to send a 'plaintext' of the private key to the attacker. 2) PGP can be used in batch mode. Write a front-end that pretends to be PGP, then sends the data to the real PGP to do the work. Then emails your passcode and private key to the attacker. 3) Watch for PGP to be run and scan through its memory space to read the private key. Mail it off the the attacker.
Of the above methods, #2 is easiest, followed by #1, and then #3. #2 could be hacked together in an hour by anyone who can code in perl.
With your private key, anyone can post messages and sign them as you. Such messages will be identical to messages you have written and signed yourself.
It is true that the Signature can't just be stuck on any old message, but with the private key, you can create a signature for any old message.
PGP could be based on a provably uncrackable code, resistant to quantum computer of unimaginable power, and your signature would still only be as strong as your OS.
The same goes for smart cards. It's just that we can assume a smartcard designed explicitly for security would be more secure than Win95. Maybe not much more, but some. The problem with smart cards is that it's all security by obscurity. The companies *know* that anyone dedicated enough, who knows the chip details, can crack them. Thus you'll never see the details, and will have to trust a big corp telling you that you're safe. Dunno about you, but I'm not the trusting sort.
Even if you can trust the smart-card, what's to stop a simple pickpocket from stealing it, cracking the simple code, and signing things before the card is revoked? You doubt the code would be simple? How many consumers can remember more than a six digit code? Fingerprints would be no more secure unless everyone used windex on the sensor after each use.
The digital signature is a great idea, but remains very easy to forge.
What can we use? How about recording a 640x480@30fps video w/ 16b 44khz audio of yourself reading the document outloud, then signing physically. It'd be a lot harder to fake. And as long as the document you read matched the other, it shouldn't matter if you fax it, because someone could just download the signature video and see if it looked real... This is just a moderately silly suggestion, but it's also the most secure thing I can think of, at least until virtual actors get to the point someone can fake this.
MS will never port an app like Office to a platform where they don't have control of the API, or control of the company that does (Apple BEGGED for Office for the Mac).
Why not? Because their apps depend on undocumented API calls. If it wasn't for that advantage they'd have to compete on size/speed/stability/options and they know that they can't.
They use the OS (which doesn't make them much money directly) to give them a base to write aps for (which do make lots of money). They dump to OS on the market to get market share because then you're locked into buying other MS products. If WordPerfect gets too good, they just change some specific API call that it depends on a lot so that it will crash all the time, and make sure that none of their aps use that call. And nobody would believe it's NOT WordPerfect to blame.
They'll NEVER leave their comfy little OS in a big way. They might port a few things where it helps them. If they invent a new media format, they'll port a player, to help make the format take over, but they'll never do it without the intent of killing a competitor or whole market. Never.