December 2003 - cypherpunks-legacy

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

17 Dec '03

At 4:17 PM 12/20/1996, Andrew Loewenstern wrote: > I think this whole idea of encrypted software and processors is pretty >poorly > thought out. Thank you for this encouraging remark. > How do you handle an organization with a site license for 20,000 users of a > piece of software? Do you issue 20,000 unique copies? Yes, that would be necessary. It isn't hard to tell which executable goes with which processor. The software vendor could give away a database to do it. Or, the software vendor could put all the executables up on a web site. What's the big deal? > Do you really think the lower price of the software is going to offset > the cost of an organization to manage all those processor certificates? Yes, I do. (BTW, the software might be sold for the same price, but be better in other ways.) > Site licensed software is already about as cheap as the companies are willing > to sell it. In the current business environment. One reason site licenses are sold to companies is to make piracy less encouraging. It also solves a difficult bookkeeping problem: "How many copies are we running? Are we in compliance with the law?" Actually, site licenses don't always solve this problem, but they sort of do. We don't really know what pricing and terms would look like in a piracy-free environment, we can only guess. My guess is that preventing piracy makes more software available for better prices. If metering is feasible, it would work out very well because customers no longer have to take a chance on software and can easily explore all of the options they have. > How about the extra hard drive space you have to purchase because you can't > just keep one copy on a server anymore? Let's assume 10MB of executable code per package. A gigabyte costs about $200 now. That comes out to about $2 extra expense per software package. > Think about what a nightmare it would be to update a piece of software on > 20,000 machines simultaneously!! It's hard enough to do it now!! Whoever is doing the updating just needs to be able to quickly get the right copy. That's easy because each software module is self-identifying as is each processor. You just need to be able to go out on the Net to the software vendor or internally and ask some machine for the particular copy you need. > What happens if a software company goes out of business? You are then > completely screwed when your processor dies or becomes obsolete. This is true. Most people make their software buying decision based on what it can do now and for the next few years. I believe that is rational. > Around here we still run a few pieces of ancient hardware that were pretty > pathetic back in 1988. The software on them is critical but won't run on > anything else and there is no source code available. Believe me, nobody > here would dare to make that mistake again!!! At least with our current > situation if the hardware dies we would probably be able to find a > replacement (and I'm sure there are some replacements waiting in the stock > room...). But with your encrypted processor we couldn't even do that! Yes, it would definitely be harder to keep a code museum. People who plan on doing that are encouraged to choose another platform and software set. > It seems to me that this is yet another scheme that basically does nothing > but seriously inconvenience the software user. Much like clipper, I believe > this is a dog that won't hunt!! I find it interesting that you compare this scheme to Clipper. Judging from the tone ("!!!") of your post, there is something about my scheme which you find upsetting. People usually don't get annoyed by schemes which won't work. (Even dumb unworkable schemes are a breath of fresh air on this list right now.) What I think you really don't like about my scheme is that you think it might work and you fear various mandatory GAP proposals that could follow its wide acceptance. I would be interested to hear more about these concerns. > Perhaps instead of trying to find a way to force users into paying, software > companies should concentrate on how offer more value and make their prices > seem more attractive. These are not either/or propositions. If the decrypting processor increases the revenue of software companies, it means people can make more money providing better products to their customers. > Even with piracy, the software industry is far and away the most profitable > of all!! There is no such thing as "profitable enough." Peter Hendrickson ph(a)netcom.com

1 0

re: Executing Encrypted Code
by AwakenToMe＠aol.com 17 Dec '03

17 Dec '03

In a message dated 96-12-20 16:43:37 EST, you write: << I would suppose that one could hack the code to find the counter, assuming you could decompile it (or wanted to). >> Nope. Just a good debugger (Softice... Borland..etc) And not to mention there's a billion disassemblers on the net

1 0

Re: Flying on planes without ID
by AwakenToMe＠aol.com 17 Dec '03

17 Dec '03

