- cypherpunks-legacy - lists.cpunks.org

MFC, was [Visual Basic (yes, Basic!), and "VBX" tools
by Pat Farrell 17 Dec '03

17 Dec '03

In message Wed, 4 May 94 13:36:38 -0700, hughes(a)ah.com (Eric Hughes) writes: >> fortuitous decision to incoporate Windows "foundation classes" (a C++ >> notion, of course) into Visual Basic > > Classes are C++. Foundation classes are Microsoft Foundation Classes, > are just a large library that Microsoft wrote which is also included > in the C++ compiler products. It is correct that MFC is simply a set of C++ classes, which are included (and their source) in the Microsoft Visual C++ environments for Windows and Windows NT. But there are significances to MFC that should be mentioned. (They are also included in the Samatec [sic] compiler products. Probably others RSN) First, MFC (and related parts of MSVC) makes writing Windows applications orders of magnitude easier than using the old SDK approach. Just as with the Borland class suite, no one who has used MFC will ever go back to hand-coding SDK calls, except for the occasional wild hack. Secondly, and IMHO more importantly, MFC 2.5 makes it easy to write OLE 2.0 compliant applications. OLE is the foundation of Microsoft's "component software development" approach (see last month's Byte for a good overview). OLE is how Microsoft expects folks to hook applications together in a seemless way. OLE is used currently in Office to make Word, Excel and Powerpoint interoperate transparently, and its use will grow when Chicago is released (RSN, I know) With little work, a programmer should be able to make an OLE server that allows users to drop Word, Excel, or other documents into an "encryption server" or write an OLE client that uses the server. Most of this can also be done with Visual Basic, which is a cool tool. But Visual C++ is still C, so it makes grabing parts of PGP or PGPTools and building them into the servers and clients is much more "native" Thirdly, MFC effectively isolates the programmer from the OS. As a long time assembly hacker, I wasn't too keen on this. But MFC makes porting trivial for most Windows and Windows for Workstations (aka NT) apps, and RSN we are supposed to get MFC for the Macintosh. This will cover some huge portion of the desktop computing universe. Once you are above 95% of the market, I don't care about arguing the last percent or two. For those on this list that like to "write code" and speak some C or C++ I strongly recommend looking at Visual C++ and MFC. At $129 for the "competitive upgrade" it is even pretty cheap. Please followup off list if you need more info, like recommended configurations, etc. Pat Pat Farrell Grad Student pfarrell(a)cs.gmu.edu Department of Computer Science George Mason University, Fairfax, VA Public key availble via finger #include <standard.disclaimer>

1 0

DEATH TO TYRANTS
by Tim May 17 Dec '03

17 Dec '03

By the way, I don't recall it being mentioned that the message from "IRS Inspection" had an interesting subject line: DEATH TO TYRANTS. I don't know if this was on the message others received, but it was on my version. Included below are the headers. Odd that this would be used, and probably not coincidental that the famous quote has been in my most recent .sig for only a few months, and only _after_ the Bell arrest (as far as I can recall). It's unlikely the IRS "Inspectors" had any mail from me via Bell's computer(s) with this quote in it. --Tim May >Received: from you for tcmay > with Cubic Circle's cucipop (v1.13 1996/12/26) Fri Jul 18 19:25:02 1997 >X-From_: irsnwpr(a)net.insp.irs.gov Fri Jul 18 15:30:05 1997 >Received: from tcs_gateway1.treas.gov (tcs-gateway1.treas.gov >[204.151.245.2]) by you.got.net (8.8.5/8.8.3) with SMTP id PAA28395 for ><tcmay(a)got.net>; Fri, 18 Jul 1997 15:29:59 -0700 >X-Real-To: <tcmay(a)got.net> >Received: by tcs_gateway1.treas.gov id AA19560 > (InterLock SMTP Gateway 3.0 for tcmay(a)got.net) > Fri, 18 Jul 1997 18:36:21 -0400 >Received: by tcs_gateway1.treas.gov (Internal Mail Agent-2); > Fri, 18 Jul 1997 18:36:21 -0400 >Received: by tcs_gateway1.treas.gov (Internal Mail Agent-1); > Fri, 18 Jul 1997 18:36:21 -0400 >Date: Thu, 17 Jul 1997 12:18:35 -0400 >From: IRS Inspection <irsnwpr(a)net.insp.irs.gov> >Message-Id: <199707171618.MAA02670(a)net.insp.irs.gov> >To: Interested-Parties(a)net.insp.irs.gov >Subject: DEATH TO TYRANTS > > > > United States Attorney > Western District of Washington > >FOR IMMEDIATE RELEASE >July 18, 1997 > >JAMES D. BELL PLEADS GUILTY TO OBSTRUCTING THE IRS AND USING FALSE SOCIAL >SECURITY NUMBERS .... There's something wrong when I'm a felon under an increasing number of laws. Only one response to the key grabbers is warranted: "Death to Tyrants!" ---------:---------:---------:---------:---------:---------:---------:---- 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."

