- cypherpunks-legacy - lists.cpunks.org

Ahem... 'virus'?
by Dagmar the Surreal 17 Dec '03

17 Dec '03

Let's get a few things straight here before we go any further... I field enough calls from the clooless at work trying to warn me about getting the 'Good Times Virus' in my email without having to worry about yet another meme floating around about email virii. 1. Can anyone show that the .com file replicates? It MUST reproduce itself to be called a virus last time I checked. It looks like a trojan horse to me. 2. How many of you people are using Microsloth Internet Mail? It was mentioned a LONG time ago (I think here, in fact) that there was a major mental lapse on the part of the programmers when designing it because single-clicking a piece of mail will view it, while DOUBLE-CLICKING the mail will execute it (and any attached files!). Most people double-click EVERYTHING in Windoze, and this is why it nailed so many people. I'm surprised I hadn't seen this done sooner. If you think it only got a few of the M$IM users, think again. I'll bet there's a LOT of them out there who are 'suffering in silence' because their computer is completely kaput, or sitting in a shop waiting for someone like me to wipe the hard drive and reinstall everything. Please, if there's going to be another damn meme about email virii, let it NOT be from a list I consider to be at least a LITTLE more enlightened than the hordes of AOL (l)users out there. ---------- Dagmar the Surreal (not actual size) "The Internet is Full. Go Away." -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2 mQCNAzK50XQAAAEEAMoJsT9Rwbd28VUGhag2fOl+QrTnltqHrN2/7CBMy6kcnaba 8j3HIsNY6NzE/62iV67n6uCTlt6r3/ZosZL4RXYerH06bDOAfWZ6AYn6d0OO+vgi sghnFXiUfknU0h7A88R7z4uRRpZNkU0NXL/svZjrL+cOiMRnQUAqcwqI8ynFAAUR tCREYWdtYXIgdGhlIFN1cnJlYWwgPGRhZ21hckBlZGdlLm5ldD4= =34r7 -----END PGP PUBLIC KEY BLOCK-----

2 1

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

17 Dec '03

At the last meeting references were made to processors which only execute encrypted code. Decryption occurs on chip. 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. Even if it is feasible to determine the secret key stored on the chip, software piracy is still hard because it is not possible to execute the code on another chip without authenticating it. One could execute the code on another architecture entirely using an emulator, but there would be a performance price paid. It wouldn't be worth the trouble for most software. 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. Viruses are not feasible if the authentication is strong. Retrieval of the secret key is quite difficult. Since the results of the decryption never leave the chip, the recent attacks against smart cards do not work. (In the case of an error, the authentication fails and the code does not execute. No information has to leave the chip.) I would be interested to hear comments and corrections. Peter Hendrickson ph(a)netcom.com

5 4

Re: "Cryptography Policy and the Information Economy" draft available
by Carl Ellison 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- At 04:11 PM 12/19/96 -0500, Matt Blaze wrote: >I've got a new draft available of my critique of US cryptography >policy and its impact on the future of the "information economy". >It summarizes comments I made to a recent meeting of the Computer >and Communications Industry Association, and is an updated version >of testimony I gave to the Senate commerce committee earlier this >year. > >Postscript is at ftp://ftp.research.att.com/dist/mab/policy.ps >ASCII text is at ftp://ftp.research.att.com/dist/mab/policy.txt Matt, I liked your draft except for one thing. You never mentioned that the government has never established a legal right to access the cleartext of an encrypted communication or file. Perhaps the most severe flaw in the GAK proposals is that I as a citizen wish to attempt to keep secrets from the government and to force them to take me to court to get a judge to demand that I release those secrets -=- while their proposals are trying to prevent me from even attempting such. - Carl -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMrn+WlQXJENzYr45AQFrFgQAp2jfB3EOLJoOKHIpTne7D4cwL1KzPcRg VoELRWDGS1RkgK5cSgLl9ASWZ7TdcMRiQUbDPMoffMi3UWlfIpomdsHq+E4HE/U+ 6CS+cpUfw/eSwBYkotCfETMAHymknu/o06QYfBX0TQsN/2XOC52xXEd9Nb/8xjUW c4RETw8Os8A= =nkcy -----END PGP SIGNATURE----- +------------------------------------------------------------------+ |Carl M. Ellison cme(a)cybercash.com http://www.clark.net/pub/cme | |CyberCash, Inc. http://www.cybercash.com/ | |207 Grindall Street PGP 2.6.2: 61E2DE7FCB9D7984E9C8048BA63221A2 | |Baltimore MD 21230-4103 T:(410) 727-4288 F:(410)727-4293 | +------------------------------------------------------------------+