In a message dated 96-12-20 17:23:29 EST, you write: << Anyone have the current black-letter regulations? I'll have some time to kill over the holidays that might as well be used for civil disobedience. What's likely to happen to me if I refuse to show ID? Provide invalid ID, don't get caught, then publicize the fact? Provide invalid ID and get caught? Or, better: "My wallet was stolen. The only ID I have on me is my ACLU membership card and my PGP key. Can I still get on the plane?" >> Well, something of the sort happened to me... I didn't have my ID on me. (Delta airlines..) and they _WOULD_NOT_ let me on the plane without the proper ID. I actually had lost my ID shortly before... Then... A different time at the airport.. American airlines told me that If I didn't have ID.. Id still be let on... just that the way they process my baggage would be different ( I imagine they would physically look through it... Adam

1 0

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

17 Dec '03

At 5:25 PM 12/20/1996, Andrew Loewenstern wrote: >Peter Hendrickson writes: >> I would expect software prices to drop because everybody using >> the software would be paying for it. > I don't mean to sound rude or insult you personally, but this is utterly > absurd. If everyone is paying for the software then the company would be > making even MORE money. Only a fool would want to make less money!! If >money > wasn't important to these people they wouldn't be in the business of selling > software in the first place! > Aside from putting a gun to people's heads, the only thing that lowers >prices > is competition. Yes, I was assuming a free market. Sorry if that was not clear. Not only would software companies face competition in the decrypting-processor market, but they also face competition with other packages running on other platforms. Presumably customers would need some sort of reason to use the decrypting-processor. Some companies may choose lower price. > Only a fool would want to make less money!! I agree completely! >> It is not out of the question for software vendors to sell >> two versions of the same software. One is the piracy-free >> version and the other is the copy-as-much-as-you-can version. >> I would expect the piracy-free version to be substantially >> cheaper. > That would render the entire scheme pointless. It only takes _____ONE_____ > copy of the software to get out for the whole world to pirate it. This was discussed a few posts back. Let's say you manage to get the secret key out of the decrypting-processor. That gives you the executable which could run on any decrypting-processor. Since it is not authenticated (*) you can't run it on another decrypting-processor. You can run it in emulation someplace else, but a heavy performance price is paid. If the leading edge processors are all decrypting-processors, a very heavy performance price is paid. If the instruction set is kept secret, even writing an emulator could become hard. (* I am being inconsistent, incidentally. At one point I said that software would be authenticated once, but I now realize that to prevent multiple uses it has to be authenticated for use on a particular processor, too.) Peter Hendrickson ph(a)netcom.com

1 0

van Eck snooping
by azur＠netcom.com 17 Dec '03

17 Dec '03

I've done some experimentation in this area. It is not possible to use a VCR in a simplified manner anymore as all recent computer CRTs are no longer use a 60 Hz half-frame, interlaced, format. Reductions in radiated emissions, per FCC Part 15, since the earlt 80's have significantly raised the bar for remote monitoring (still possible though). -- Steve

1 0

Solidarity with Peruvian Guerrilla!
by aaron＠burn.ucsd.edu 17 Dec '03

17 Dec '03