2 1

NYT article - WOW
by L. Detweiler 17 Dec '03

17 Dec '03

Markoff has written a BRILLIANT article. Virtually all the facts are right on, and he dances around the technical issues expertly, cutting to the core. This is FANTASTIC fodder for the cypherpunk cause! Probably just what PRZ dreamed of when he first wrote PGP :) Does anyone know Markoff's email address? Some minor idiosyncrasies, though. >Receiving the Federal subpoenas were Viacrypt, a Phoenix company >that plans to sell a licensed version of P.G.P., and Austin Code >Works of Austin, Tex., which is selling a version of P.G.P. for >other software developers to incorporate their own programs. Say what? this is false, from what I understand. *Maybe* `selling a version of RSA'? There is a rumor that G. Ward intended to include PGP in distribution disks, unconfirmed. But so far it appears there is very little related between G. Ward and PGP. >The >grand jury subpoenas, which the companies received Sept. 9 from what I can figure out so far, ViaCrypt got theirs on Tuesday, G. Ward on Thursday. This from their online statements. But it could have happened on the same day. Note that getting *served* a subpoena on the same day is very interesting -- if they were just dated on the same day and received at different times, that would be more realistic. If they were *served* simultaneously, that implies some kind of systematic coordination. Did somebody want to make sure that both places were hit exactly at the same time? Did they anticipate the rapid-fire explosion in cyberspace that would ensue? Remember, the grand jury is in California -- it would take some planning to have the summons *received* simultaneously. Don't they have to be delivered in person by agents? >Both publishers said they had no plans to sell their products >abroad. hee, hee. I wonder what Austin Code Works would think of G. Ward's Usenet postings... Pres. Leonard Mikus of ViaCrypt >"They're on a fishing expedition [...] hm, I wonder where I saw that term used before? >President Clinton alluded to the problems of controlling >distribution of software technology in a speech last week promoting >the North American Free Trade Agreement. > >"Nothing we do in this great capital can change the fact that >factories or information can flash across the world, that people >can move money around in the blink of an eye," the President said. >"Nothing can change the fact that technology can be adopted, once >created, by people all across the world and then rapidly adapted in >new and different ways by people who have a little different take >on the way that technology works." holy *cow* -- this sounds like something John Barlow of EFF would write! he almost appears to be alluding to *digital cash*! Obviously, Mr. President forgot to clear his remarks with the NSA first! Saying things like this, perhaps we should start a cypherpunk feed to president(a)whitehouse.com! cypherpunks, who'd ever have thought we'd have something from Mr. President for our signatures?! `technology rapidly adapted in new and different ways by people who have a little different take on the way that technology works' -- this is virtually from the Cypherpunk Charter. GAD! >"There is a First Amendment right to speak in a encrypted way," >said Eben Moglen, a professor of law and legal history at Columbia >University who is familiar with the case. "The right to speak >P.G.P. is like the right to speak Navajo. The Government has no >particular right to prevent you from speaking in a technical manner >even if it is inconvenient for them to understand." wow, this is *awesome* press. First time I've seen the constitutional aspect of cryptography dealt with. Markoff has got to be my absolute favorite writer. this is all what is called `bitter joy' ...

1 0

Forwarded Article
by gtoal＠an-teallach.com 17 Dec '03

17 Dec '03