1 0

Re: Executing Encrypted Code
by Jazzmin Belle Sommers 17 Dec '03

17 Dec '03

>>>> 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." >>However, why not use "beacons"? chop chop chop I have been using some shareware that simply has a built-in counter. Once the counter runs out, you have to register. I would suppose that one could hack the code to find the counter, assuming you could decompile it (or wanted to). Personally I think this is a decent solution to the problem -- the counter on this particular software let you use it 50 times. That's adequate to determine whether you want to keep it or not. Of course, if you saved the .zip file to disk before you installed it, you could delete the copy and reinstall the .zip. But everyone knows this. Jazzmin Sommers

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

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

17 Dec '03

At 9:18 PM 12/19/1996, Ben Byer wrote: >> At the last meeting references were made to processors which only >> execute encrypted code. Decryption occurs on chip. >> >> If each chip has a unique public/secret key pair, and executes >> authenticated code only, there are some interesting implications. > Let's see... What about this scenario: > Alice gets a contraband copy of PGP 4.0 off the Internet. Since the > public-key algorithm is publicized so that people can encrypt software > to a chip, PGP 4.0 has the ability to encode/decode/generate keys for > the chip. Alice generates a public key/private key pair 0x12345678, > in software. Alice goes to www.microsoft.com and orders Office '99 > online, and tells Microsoft "Hi, my name is Alice, my credit card > number is 31426436136778 and my PGPentium's public key is 0x12345678." > Microsoft unwittingly sends Alice a copy encrypted to 0x12345678, for > which she has the private key to. Alice decrypts Office '99, and > reencrypts it with public key of her PGPentium, as well as the keys f > all her friends. The software vendor would be wise to check that the public key was legal. It would be a simple matter for the manufacturer to publicize all public keys that had been installed on chips. > 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. > 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. 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. The processor could support some sort of API for the software to tell it how many computrons had been used and stop it from running after they run out. This means that light users or evaluators of software pay relatively low prices while heavy users pay high prices. This is a great deal for all concerned. Right now software vendors try to do this with clever deals, but it's crude at best. Peter Hendrickson ph(a)netcom.com

4 3

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

C2Net Party: January 24th
by sameer 17 Dec '03

17 Dec '03

http://www.c2.net/party/ C2NET is having a party January 24th at 654 Mission St. San Francisco assorted snacks, a cash bar and live music by WEIRD BLINKING LIGHTS with dj accompaniment by DJ FLINT and DJ PINNIPED will be present for your enjoyment Festivities begin at 8PM We hope to see you there --- Directions: >From the West or North: Take Oak Street East. Turn left on Laguna. Turn right on Fell. Fell crosses Market and becomes 10th Street. Merge left within one block of Market. Turn left on Mission. >From the East: Take Hwy 80 West across the Bay Bridge. Take the first exit on the left (Harrison Street exit) Turn left on Harrison. Turn right on 3rd Street. Turn right on Mission. >From the South: Take Hwy 280 North. Follow 280 to its end at 4th & King Streets. Follow King Street to its end at 3rd Street. Turn left on 3rd. Turn right on Mission. >From BART: Take BART to the Montgomery station Walk south on New Montgomery Street Turn right on Mission. Parking: There is a commercial parking lot across the street on Mission and another one on the corner of 3rd and Mission.

1 0

Key Escrow Rule
by John Young 17 Dec '03

17 Dec '03

The Federal Register of December 13, 1996 has published "Licensing of Key Escrow Encryption Equipment and Software" This parallels the draft regulations for encryption export provided by Steptoe & Johnson on December 11 but sets provisions specifically for key escrow products. We've put it at: http://jya.com/ke121396.htm (39 kb) Here are excerpts from the opening: ----------------------------------------------------------------------- This interim final rule amends the Export Administration Regulations (EAR) by imposing national security controls on Key escrow information security (encryption) equipment and software transferred from the U.S. Munitions List to the Commerce Control List following a commodity jurisdiction determination by the Department of State. This interim final rule also amends the EAR to exclude key escrow items from the de minimis provisions for items exported from abroad and to exclude key escrow encryption software from mass market eligibility. Further, key escrow encryption software is subject to the EAR even when made publicly available. ... Once transferred, key escrow encryption items will be controlled for national security reasons. A license will be required from the Department of Commerce to all destinations, except Canada. This is an initial step in liberalizing the treatment of encryption exports. The Bureau of Export Administration is preparing regulations to further implement the Administration's encryption policies, which will be published in the Federal Register in the near future. ...

1 0