** See list of useful Web sites at end of this post! ** Companer@s, I am writing this while I am tired and should be asleep, since I think that this matter is too urgent to delay. I apologize for any careless formulations. By now, you all know that the Peruvian guerrilla group MRTA (Movimiento Revolucionario Tupac Amaru) has occupied the mansion of the Japanese ambassador in Lima and is holding several hundred prisoners. Unless you are in an unusual part of the world, you also have seen how the bourgeois media are discussing the matter as a problem of how to deal with 'terrorists.' For the working people and all the oppressed and exploited of the world, and for socialists, communists, and anarchists, the seizure of the ambassador's residence along with about 400 bourgeois dinner guests is a great accomplishment. It is a blow against the terrorism of the Peruvian state and its imperialist patrons! Those captured in the raid include many members of the Peruvian and international ruling elite, including the head of Peru's secret police! It will be politically very difficult for the Peruvian state to launch a military attack as a means of resolving the crisis, since that would create quite a few 'illustrious corpses' and lead to a falling out among bourgeois sectors.. (And it would be difficult to get the world's poor majority to join the bourgeoisie in mourning its dead!) It seems that there is already a falling out between Fujimori and the Japanese over Fujimori's refusal, so far, to negotiate. It is very important that the situation in Lima not be resolved in a way that can be seen as a victory for the bourgeoisie. It is our task to publicize who the real criminals are in Peru and to help wring concessions from the Peruvian dictatorship. In particular, we should demand the release of all political prisoners and prisoners of war from Peru's hideous torture-chamber prisons. In this context, let's not get involved in sectarian battles among the various factions of Peru's anti-government left. Whatever differences the groups have, and these are very serious, we must keep in mind that the Peruvian state and its imperialist backers (in Washington, Tokyo, London, Bonn, etc.) are the main enemy. All political prisoners must be released, whether of MRTA, the PCP (Shining Path) or neither. Thanks to the widespread publicity given to the events in Lima, many more people will be interested in what we have to say about Peru than normally would. Let's organize demonstrations at Peruvian Embassies, Consulates, airline offices, etc. Let's raise our voices in whatever forum may be available to defend the heroic guerrillas and to denounce the real terrorists. --In solidarity, --Aaron <aaron(a)burn.ucsd.edu> P.S. Plans are being made for a demonstration at the Peruvian Consulate in San Francisco, California -- probably on Monday, December 23. If you live in the area, please send me an e-mail message. Otherwise, do what you can in your area! SOME USEFUL WEB SITES: Web site on the current crisis: <http://burn.ucsd.edu/~ats/mrta.htm> What Are The Goals Of Your Embassy Occupation? -- Interview With Norma Velazco, Representative Of The Tupac Amaru Revolutionary Movement (MRTA) In Peru: <http://burn.ucsd.edu/~archive/ats-l/1996.Dec/0089.html> Partial list of hostages: <http://burn.ucsd.edu/~archive/ats-l/1996.Dec/0092.html> MRTA's web site in Europe: <http://www.cybercity.dk/users/ccc17427/> Lima's best bourgeois newspaper (in Spanish): http://ekeko.rcp.net.pe/LaRepublica/

2 2

RE: The Ebonic Plague
by blanc 17 Dec '03

17 Dec '03

From: Timothy C. May Democracy has run amok in this country. There is no hope for reforming at the ballot box, as democracy only makes things worse. Only a crypto reign of terror can purge this land of the scum. ...................................................... Just how would this take shape in "real life" - what would constitute this reign of terror; how do you envision such an event in action? And which are the scum who would be purged? .. Blanc

4 5

New Australian export regulations
by pgut001＠cs.auckland.ac.nz 17 Dec '03

17 Dec '03

Australia's new export control regulations have just been posted to the net, you can get them from http://www.adfa.oz.au/DOD/al/iic/excontrl/excohome.htm (they're all Word 6.0 documents, I've been reading them with a binary file browser - blech). What makes them interesting is that most of the text is word for word identical to the Canadian regulations (which is sensible, since the Canadian ones are clear and easy to follow, unlike the US "We'll let you know when you've broken the law" FUD regulations). The only thing which is different is the section numbering, the mapping from Canadian to Australian section numbers appears to be: 10xy.y.z -> xY00?.Y.Z where y -> Y == 1 -> A, 2 -> B, etc and z -> Z == A -> 1, 2 -> B, etc, so that Canadian 1151.1.c becomes Australian 5A002.a.3 (this doesn't work in all cases, if there's no .n suffix on the Australian number then the .n part from the Canadian number becomes part of the main Australian number, eg 1071.5 -> 7A005. The text may not be taken straight from the Canadian one because some of the spelling mistakes in the Canadian one aren't present in the Austrlian one, or maybe it was prepared from a later version which had been spelling checked. For crypto software, you want cat_5.doc, equivalent to section 1150 of the Canadian regulations. Anyway, here's the good bit, in sou.doc, "GENERAL TECHNOLOGY NOTE (PART 1 - MUNITIONS LIST)" >3. Controls do not apply to "technology" "in the public domain", to "basic > scientific research" or to the minimum necessary information for patent > applications. Again, this is identical to the Canadian regulations. Since the Canadian government has already ruled that a whole variety of crypto software is exportable under this exception, it means that the same stuff (and equivalent software from Australia) should also be exportable, or at least that you've got a very good case for arguing with the Australian government if they decide it's not exportable. Then in definits.doc we again have the Canadian text: >"In the public domain" (GTN NTN GSN), as it applies herein, means >"technology" or "software" which has been made available without restrictions >upon its further dissemination (copyright restrictions do not remove >"technology" or "software" from being "in the public domain"). It's nice to have this stuff laid out at last, because it finally takes the Australian crypto controls out of a gray area and defines them so that stuff like SSLeay and my own cryptlib aren't restricted. Incidentally, there's also the cute: >1. The export of "technology" which is "required" for the "development", > "production" or "use" of items controlled in the Munitions List is > controlled according to the provisions in the Munitions List entries. > This "technology" remains under control even when applicable to any > uncontrolled item. This covers virtually any software development tool, and any kind of computer hardware, as well as natural neural networks and personal digital extensions (of the kind designed for keyboard data entry). I wonder if we'll see the regulations retroactively changed when someone in Canberra realizes what they've copied from the Canadian regs :-). Peter.

