December 2003 - cypherpunks-legacy

RE: Securing ActiveX.
by paul＠fatmans.demon.co.uk 17 Dec '03

17 Dec '03

> Armenians are murderous cowards. They killed over 2 million Moslems in > this century alone - mostly women and children. I note that along with this racist generalisation you decided to post the following rant: >As usual, Timmy May spouts racist, anti-Semitic shit. As usual, he has >no idea what he's talking about. So what else is new... As well as a number of other rants along those lines. There is little difference between over generalisations of the kind you made above and, for example, discriminating against someone on the basis of race, colour, religion etc. Datacomms Technologies web authoring and data security Paul Bradley, Paul(a)fatmans.demon.co.uk Paul(a)crypto.uk.eu.org, Paul(a)cryptography.uk.eu.org Http://www.cryptography.home.ml.org/ Email for PGP public key, ID: 5BBFAEB1 "Don`t forget to mount a scratch monkey"

2 1

Re: Executing Encrypted Code
by ph＠netcom.com 17 Dec '03

17 Dec '03

At 8:31 PM 12/19/1996, Timothy C. May wrote: >At 7:34 PM -0800 12/19/96, Peter Hendrickson wrote: >> You could also timestamp the software so that it only runs for a given >> length of time. This will encourage people to upgrade regularly. ;-) > Or to reset their clocks. Which is what many of us do when software is > about to "expire." You are right that this only works in instances where the customer just needs a little prodding to get the upgrade and not in instances where the customer might put up with significant inconvenience to avoid it. However, why not use "beacons"? The clock could have a built-in timer that needs to be reset once a month from an authenticated source. This assumes the presence of net connectivity, but that's not a terrible assumption. Peter Hendrickson ph(a)netcom.com

2 1

Re: Executing Encrypted Code
by ph＠netcom.com 17 Dec '03

17 Dec '03

At 11:16 PM 12/19/1996, Ben Byer wrote: > The manufacturer is going to publish a list of ALL of the public keys? > We're talking one key per chip, right? Isn't that an AWFUL lot of > keys, like, in the millions range? Let's say each key is 2048 bits and there are 10 million processors. That's only 2.38 gigabytes, or under $1000. Easy enough to put on the Web or on a set of CD-ROMs. > Also... with a few million possible keys like this, all you need to do > is to either guess or factor just one of them. Yes, my working assumption is that factoring is very hard. >>> Does the authentication defeat this? >> I'm sort of waving my hands around when I say "authentication". >> One approach is for the manufacturer to authenticate software submitted >> by approved vendors. The vendors are then tasked with encrypting it >> for the correct processor. > I'm not sure the "approved" bit would go over too well... one idea > would be to license the compiler writers, who would build the > encryption into compilers. It's still not horribly great, but > better. You have to have the "approved" message so that you don't get viruses and to thwart piracy in case anybody did manage to get the secret key out of the chip. How well it goes over depends entirely on how much you pay for the software. >>> Our computers would only run software from Microsoft? Scary. >> There are all sorts of nifty deals that could be made. Microsoft >> could commission a special run of the processors which only run >> Microsoft approved software. Machines using these processors could >> be given away or sold at a steep discount. > Right; the only reason I could see people using this would be for > economical reasons. And one would expect piracy-proof software to be very inexpensive. Most people who pay for software have little sympathy for those who don't. >> You could also timestamp the software so that it only runs for a given >> length of time. This will encourage people to upgrade regularly. ;-) >> The processors could also support metering. > Right; once the user loses control of what he's running, then you can > pretty much do anything you want as far as metering goes. Right you are - see below. > ObGAK question: Would this be exportable? I mean, you could be > encrypting god knows WHAT into those .exe's... Key escrow? How would > they get the key?!? I can see the headlines, "Key Escrow Database > Leaked to Pirate Firm"... :) While I am certainly not a lawyer, and even the lawyers can't tell you what is legal to export, I would guess that Big Brother would be delighted with the manufacturers of this processor. It can't be used to encrypt communications, only to decrypt software. What is more, you could control the physical processors so that exportable processors accept a different authentication key. Then, the manufacturer of the processor can take care not to authenticate any privacy enhancing programs for the export version of the processor. Free speech and constitutional issues evaporate because the processors are physical devices and not expressions of ideas. Even "better", not very many organizations in the world can afford the fab lines to manufacture a state of the art processor. So, if the G-7 countries are brought onto the reservation, it would be feasible to forbid all free processors. Peter Hendrickson ph(a)netcom.com P.S. Did you hear? For Christmas Big Brother is raising the chocolate ration from 30g to 20g!!!

