December 2003 - cypherpunks-legacy

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

Re: Credentials without Identity--Race Bits
by drose＠AZStarNet.com 17 Dec '03

17 Dec '03

aaron(a)herringn.com wrote: >Flew down to LA recently with a firearm (checked, of course). > >Looking over the ticket later, I was mildly surprised to find "GUN" in >a string of otherwise unintelligible text. This is a case of damned if you do, damned if you don't. The last time that I declared (as the legal notices at the check-in podium admonished me to do) a firearm in my luggage, my bag sported a large, chromium yellow GUN tag that also featured a graphic representation of a pistol (I guess for baggage handlers who can't read, or can't read English, and would still like to take advantage of one of the perks of their position).

2 1

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

Instruction Sets which are tough to emulate
by ph＠netcom.com 17 Dec '03

17 Dec '03

I'm guessing there are a bunch of ways to make a processor hard to emulate. For instance, you can make the registers 65 bits wide. Can anybody think of some more? Peter Hendrickson ph(a)netcom.com

2 1

Re: Ebonics
by Matthew J. Miszewski 17 Dec '03

17 Dec '03

At 11:29 AM 12/20/96 -0800, Timothy C. May wrote: (snip) >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. Jesus Tim. You're letting your lilly white show. -feeling-oppressed-by-every-law-in-existance-white-boy Matt

8 8