1 0

WIP_out
by John Young 17 Dec '03

17 Dec '03

12-21-96. NYP: "Global Agreement Reached To Widen Law On Copyright" On-Line Material: International law would specify that copyright protection includes the right to control the on-line distribution of copyrighted materials, as well as the right to prevent others from making unauthorized copies. "Fair use" -- the tradition of allowing individuals to make a limited number of copies for noncommercial purpose, or to use brief excerpts in news reports or artistic criticism -- would still apply in cyberspace. In a compromise meant to defuse one of the harshest criticisms of the treaty, negotiators agreed to delete language that would have treated even temporary copies of material downloaded from the Internet as possible violations of international copyright law. ----- WIP_out ---------- WIPO on the Web: http://www.wipo.org

1 0

Security hole in premail
by Mixmaster 17 Dec '03

17 Dec '03

There's a pretty nasty bug in premail that allows any non-root to obtain the contents of the premail secrets file. This is a race condition that can be exploited because an indefinite amount of time can pass between the time that premail checks if the secrets file exists and when it tries to write to the file. It can be exploited as follows: attacker: $ umask 111 $ ln -s ~/premail-secrets-file /tmp/.premail-secrets.$< normal user: $ premail -login Remember to logout when done. Your premail passphrase, please: All the attacker has to do is execute "touch premail-secrets-file" between the time that the user is prompted for the passphrase and the time when the login is completed. $ ls -al premail-secrets-file -rw-rw-rw- 1 d00d nogroup 19 Dec 20 19:01 premail-secrets-file $ cat premail-secrets-file [contents of premail secrets file] This bug can be fixed in two ways. One way is to set the premail-secrets setting to some non-world-writable directory. The second way is to apply the following patch: *** premail.orig Fri Dec 20 18:46:01 1996 --- premail Fri Dec 20 18:55:54 1996 *************** *** 3574,3579 **** --- 3574,3582 ---- } for ($triesleft = 2; !$done && $triesleft; $triesleft--) { $pass = &getpass ($x); + if(!-O $ps) { + &error ("Secrets file exists and is owned by another user\n"); + } $status = &decrypt_secrets ($ps_pgp, $ps, $pass); if (!-s $ps) { unlink $ps; } $done = (!$status && -e $ps);

1 0