1 0

Re: Executing Encrypted Code
by ph＠netcom.com 17 Dec '03

17 Dec '03

At 9:20 PM 12/19/1996, Timothy C. May wrote: >> However, why not use "beacons"? The clock could have a built-in timer >> that needs to be reset once a month from an authenticated source. This >> assumes the presence of net connectivity, but that's not a terrible >> assumption. > I mentioned "beacons" in the portion of my message you did not quote here. Gack! > As for why they are not being used, they don't exist. Here's how I would do it. When the processor wants to update its clock, it generates a random number and encrypts it for the trusted time source. The trusted time source decrypts its message to get the random number. It timestamps it, encrypts it, and sends it back. This means you can't replay old time messages to keep using your old software. Is it possible to have a little clock and rechargeable battery on a chip? If so, then this technique should be easy to use. If not, then the processor can count the number of cycles it runs and use that as an approximate means of deciding when to check the time. Or, it could demand a time update every time it is power cycled. Peter Hendrickson ph(a)netcom.com

1 0

Expedia New Member Information
by accthelp＠expedia.com 17 Dec '03

17 Dec '03

Welcome to Microsoft Expedia Travel Services! Below is your new membership information. Please keep this confirmation mail as a record of your Member ID and Password. Your Member ID is: cypherpunks Your Password is: cypherpunks The Expedia Internet address is: http://expedia.msn.com/ Expedia is a free service. To use the Expedia Travel Agent, you will have to type your Member ID and Password on the Sign In page. Whether for business or pleasure, Microsoft Expedia makes it easy for you to plan and purchase travel arrangements that best meet your budget and personal preferences. Expedia is on the job 24 hours a day, 7 days a week. With a click of your mouse, you can: * Reserve and purchase airline tickets * Reserve hotel rooms * Reserve rental cars * Subscribe to Fare Tracker for the lowest airfares to your favorite destinations * Research over 300 destinations in the Expedia World Guide * Chart your course with over 200 city maps * Check out the world of adventure in the Mungo Park online magazine * Catch up on the latest travel news, weather and more We look forward to fulfilling all of your travel needs. Expedia Member Services Start your travel here. http://expedia.msn.com/

1 0

Re: Proof that "cypher punks" have complete degenerated...
by Adamsc＠io-online.com 17 Dec '03

17 Dec '03

On Thu, 19 Dec 1996 04:24:14 +0000, geeman(a)best.com wrote: >It wasn't worth commenting on. >Appending data after the ctrl-Z as stego? >Not even worth a letter to the ed! >> No one even commented on the latest Dr. Dobbs issue. I know - I was amazed that made it into the issue. It's almost amazing that someone would go to such effort to do this and miss all the [IMHO] easier ways. Simply astounding... # Chris Adams <adamsc(a)io-online.com> | http://www.io-online.com/adamsc/adamsc.htp # <cadams(a)acucobol.com> | send mail with subject "send PGPKEY" "That's our advantage at Microsoft; we set the standards and we can change them." --- Karen Hargrove, Microsoft (quoted in the Feb 1993 Unix Review editorial)

1 0

Re: Executing Encrypted Code
by ph＠netcom.com 17 Dec '03

17 Dec '03