This article was forwarded to you by gtoal(a)an-teallach.com (Graham Toal): --------------------------------- cut here ----------------------------- Newsgroups: mail.cypher Received: from post.demon.co.uk by mailhost.an-teallach.com with SMTP id AA11163 ; Thu, 23 Sep 93 12:41:47 GMT Received: from relay2.uu.net by post.demon.co.uk id aa07673; 23 Sep 93 9:14 BST Received: from toad.com by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA19504; Thu, 23 Sep 93 04:09:31 -0400 Received: by toad.com id AA29715; Thu, 23 Sep 93 01:03:46 PDT Received: by toad.com id AA29712; Thu, 23 Sep 93 01:03:11 PDT Return-Path: <karn(a)qualcomm.com> Received: from qualcomm.com ([129.46.62.22]) by toad.com id AA29707; Thu, 23 Sep 93 01:03:08 PDT Received: from servo.qualcomm.com by qualcomm.com; id AA27850 sendmail 5.65/QC-main-2.1 via SMTP Thu, 23 Sep 93 01:00:40 -0700 for cypherpunks(a)toad.com Received: by servo; id AA10225 sendmail 5.67/QC-subsidiary-2.1 Thu, 23 Sep 93 01:00:39 -0700 for cypherpunks(a)toad.com Date: Thu, 23 Sep 93 01:00:39 -0700 From: Phil Karn <karn(a)qualcomm.com> Message-Id: <9309230800.AA10225@servo> To: cme(a)ellisun.sw.stratus.com Cc: cypherpunks(a)toad.com In-Reply-To: Carl Ellison's message of Tue, 14 Sep 93 23:53:23 EDT <9309150353.AA06198(a)ellisun.sw.stratus.com> Subject: more than spread spectrum This idea of setting up your own independent network isn't as far fetched as it sounds, at least in a relatively local area with critical mass. The router nodes already exist, in the form of my own TCP/IP code for the PC, or any of several other packages including the various freeware UNIX clones. Radio transmission equipment operating under Part 15 of the FCC rules is already available. Under Part 15, you don't need a license; the radio transmitter does have to be "type accepted" by the FCC but since you buy that as a prepackaged box you don't have to worry about it. The section of Part 15 that is particularly interesting is either 15.247 or 15.249 (can't remember which). It allows you to run up to 1 watt of power, quite a bit for an unlicensed service, on any of several "ISM" (aka "garbage") bands as long as you use spread spectrum with a minimum processing gain of 10dB. The most popular is 902-928 Mhz, with another band in the vicinity of 2450 Ghz coming up fast. Ahthough most Part 15 equipment is designed primarily for use within office environments, it can be and is used over point-to-point paths of 5-10 km with the proper directional antennas. Although Part 15 users are not allowed to cause harmful interference and must accept interference from other users (microwave ovens generally operate on 2450 Mhz), in practice these nets seem to work pretty well if they're properly engineered. Besides, the inherent distributed redundancy available in a packet network should be able to compensate for momentary outages due to interference. Unlike the amateur service, which has some particularly draconian "acceptable use" policies (despite a recent liberalization, encryption is still illegal), there are *no* restrictions on the use of Part 15 equipment. Encryption is not only legal, some boards have hardware encryption support (e.g., the NCR Wavelan has a DES chip). This particular board operates at 2 megabits/sec on the 902-928 Mhz band with 250 mW of power. There is an even more interesting development in the works: "data PCS". In essence, this is "Part 15" style operation on dedicated spectrum, i.e., new spectrum in the 1.8-2.2 Ghz band that will not have to be shared. The specific intent of data PCS is to allow users to build their own ad-hoc networks without having to rely on the facilities of (and pay money to) carriers such as telephone companies. Phil --------------------------------- cut here -----------------------------

1 0

Re: Why RSA?
by smb＠research.att.com 17 Dec '03

17 Dec '03

Let me try to answer some of these questions by giving a broad overview of patent law. I'm not a lawyer, but I've spent a lot of time talking to lawyers about patents during the last several years, and about what they are and aren't. First of all, a patent is (theoretically) a contract between an inventor and society. In return for the inventor teaching everyone about the new idea, he or she gets a monopoly on use of that idea for a limited period (normally 17 years in the U.S.). Patents cover the right to build, make, import, or even *use* the protected idea. A patent is *not* a license to do something. Rather, it is the right to prevent others from doing it. Thus, if I invented the pencil, and you invented the eraser, neither of us could make a pencil+eraser without permission from the other. Patent infringement is not a crime; you cannot go to jail for it. It is a civil offense, and the patent holder has to sue you for infringing. You can get a patent for things that are new, useful, and non-obvious. All three criteria must be satisfied. Note specifically that a new use for an old idea is patentable. R, S, and A did not patent particular equations; rather, they patented certain specific uses for those equations. If you can find a new use for them, you're home free. (I and a colleague almost did that. We came up with a new application for them, and we felt that the security of our scheme would be strengthened tremendously by the work that's gone into RSA. However, our application was just different enough that I managed to crack it. Sigh. But better that I cracked it before publishing...) For our purposes, a patent consists of two major parts. The first is more or less a technical paper; this is what you're supposed to learn from. Some of the language is rather stylized, but for the most part it will be comprehensible to someone who understands the field. The second part is the ``claims''; these are written in very dense legalese, and are supposed to delimit exactly what's new. You infringe a patent if your activity includes all of the elements of any one claim. Writing good claims is at the heart of a patent attorney's skills. You want to claim as much as you possibly can, even if you think some of it is worthless -- but you have to make sure that what you claim doesn't include prior art. In the RSA patent, for example, almost every claim speaks of both encryption and decryption. The idea of mine that I alluded to involved encryption only; thus, it did not fall within the scope of all but one of the RSA claims. For various other reasons, it didn't fall within the scope of the other one. > All are patented in so far as one of the patents covers ALL public k ey > schemes. Some, like Rabin's scheme, have possible technical advantag es > over RSA. First, a note: "Rabin's scheme" is (as Perry said) the one provably linked to factoring (a major advance!) and I assume it's the one implemented in RPEM. According to the RIPEM FAQ, PKP squashed that development by claiming that their patents were broad enough to cover Rabin's scheme, and the effort was abandoned "for pragmatic reasons" (another example of how superior technology can be suppressed by monopolies). Well, Rabin's scheme has other problems as well, including the lack of an unambiguous decryption algorithm. You get a few answers, one of which will be correct. Under patent law, though, the ``superior'' technology hasn't been suppressed. Rather, Rabin would need a license from RSA (and Diffie-Hellman) to practice his invention. And he couldn't have come up with his idea unless RSA had been published. Now, I've looked a little further into the patent issue, and I remain kind of confused. I went to the library and read the four patents in question (but only made a hardcopy of the first chronologically). I found the documents difficult to understand (for legal rather than crypto-tech reasons). All four applications were made in 1977-1978, and the patents were granted variously from 1980-1984. The earliest one has Hellman, Diffie, and Merkle as inventors; the second just Hellman and Merkle. Both are assigned to Stanford University. It seems to me that one of these is the one that covers, broadly, public key cryptography -- presumably the earliest one (4,200,770), since it has all three major players as inventors and the language of the eight claims seems to be rather broad (though only the second patent, 4,218,582, has the phrase "public key" in its title). Patent 4,405,829, granted in 1983, is for the RSA algorithm [footnote: the RSA patent apparently celebrated its tenth birthday two days ago; was there a party?]. There is no overlap between this patent's inventors and assignees and the earlier more general patent. Here's a question for somebody in the know: if the earlier patents cover all public key cryptography and RSA is a public key system, isn't it in violation of the earlier broader patent? Does PKP pay license fees to Stanford, or were they granted exclusive rights by Stanford as well as MIT? As I explained above, a patent does not infringe per se. However, practicing RSA would indeed require a license from Stanford. But both Stanford and MIT assigned exclusive licensing rights to those patents to Public Key Partners, a deal which arguably violates the antitrust laws. (Down, libertarians, down. I know you don't believe in such things...) Anyway, patent 4200770 claims virtually all mechanisms for public key distribution or exchange systems. Exponential key exchange is the particular example given; it's claimed, too. Patent 4218582 claims all of public-key cryptography. The knapsack system was the particular system given; it was claimed, as well. I should note here -- to patent something, while you don't (as a rule) have to build it, you do have to show that it's buildable. If there's any doubt, the patent examiner can order you to produce one. This is used to deal with perpetual motion machines and the like. The concept of public key cryptography couldn't have been patented without a working example. And, while knapsack systems were subsequently cracked, at the time the patent was issued there were no (publicly) known attacks. Similarly, apparently a public-key scheme called Warlock has been granted patent protection. How is this possible if somebody else holds patents covering all of public key encryption? If I understand patents correctly (hah!) they last for 17 years from the time they are granted. This means that the earliest public key patent will expire in about 3.5 years. After that presumably there will be no restrictions on new public key systems. The RSA patent would expire in 2000. If somebody could clarify which patent is the "broad" public key patent, I'd appreciate it (even with them right in front of me, I can't tell)! My guess is that it would have to be either 4,200,770 or 4,218,582 -- if it's the latter, how did Merkle get squeezed out of inventorship? Have a look at "The first ten years of public key cryptography", Diffie, W., Proceedings of the IEEE 76:5, 1988, pp 560-577. Respondents to my initial questions pointed out that the patents may be over-broad and could be challenged on those grounds; given the history of how public key crypto was invented, it seems to me that it would be difficult to contend that the idea is obvious (Simmons says that the idea "stunned" the crypto community) -- but I'm no lawyer, and I'll leave that issue to those with more skill, brains, and money than me! There was some question of prior art published more than one year before the patent was filed. See "Multi-user cryptographic techniques", Diffie and Hellman, AFIPS Proceedings 45, pp109-112, June 8, 1976. The patent apparently contains some language explaing why that doesn't count, and in particular because there was no demonstration that it was even possible to build such a thing as a public key cryptosystem.

1 0

Where'd pgptools go?
by Hal 17 Dec '03

17 Dec '03

I notice on csn.org:/mpj there is now pgptl10d.zip, PGP Tools version 1.0d. However, 1.0d is not the whole PGP Tools program. It is just an addendum which implements Diffie-Hellman. Apparently pgptl10c.zip is still needed to give you the whole of PGP Tools. Does anyone know of an FTP site which still has pgptl10c available? Thanks - Hal

1 0

Screen and secure sessions
by rcain＠netcom.com 17 Dec '03

17 Dec '03

What follows is part of a dialog I am having with netcom support right now about the use of the Screen hyper-shell. I've been using it between home and work and it is awesome if you have never seen it. The man pages for it in ascii are ~rcain/pub/screen.man if you are on netcom and want to check out what it can do. There is someplace here I could put it for anon ftp if somebody could tell me the name of that drirectory from a netcom shell. The dialog starts as a discussion of the problem I have with the two or three minute inactivity timeout on the San Jose modems and is mostly about the low impact I see it having on resource usage. If you know all about Screen or aren't really interested in a bunch of justification, go forward about 100 lines to get to the part that discusses crypto. Peace, Bob > Netcom Support sez: > > > > Robert Cain writes: > > > > > > [some stuff deleted] > > > > > > First the short duration of your modem timeout pushes the envelope of > > > the ridiculous. I'm not sure what it is but when a brief conversation > > > or call of nature causes it to disappear *IT IS TOO DAMNED SHORT*. > > > > I'm sorry you have a problem with our policy, but we have no > > intent to change it in the future. We'll take your suggestions > > under consideration, but as I said we have no plans to modify > > it at this time. > > You certainly sound intransigent. What would the implications of > doubling it be for example? You could at least try it for a while > and see if it has the effect of increasing the load on modem banks > signifigantly. What is the currently programmed inactivity interval > anyway? I lost it again in the middle of this damned note because > I got a phone call. Damn I hate it when that happens. At lest > this time there was a "vi -r" message in my mailbox after logging > on. > > > > > > > I have a solution to this that I am using on our sun network at > > > work. It is a package called "screen" that has wonderful features > > > like multiple windows (all stacked one atop the other) that are > > > easy to create and switch between if you want several contexts > > > available at once. The most exciting feature is that if I wish > > > to or if my line goes down, I can reconnect to it at the next > > > login and pick up as if nothing had happened. This would be a > > > wonderful feature at netcom too. I know that your no nohup > > > hacks prevent us from having processes that persist when we log > > > off (OR ARE FORCED OFF) but if you changed that specifically > > > for the screen processes and it's descendants to instead reduce > > > them to the lowest possible priority until a reconnect then all > > > this hassle would go away and netcom could offer a very neat > > > feature. IBM mainframes have had disconnect/reconnect forever and > > > I've never understood the lack of it on Unix. Here it is! It > > > is a very friendly and powerful capability. Users would love it > > > and the cost to netcom would be entries in process tables and > > > swap space for the processes. You seem to have more than enough > > > of those kinds of resources now. Please consider it. > > > > The use of "Screen" is not supported on Netcom because of its drain on > > system resources. It violates our policy against running detached > > backround processes. This is also a policy we have no plans to modify > > at this time. > > Hmmm, I'm not sure you read me. What I am suggesting would not > violate the intent of your policy WRT detached background processes. > Let me try and persuade you. > > If whatever you use to kill processes upon detachment, logout or forced > by timeout, could instead merely lower their priority to the minimum > then, as I said, they would not load the system's cycle capacity, > merely occupy some process specific tables and some swap space. I am > pretty sure that in one of the netcom newsgroups (to which I am posting > a copy of this) we hassled this out and it was determined what the cost > in real memory was for a process's tables that was totally swapped > out. It was truly insignifigant in proportion to the size of real > memory that is on the systems. There is little drain on system > resources if you do this unless the number of processes becomes > absurdly high. > > Yes, there is a cost for swap space. Is it possible to set up your > unix to use more than one swap area? If so then it could be arranged > that a user's pages were swapped into storage he is paying for > (possibly after he/she had exceeded some limit in the system swap > area) and then this would become a revenue generator for netcom rather > than a drain on resources. If that is not a thing you know how to do > then you could simply establish a daemon that checks the number of > processes (or the total size) and warns the user when he is in > violation of the limit. That limit should be based on a determination > of the real cost in process tables and swap space rather than just set > arbitrarily. I don't see how my request does much more than offer > serial line users <!!the same advantage that lucky telnet or rlogin users > enjoy!!>. They can and do stay logged in indefinitely and in effect have > various processes running all the time without concern about an > inactivity timeout. > > Arguing against having a bunch of virtual windows makes no sense > because you can effect that if you know emacs reasonably well anyway. > Screen is just an easier way that doesn't require one to learn emacs. > As a hypershell, Screen has *many* powerful features for power users. > For fairly naive users only a fairly few keystrokes need be > remembered to use it's most useful features. In combination with > the menu program you offer it would be very powerful across a slow > line. > > One of Screen's features is a rather elaborate filtering mechanism whereby > all incoming keystrokes and outgoing screen data can be filtered by > user programs. I would like to use this to add encryption for my phone > line. It would be straightforward to encrypt my outgoing and incoming > data here at my PC that is acting as a terminal since I think my terminal > emulator has similar filter hooks so the same programs that I used on > the netcom end or my work end would function on this end as well if I > explicitly wrote them to be that way. Given that, I would make Screen > effectively my login shell, have it negotiate (via the filters) a > secure link with my terminal emulator here at home and then go through > another password process before invoking my startup shell. Viola I no > longer have to worry about someone grabbing my real password nor can I > be snooped or spoofed between my system and a system at netcom. This > has *HUGE* advantages to users and I will use a cypher (IDEA) in a mode > that is *very* fast so that the system load that would be introduced > by the crypdec filters would not be all that great. I have all the > necessasary C libraries of long integer math routines and hard crypto > functions as well as the theoretical knowledge of crypto needed to code > what's left to write such a filter. > > Hell, Screen's capability would *greatly* enhance Netcom's account > attractiveness and good crypto could be used as a big selling point in > attracting commercial accounts where you make substantial profit per > account. In fact when I get this to work I wouldn't be surprised if > users demand it. :-) > > I have the man pages for Screen in my ~rcain/pub directory if anybody > at netcom wants to check out Screen's capabilities. I could also > make them temorarily available for incoming anon ftp if requested. > Now, while all this is true in theory, in all honesty I am too deeply involved in other things (like a day job) to actually do the implementation I speak of but I *do* have all the tools if anybody else wants to take a shot at writing the filters. Since screen runs across rlogin just fine, if this were done I could rlogin to any other machine on the net and have a secure session across the net. I think it could also be made to be secure across "talk" or "irc" sessions and even email between machines. It could also be used as the front end to any text based telnet port too. So if you want to be able to dial in securely at least and communicate with a system that is secure, and across systems that are secure badly enough to put the time into it (or pay me enough to quit my day job :-), here is a chance to maybe make some history. I think this is the right way to get a start on global network security. Screen offers such a rich environment for single windowed connections already that it is a natural starting point given that it's author has thought ahead to the kinds of filters we need. It also could care less what shell you run and it is transparent to the applications running below it (from the experience I have had to date) It is a work of art to begin with IMHO and with this crypdec capability there would hardly be a reason not to use it since if you don't know it and don't want to learn, you won't know Screen is there until you invoke it's commands with the ctrl-A key (which can be changed to anything else as an escape if you use applications that are fond of ctrl-A.) Peace and hoping, Bob -- Bob Cain rcain(a)netcom.com 408-354-8021 "I used to be different. But now I'm the same." --------------PGP 1.0 or 2.0 public key available on request.------------------ --

1 0

FIDO, steganography, PGP
by Karl Lui Barrus 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- I've had fun writing this! This is a PERL script that takes as input a PGP encrypted, ascii output file. It skips the headers and stuff, and converts every character in the body into a geographic name. I don't think I'll have a chance to write the reverse script tonight, but it will coming along soon. So maybe this can be used to mail other people lists of geographic names rather than encrypted messages since I've heard some networks frown upon encrypted mail :-) Generate your PGP file, and invoke the script like this: pgpsteg < encrypted_file_ascii_output > steg.out and steg.out will contain a list of places derived from your input file. - ----------8< cut here >8---------- #!/usr/local/bin/perl #simple minded steganography for pgp encrypted messages #Karl L. Barrus <klbarrus(a)owlnet.rice.edu> %conversion = ( '0', 'canada', '1', 'united states', '2', 'mexico', '3', 'pacific ocean', '4', 'atlantic ocean', '5', 'arctic ocean', '6', 'gulf of mexico', '7', 'north america', '8', 'allegheny mountains', '9', 'rocky mountains', 'a', 'alabama', 'b', 'alaska', 'c', 'arizona', 'd', 'new mexico', 'e', 'arkansas', 'f', 'california', 'g', 'colorado', 'h', 'connecticut', 'i', 'rhode island', 'j', 'delaware', 'k', 'maryland', 'l', 'florida', 'm', 'georgia', 'n', 'hawaii', 'o', 'idaho', 'p', 'illinois', 'q', 'indiana', 'r', 'iowa', 's', 'kansas', 't', 'kentucky', 'u', 'louisiana', 'v', 'maine', 'w', 'massachusetts', 'x', 'michigan', 'y', 'minnesota', 'z', 'mississippi', 'A', 'missouri', 'B', 'montana', 'C', 'nebraska', 'D', 'nevada', 'E', 'utah', 'F', 'new hampshire', 'G', 'vermont', 'H', 'new jersey', 'I', 'new york', 'J', 'north carolina', 'K', 'north dakota', 'L', 'south dakota', 'M', 'ohio', 'N', 'oklahoma', 'O', 'oregon', 'P', 'pennsylvania', 'Q', 'south carolina', 'R', 'tennessee', 'S', 'texas', 'T', 'virginia', 'U', 'washington', 'V', 'west virginia', 'W', 'wisconsin', 'X', 'wyoming', 'Y', 'washington d.c.', 'Z', 'bermuda', '+', 'guam', '/', 'puerto rico', '=', 'virgin islands', ); while (<>) { last if /^-----BEGIN PGP/; } while (<>) { last if /^$/; } while (<>) { last if /^-----END PGP/; $line = $_; chop $line; @pgpchars = split(//,$line); while (@pgpchars) { $convert = shift @pgpchars; print $conversion{$convert}, "\n"; } print "\n"; } - ----------8< cut here >8---------- -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLKvBOYOA7OpLWtYzAQGsAwP/Y5xZx5nZdKYM785zQSmPAU60UqqqU7X+ bAZ6+6f0foC2bo7AfClSTcAcCmZkCyPAL10toB6Qs0Qzkoe6eZKSlRVJgy9WzDdB oZhJV/jlvYxxlgpBJXz95sJ7ADxmtIBw6jIbfRYPjX1zva7GenTeBzXcMTabJUZJ SPG853ZqWeA= =0MEu -----END PGP SIGNATURE-----

1 0

DC Physical Meeting This Saturday
by pfarrell＠netcom.com 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- This Saturday, March 12 starting at 3:00 PM EST and running until 5:30 PM, there will be a physical Cypherpunks meeting at the EFF's offices in downtown Washington DC. The meeting title is: Cypherpunks distributed meeting Politics, Strategies, and Action The meeting will run in parallel with several other c'punk meetings. If the technology works, we will have realtime audio feeds from other sites. If not, we'll call in using speakerphones (bring your long distance credit card as EFF is _not_ sponsoring us.) With the Clinton Administration's continued insistance on Clipper and the current revision of the FBI's Digital Telophony bill, we c'punks "inside the Beltway" need to get organized. Please do not bring PCs or floppies. We will be inside EFF's offices, and should not bring in, nor take out, any hardware or magnetic media. Paper copies of the MD5 hash of your PGP/ViaCrpyt keys for swapping are fine. We can use email or the keyservers to exchange the actual keys. Some EFF staffers are interested in getting signatures for their ViaCrypt keys. So this will be a good chance to expend the web of trust. Directions: EFF is at the Metro Center stop of the Metro. There is nearby street parking. The Metro stop is literally inside the building lobby. Address is 1001 G street, North West. This is the corner of 11th and G. EFF is in suite 950 East, but the meeting is on the 8th floor. Coming by the metro, leave the station through the Woodies Deli. Go though there, and there will be a set of double doors oposite an escalator. Go though the doors, around a corner and up two escalators. You should then be in the lobby of the EFF building. Off the street, We are next door to the Grand Hyatt, which is right across the street from the Washington Convention Center. Once again, come in and you should be in the lobby of our building. We will send folks down on the hour to let you into the EFF's secure space. Outside of those times, you can set up an appointment, or you will need to call up to get an EFF staff member to come down and let you in. Call 202-347-5400. ext 224 and ext 205 will probably get answered Saturday. Questions: Contact pfarrell(a)netcom.com or leave a voicemail (up until about noon Saturday) at (703) 267-2986) -----BEGIN PGP SIGNATURE----- Version: 2.3a iQBVAgUBLX1aIR9bGnaOb/KNAQF5BgIAx6SwF1q2H2W/Pt85g7TdfWV+vQIuU6oZ k42HeH8+CiRftiIGbtueso9v/hF1sLYAyUs+/4NAYPXegLpLzbrUbQ== =GlHV -----END PGP SIGNATURE-----

