December 2003 - cypherpunks-legacy

Bob Cain's mind switch
by Carl Ellison 17 Dec '03

17 Dec '03

Bob wrote: >The real issue is that this is an *enabling* technology that allows any >group of people distributed over the world to meet spontaneously in >secret to plan anything. I don't think we can even conceive, nor have >they yet, the ways the real Bad Guys (I hope we can agree that some >do exist) might find to use this new ability. A very clear danger is >sensed in Washington with little real benefit to the civilized and >civil majority. There's no question that this is a possibility. It exists. However, Clipper won't make it go away. There's no Daddy to run home to. In fact, this has always been a possibility, unless you believe that all hotel rooms, bus stations, city parks, farmer's fields, men's rooms, women's rooms, ..., are bugged and will continue to be (so that clandestine meetings can be overheard). Now, the next step for the NSA and FBI is to get on the stick and discover ways to counter this threat. Now that PCs permit criminal organizations to create their own strong crypto and worldwide communication allows them to telecommute cheaply, interaction among criminals for planning purposes will be enhanced just as interaction among businesspeople and computer designers is. The world is changing -- as usual -- and LE needs to keep up -- as usual. --------- That isn't hopeless. However, it requires thinking in new ways and I don't expect bureaucrats to be able to do that. Perhaps technical people need to be given a free hand. :-| Maybe the result is that there is no security. For example, we should not expect to achieve more protection from plans laid during electronic meetings than we would achieve from plans laid during physical meetings. ..and, no, I don't believe there should be a law prohibiting private physical meetings. There will *always* be some insecurity. There is always a nut with a gun out there. There are also car accidents. I am not totally safe and would not want to live in a world in which the police are powerful enough to make it that safe. ---------- What I kept suggesting to Dorothy Denning, as this flap was building, was that: 1. the gov't should immediately drop the Clipper proposal because it's alienating people who need to be on the gov't's side; 2. the gov't should actively promote encryption of cellular calls with an untappable algorithm, for the over the air link (with conversion back to clear voice once it hits the cellular office) -- providing the public with trustworthy security, addressing the public's biggest security threat and therefore reducing the market demand for encryption which interferes with wiretaps; and 3. the LE and intelligence community should recognize that the world has changed beyond the point of no return, thanks to the PC and to communications technology, and there is no way to prevent criminals from using totally secure cryptography to aid in their plans. Criminals have always had access to strong cryptography for their communications (cf., Kahn talking about the rum runners, for example (Elizabeth Friedman's efforts as a cryptanalyst)) and the world hasn't fallen apart yet. However, the PC and high speed digital communications mark a slight change in the landscape and these changes need to fuel some good, creative, technical work -- not a bureaucratic running-scared retreat to an impotent "there oughtta be a law". I don't know if it's too late, thanks to the FBI and NSA serious alienation of people (like us) who matter. It might be. Once they declared war on us, it's unlikely to expect us to suddenly look at them as good guys. However, if they followed my 3 step plan right now, they'd have a chance still -- at least, I believe they would. - Carl

1 0

Re: low-overhead encrypted telnet
by smb＠research.att.com 17 Dec '03

17 Dec '03

Eric Hughes says: > The reason that encrypted telnet is a good thing is that modificatio n > at the network level requires kernel modification, and encrypting a > telnet does not. Installing an encrypted telnet daemon does require > sysadmin cooperation, but it doesn't mean recompiling the kernel. Although running an encrypted IP stack does require sysadmin cooperation, it does not require a kernel rebuild -- John Ioannidis has built modloadable versions of most of the swIPe software. Assuming, of course, that you're running a system that has modload. (Ironically, CERT has recommended that you delete loadable device drivers from systems that don't need them, as a way to guard against password- sniffers.) > As such, encrypted telnet is a good intermediate while the long term > solution of encrypted IP gets developed and deployed. Agreed -- sadly its arriving VERY slowly. 4.4BSD Lite comes with a standards-compliant encrypted telnet implementation, however. What standards? There are no RFCs, nor any current drafts, that define a telnet encryption option. The last draft I saw was from 1991, and Internet drafts expire after 6 months. As I recall, the idea that was being pushed then was to integrate encryption more closely with authentication.

3 2

ALERT: UK anti-porn network proposal
by russw＠netcom.com 17 Dec '03

17 Dec '03

The author of the following notice is in a sensitive vocational position, and has asked me to post the following... ###BEGIN### A Home Office press release issued on 15 Feb 94 announces the intention of the Home Secretary to crack down on computer-distributed pornography. Accordingly, last week the government introduced an amendment to the Criminal Justice and Public Order Bill which is pending before Parliament. The new clause in the Bill would amend the definition of *publication* in the Obscene Publications Act 1959. It is currently considered *publication* of a pornograph image if one *record, shows, plays, or projects it.* The proposed amendment would change this to read: ... record, shows, plays, or projects it, or, where the matter is stored electronically, transmits that data. The problem, of course, is that there is no definition of what it means *to transmit* pornographic data. There is no distinction drawn between primary and secondary transmission. This could mean that bulletin board sysops, commercial sites with Usenet feeds, and even BT, could ALL be engaged in the *transmission* of pornographic data. If this is correct, then people in the position of innocent intermediary would have to rely upon a defense of *innocent dissemination*, much like that found in UK defamation law. Essentially, if the police could show that pornographic images had passed over one's computer equipment, then one would have to prove that he *had not examined the [pornographic] article and had no reasonable cause to suspect* that its publication was illegal. Aside from being in the uncomfortable position of having to prove one's ignorance, the *reasonable cause* language may imply a duty to inspect certain data in a vain attempt to see if it contains pornographic images. This especially could be true where one provides a data feed to a known past-pornographer. It is not entirely clear why the Home Office thinks that this amendment is necessary. If the intention is to catch commercial pornographers, it would appear that *record* should include recording to CD-ROM or into RAM. Likewise, *play* should catch purchasers. The justification might be that proof of recording and playing is much more difficult than proof of transmission. CAVEAT: This discussion does not include radio and television broadcasts. There is a seperate section of the Act which specifically addresses this area. It is not clear whether or not the proposed *transmits* language would have any effect upon that section, but presumably it could. It is difficult to believe that large players like BT, Mercury, CompuServe, etc, will let this pass without a fight. It could also be, however, that they are unaware of the possible ramifications of the proposed amendment. ###END### [I will forward responses to this message. - Russell] Russell Earl Whitaker russw(a)netcom.com Director, Extropy Institute 408-366-5435 ================================================================

1 0

Re: Clipper/Skipjack
by koontzd＠lrcs.loral.com 17 Dec '03

17 Dec '03

>just a quick note to tell you all that I just read an editorial in >info security by John Droge. >Anyway, I was wondering why any sane, 1/10 intelligent person would be >defending the Clipper chip...then I read his bio...he is a VP at >Mykotronx. He is also the marketing manager for CLIPPER/CAPSTONE

1 0

'Nother possible Stego place...
by Alan (Miburi-san) Wexelblat 17 Dec '03

17 Dec '03

It's a bit of a hack, but don't most char implementations in C just ignore the high-order bit? --Alan Wexelblat, Reality Hacker, Author, and Cyberspace Bard Media Lab - Advanced Human Interface Group wex(a)media.mit.edu Voice: 617-258-9168 Page: 617-945-1842 na53607(a)anon.penet.fi We are Chaos Boys. We are coming to a paradigm near you.

2 1

Re: encrypting the list (Was Re: Insecurity of public key)
by Eric Johnson 17 Dec '03

17 Dec '03

: Eric Johnson says: : > I don't think "adjust[ing] on a case by case basis" is necessary. : > I was suggesting just the opposite. It obviously isn't a security : > issue. I believe it is more of a first principles issue; "Thou : > shall encrypt thy communications, lest thou draw attention to thy : > self, and the right be removed by thine opponents." : : You miss the point, Eric. We are advocating that IN THE FUTURE all : communications should be encrypted. However, FOR THE MOMENT this is : often impractical. Cypherpunks write code in an effort to try to bring : this future closer. However, making our lives impossible right now : will delay that future. This is hyperbole. It would not make our lives impossible. And far from delaying the future, as it relates to communications on the list, I would argue that it would reduce the signal-to-noise ratio immensely, thereby hastening the deployment of tools. So I don't think I'm missing the point simply by disagreeing with you. : I encrypt things whenever possible. Some people I communicate with : can't encrypt, so I adjust, on a case by case basis. Someday, : hopefully within the next year or two, things will be different. : : Encrypting this list ever would be useless -- but fine if it would : be easy to do. Since it isn't easy or useful, it is a bad idea. It's usefulness depends both upon whether you think increasing the ratio of cryptext vs. cleartext to your system is useful, and whether easy is defined by the least capable systems on the list. Don't worry. I'll drop it here. : : Perry BTW, you don't have to shout. I can read upper-lower case text without difficulty. --Eric

2 1

Defenders of Clipper
by area51＠aol.com 17 Dec '03

17 Dec '03

Hi everyone, I've been watching this list for a few weeks now, and I really don't see any real basis for defending Clipper. It seems the essential arugment of Denning and others is, "Well, we can't tell you what we're afraid of, but trust us, we should be afraid". Can they not tell us because they don't know? Or is it some sort of "secret" they fear? Obviously, widespread secure communications would make life much easier for criminals. Yes, terrorists will be able to make their secret plans using cryptography. But, I would hasten to point out that the Trade Center bombers managed to pull their attack off with NO encrypted conversations that I've heard about. And yes, next time it might be a nuclear bomb. There, is that the unnamed terror? Or is it that the intelligence community is learning all the neat-o toys they bought for SIGINT are rapidly becoming worthless, and in reality there's absolutely nothing they can do about it. They'll have to strengthen their long neglected human intel-gathering side, much as some members of their own community have been arguing for years. The real reason Denning, the NSA, et al are arguing for Clipper is that they realize their professions are becoming obsolete. Welcome to the ranks of the techo-unemployed. Just as nuclear proliferation marches on slowly but surely, so will high-tech crypto. Information wants to be free, as they say, and the implication here is you just can't stop it. Does the government really think they can stop everyone in the world who wishes this nation harm from using crypto? I think not....So they better get on the ball really defending us... Sorry for rambling on.... Rod Ramsey Area51(a)aol.com

1 0

PEM, was Re: low-overhead encrypted telnet
by Pat Farrell 17 Dec '03

17 Dec '03

In message Wed, 2 Mar 1994 11:55:32 -0600 (CST), Jim McCoy <mccoy(a)ccwf.cc.utexas.edu> writes: > I sincerely doubt that such a system would be designed or implemented > before the turn of the century. All one needs to do is take a look at the > PEM key certification authority clusterfuck to see just how difficult it > can be to implment something like this. I have to admit that PEM's RSN availability against PGP 2.X's 20+ months of worldwide availability has made me not keep up with PEM and the latest hierarchical, government controlled certification process... But is there an intrinsic problem with a PGP-style web of trust for remote telnet/rlogin applications. I really don't expect to login to arbitrary nodes on the net, but is that required? or simply a robust way (SecureID in software?) Maybe PCMCIA cards with PGP once desktop systems have them. If i'm cluelessly missing something essential, please email me the news. Thanks Pat Pat Farrell Grad Student pfarrell(a)gmu.edu Department of Computer Science George Mason University, Fairfax, VA Public key availble via firger #include <standard.disclaimer>

1 0

RE: Laziness?
by Pat Farrell 17 Dec '03

17 Dec '03

In message Wed, 2 Mar 1994 10:38:55 -0800 (PST), tcmay(a)netcom.com (Timothy C. May) writes: > I connect to the Net from my home Mac IIci or PowerBook 170 over a > 14.4 modem line to Netcom, an Internet service provider many of you > are familiar with. Once on Netcome, I have access to a wide range of > standard UNIX tools. However, I do NOT run PGP on these machines! > > Rather, I run MacPGP (or PGP on my DOS machines, in emergencies, or > even "MailSafe" in rare circumstances) on my *home* machine, after first > downloading the mail with "Eudora 2.0," a nice off-line mail reader. > It still takes several steps, as most of you can imagine. I use a similar system to Tim's, except that I use NUpop on a "PC" to download 150+ messages a day from cypherpunks and a bunch of other lists. We have to move the tools to the user's controlled, secure environment. For some that may be Unix, but for close to 98% of the 'net community, a controlled computer is a Mac or PC. At GMU, a few supported grad students have personal Suns or other workstations, maybe 50 students out of 22,000. But nearly all of the students in the techy schools have at least a PC or mac that is under their personal control. Multi-user Unix solutions don't cut it. More importantly, if all 700+ of us on this list used encrpytion for _every message every day_ it would be only an insignificant portion of the net volume. We have to get encryption out to the masses. Pat Pat Farrell Grad Student pfarrell(a)gmu.edu Department of Computer Science George Mason University, Fairfax, VA Public key availble via finger #include <standard.disclaimer>

1 0

Windows Programming help wanted.
by Pat Farrell 17 Dec '03

17 Dec '03

This is a repeat of a request that I made last fall. I got no real response then. Perhaps as the list has grown, someone will respond.... I am looking for help on a Microsoft Windows development project. I have most of a Windows Client SMTP mail client program written, but I can't devine how to make the Windows Communications API work with any marginal success. I need help from someone who has written Windows communications software. The program is functionally equivalent to NUpop or Eudora. It is designed to work over dialup asynchronous lines without TCP/IP. Not that I dislike all the nice functionality tht TCP/IP provides, but because some netowrk providers (such as George Mason University) refuse to support SLIP/PPP for political reasons, and because other providers (Netcom for one) charge orders of magnitude more for SLIP/PPP than for async support. The resulting product will be user firendly, a native Windows program with the usual buttons, icons, context sensitive help, etc. It will have PGP, and maybe RIPEM, support built in. Automagically. I plan to release the code to the net, and will give full credit in the About Box, documentation, etc. for any help. Please respond via email. Cypherpunks write code. Thanks Pat Pat Farrell Grad Student pfarrell(a)gmu.edu Department of Computer Science George Mason University, Fairfax, VA Public key availble via finger #include <standard.disclaimer>

1 0