At 9:52 PM 12/19/1996, Bill Frantz wrote: >At 12:08 PM -0800 12/19/96, Peter Hendrickson wrote: >> If each chip has a unique public/secret key pair, and executes >> authenticated code only, there are some interesting implications. >> Software piracy becomes difficult, if not impossible. Code is sold >> on a processor by processor basis. Code for a different physical >> processor cannot be decrypted or executed. > This makes backup hard. That is the rock the routine copy protection hit > up against. There were many, me included, who simply said, "If your > product is copy protected then I will buy from your competitor." No, you can backup just as much as many times as you like. The code isn't stored on the chip permanently, it is only decrypted there. There is a similar problem, though. If your processor dies you could lose your software library. There are ways to mitigate this. One is for the vendors to just trust people and reissue the code to a new processor. Of course, you track how often you have to do this. Or, you could turn in the broken processor and have the manufacturer certify that it was turned in to the software vendors and that a new version of the software should be generated. This might not be so important if you generally pay for metered software. >> Viruses are not feasible if the authentication is strong. > So is user written code, public domain code etc. If there is an > un-encrypted mode for that kind of code, then viruses again become > possible. User written code is harder to arrange, it is true. You might have a way to execute non-authenticated code but at a speed comparable to an emulator. Or, you might just have another computer for running your own code. Right now it is not uncommon for a software library to exceed the value of the machine. It might actually be economical to have two machines if one of them can support a rich software library which doesn't cost as much money because it can't be pirated. Free software is still possible to run at full speed, but it has to be authenticated. The free software writer just has to do whatever the software vendor had to do to get it okayed. This makes it harder to release free software, but the effort is still a small fraction of the work required to build a significant application. Getting it to execute for particular processors is easy. You could release a piece of software which takes code and encrypts it for your particular hunk of silicon. If you could offer otherwise free software for, say, $20 and know that everybody using it will pay, many people might consider that to be a great deal. Right now the mechanisms of moving the software are too expensive to really make it feasible for something under $20. Development might be a bit tricky, but there are workable solutions. The manufacturer could release special processors which have an additional authentication mechanism for software developers which is specific to each developer. They could authenticate code to run on their own machine, but not on anybody else's. This does make it possible for software developers to pirate software (if the can get a secret key), but if the number of development processors is low, this could be manageable. If the environment was well defined, you could conceivably develop in a high level language on one platform, but deploy for sale on the decrypting-processor platform. Peter Hendrickson ph(a)netcom.com

2 1

Re: Executing Encrypted Code
by ph＠netcom.com 17 Dec '03

17 Dec '03

At 1:41 AM 12/20/1996, Scott V. McGuire wrote: >On Thu, 19 Dec 1996, Peter Hendrickson Wrote: >> The manufacturer of the encrypted-code processor would protect its >> instruction set using intellectual property law. Given the high >> price of a fab, it is entirely feasible to stop anybody from building >> a new architecture which can execute the code about as fast as >> the encrypting-code processor. > It seems to me that this is where this scheme would be broken. Have > intellectual property laws been (successfully) used in this way? I don't know, but I bet it would be possible to arrange if there was support for it. Or, maybe the instruction set itself remains a trade secret. Sure, it could leak out, but aren't there laws against industrial espionage? (If the instruction set was secret, the manufacturer might have to provide a compilation service.) > And even if so, would they be enforced in all the countries where the > chips might be fabricated? Yes, if the laws exist they would be easy to enforce. What does a state-of-the-art fab cost now? $5 billion? $10 billion? I was generous when I said "G-7". Which countries can really compete in this market? The U.S. and Japan, I believe. There is no reason to rule out extra-legal pressure, either. The USG appears to have played the policeman in supporting the DRAM market in an informal way. It would be very easy to have a chat with the Japanese government about the importance of stopping software piracy. Peter Hendrickson ph(a)netcom.com

1 0

Ebonics
by Timothy C. May 17 Dec '03

17 Dec '03

In order to remain compliant with the new California law requiring increased use of "Ebonics," the new academic name for "Black English" (and known by honkey mofos as "ghetto jive"). Apparently the coloreds have had enough of "standard English" and its repression of their culture. To meet the requirements of this new law, 10% of my posts from now on will be written as best I can manage in the Ebonic language. Switching to Ebonics: De honks be chimin.' Code be fly! I's huffa be gots to be sizing, bitch. PGP 3 be dope, nuffin but bad! I be axing you if it be outa honkeyland or outa Afrika? Dat bitch Reno be sayin' it be 'legal be usin' dope 'warez. Day be hos. --a melanin-challenged honkey mofo Just say "No" to "Big Brother Inside" We got computers, we're tapping phone lines, I know that that ain't allowed. ---------:---------:---------:---------:---------:---------:---------:---- Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)got.net 408-728-0152 | anonymous networks, digital pseudonyms, zero W.A.S.T.E.: Corralitos, CA | knowledge, reputations, information markets, Higher Power: 2^1398269 | black markets, collapse of governments. "National borders aren't even speed bumps on the information superhighway."

1 0

Test files for encryption
by Steve O 17 Dec '03

17 Dec '03

Can someone point me to any standard files that are used when testing encryption strength. Iie i'm looking for a gourp of files that may have been used by an agency or Internet group in the past that when encrypted were tested for byte frequency etc. as well as cryptoanalytic atacks. thanks in advance. steveo privsoft(a)ix.netcom.com

1 0