1 0

Why the chip in my dog won't work in humans.
by collins＠newton.apple.com 17 Dec '03

17 Dec '03

>> Today I ran into a situation that made me completely nausiated and feel like >> my privacy had been completely invaded... It involves a chip which is >> implanted in animals and used for identification... I have such a chip in my dog. Why? Animal services can destroy a stray animal after as little as 48 hours. My dog doesn't speak English, and if she loses her tags and gets lost --- she's a stray! Animal services scan (and you have to be pretty close, like those door-opening-id-cards) all the animals that are picked up. If there's a chip, the animal WON'T BE DESTROYED. They'll call the Infopet service, who will in turn call me, and I'll come pick her up. Additionally, I have pre-authorized emergency medical attention for her. If she needs help, she'll get it even if they don't know where I am. And, as others mentioned, if she is stolen then the next time she is taken in to the vet (my vet and many others in CA scan as a matter of course) or picked up by animal services ... I will know about it. I love my dog. She's a good companion; and I take good care of her. She has never lost her tags or `gotten loose'. But if she ever does... ...this chip will help me recover my property. Whoa! what happened to loving companion? How did we go from friend to chattel? The truth of the matter is that the law considers and dog _owners_ act as though dogs are property. They have value. They need to be protected like any other piece of property. I love my dog, but that doesn't change the fact that if she fell in love with YOU and wanted YOU to be her master and decided she no longer loved ME ... she would still stay with me, because she's mine. - --- - Is this the edge of a slippery slope for putting chips in human beings? I don't think so. The reasons for having such a device in a dog are completely different from the reasons for having them in an human being. In one case it is essentially to identify property (like a brand on a cow -- we still don't brand humans), in the other it is to make a certain kind of deception more difficult. Marking children as though they were animals or property? Grotesque. Marking adults for identification? Hopeless. Dogs don't even know what a chip is, let alone that they have one implanted in them. They won't remove or replace it; but a human bent on such a course will. Therefore, as identification or proof of permission, it will be no better than the cryptographic system beneath it. In which case, it will be pointless to have an implant rather than a smart card. Scott Collins | "That's not fair!" -- Sarah | "You say that so often. I wonder what your basis 408.862.0540 | for comparison is." -- Goblin King ................|.................................................... BUSINESS. fax:974.6094 R254(IL5-2N) collins(a)newton.apple.com Apple Computer, Inc. 5 Infinite Loop, MS 305-2D Cupertino, CA 95014 ..................................................................... PERSONAL. 408.257.1746 1024:669687 catalyst(a)netcom.com

1 0