December 2003 - cypherpunks-legacy

NSA Security
by a2＠ah.com 17 Dec '03

17 Dec '03

Seymour M. Hersh, writing in the November 1, 1993 _New Yorker_, comments: "...current and former high-ranking officials with access to intelligence, whose information has been extremely reliable in the past, specifically told me that the National Security Agency, which is responsible for electronic intelligence, had produced no significant high-level intercepts from Iraq in years. American intellignece experts have concluded that the Reagan Adminstration's policy of providing satellite and communications intelligence to Iraq in the mid-nineteen-eighties had an unwelcome side effect: the Iraqi intelligence service learned how to hide its important communications from the N.S.A.'s many sensors." I am posting this to help provide an insight into some of NSA's motivations. If you think this is disinformation, consider the motives for creating it -- the insights are similar. -a2

1 0

Hardware encryption device...
by Michael J Kirwin 17 Dec '03

17 Dec '03

Hey 'Punks! I found a kit to build a hardware encryption device. The whole kit costs less than $120 and both partys need one. There rather slow however, the top speed is only 1200 baud. I found the article on it BYTE September '86. Here's the address of the place that sells the kit CCI P.O. Box 428 Tolland, CT 06084 If anybody does get this kit and trys it out I would be interested in how it turns out. Drop me a line. Thanks, Michael mkirwin(a)acs.ohio-state.edu

1 0

MEDIA: PGP in CompuServe Magazine
by russell＠eternity.demon.co.uk 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- 1 Nov 93 Yesterday, 31 Oct 93, in London, some of us privacy advocates held another meeting of the UK Cryptoprivacy Association. One of our regulars brought in the latest CompuServe Magazine, the issue of November 1993. I was delighted to read an article (pp 19-25), "The Digital Deadbolt", strongly advocating the use of secure cryptography, including PGP 2.3. The article, written by Christopher J. Galvin, an associate editor of the publication, was truly an advocacy piece. For those on CompuServe (CIS) who were unfamiliar with the issues, cogent and useful reasons for using encryption were given, with pointers for finding the relevant software. I quote: ZIFFNET PUBLIC BRAND SOFTWARE APPLICATION FORUM (GO PBSFORUM) Pretty Good Privacy 2.3 - The controversial program PGP combines the convenience of the RSA public-key cryptosystem with the speed of conventional cryptography to protect e-mail and data files. Includes digital signatures, data compression before encryption and sophisticated key management. Manual included. Freeware. Library 1, "Hot Off the Presses," PGPRIV.ZIP (232,895 bytes). Further file references included text in the CYBER FORUM (GO CYBERFORUM) on anonymous remailers (Library 13, "MONDO 2000," PRIVAC (7,078 bytes)), and a NIST publication on public-key cryptology in ELECTRONIC FRONTIER FORUM (GO EFFSIG), (Library 3, "The Frontier Files," PUB_KE.EXE (125,472 bytes)). CompuServe claims a worldwide subscriber base of around 1 million accounts. Every account holder is sent a monthly copy of CompuServe Magazine. Based on this circulation alone, the article is a notable achievement in public access to strong encryption. What makes it even more notable is the bald admission in the article that "... PGP and RIPEM aren't circulating as far as they might. They've been removed from various CompuServe forum libraries and some university Internet sites by sysops and administrators concerned that export laws might be violated by online availability." Those who are puzzled as to why, then, PGP is listed in the same article as being available _through_ CompuServe should take note that it is not available _on_ CompuServe. Having had some CompuServe experience myself, I was struck by what I think might be the case here: Ziffnet is a separate service from CompuServe (CIS), with CIS acting solely as a gateway. Ziff-Davis is a very large publishing house. Anyone who's been to trade shows around the world has run across the Ziff-Davis booth, where various of its magazines - the biggest names in the business - are given away as samples. It may be an ill-informed hunch on my part, but I suspect that Ziff-Davis is drawing on its statutory rights as a _publisher_ to make PGP available through one or more gateway services. If this is the case, I applaud them. And I congratulate CompuServe for having run Mr. Galvin's article. Christopher Galvin can be reached at 70003.5571(a)compuserve.com. Russell Earl Whitaker whitaker(a)eternity.demon.co.uk Communications Editor AMiX: RWhitaker EXTROPY: The Journal of Transhumanist Thought Board member, Extropy Institute (ExI) Co-organizer, 1st European Conference on Computers, Freedom and Privacy, London, 20 November 1993 -----BEGIN PGP SIGNATURE----- Version: 2.3 iQCVAgUBLNRf6YTj7/vxxWtPAQEotgP/SU04KS325v8ca8ydCgr/358QsxmHhz// TtHkdhLRjvDLeWOEbG5LKY1VsVovU5YY1ru8h1xjrMqLiWvv4LQJanhg7I+D3Cpr J5xhM0IZSMotYKmCdY20SRdw918VA8JlNck+r1n40ozgdY8yOsAO6qdjOsolyquA OXShI0Gkzf8= =U0GH -----END PGP SIGNATURE----- -----END PGP SIGNATURE-----

1 0

unsubscribe
by D Nicoll 17 Dec '03

17 Dec '03

unsubscribe please thanks

1 0

Re: Secure Phone Progress (fwd)
by jim＠Tadpole.COM 17 Dec '03

17 Dec '03

Most (US-based) phone equipment can't deal with clear channels, (ok, long strings of zero data) thus, a DS0 (the cannonical single voice call) operates with one bit always set 'on', so your 64kbps channel is now a 56kbps channel. 4:1 compression would get you to (just) inside the magic '14400' bps limit of v.32bis signaling. Such algorithms exist, though their performance on data with characteristics like 'voice' is poor at worst. CLEP is a speech encoding algorithm (compressor) that can work well inside a 4800bps channel. It is, however, quite expensive in terms of CPU power. A DSP would help here. :-) CLEP also tends to diminish the dynamic range of its input, with a resulting loss of 'quality'. Writing things in assembly is not a magic bullet, making the algorithm go faster just as a consequence of it being hand-rolled. The v.fast (28000 bps) modes may, or may not work at 28000 bps between any two endpoints. (subscribers). Jim

2 1

Anonymous remailer with encryption (query)
by Alan Ruttenberg 17 Dec '03

17 Dec '03

Is there a stable anonymous remailer which can encrypt any mail that it sends to me?

1 0

Re: Secure Phone Progress (fwd)
by karn＠qualcomm.com 17 Dec '03

17 Dec '03

>Um... Well, you should be able to do that with an ordinary sound >board/digitizer and a modem. However, 14400 bps (without compression) >isn't enough to transmit sound waves at normal frequencies. [...] There are a few minor misstatements in this note. Standard telephony samples 8000 times per second, with 8 bits per sample. You can easily sample fast enough to get all important speech frequencies into 14400 bps -- at the expense of reducing the resolution of each sample. The resulting speech would be understandable, but highly distorted. There are many other speech coding methods that work somewhat better, including various forms of delta modulation (sending just the differences between adjacent samples). These are probably the best in the bang-for-buck department (Motorola's CVSD is already widely used in secure voice radios operating at 16 kb/s or so). But if you really want high quality at low data rates, you pretty much have to use a vocoder. All of the methods mentioned above try to reproduce the (important parts of) the speech waveform. Vocoders work by modeling the human vocal tract and sending the parameters that describe it at any particular moment, instead of attempting to encode the actual waveform. Since these parameters correspond to things that move relatively slowly in the modeled system (e.g., the muscles of the tongue, jaw, lips, etc) they consume much less bandwidth than the actual sound that's produced. What makes CELP so computationally expensive is the "C" part. CELP stands for Codebook Excited Linear Prediction. The modeling scheme I just mentioned is the Linear Prediction part; the Codebook Excitation part is used to drive it. It corresponds to the vocal cords in the vocal tract. As I understand it, the analyzer picks an entry in a predefined "codebook" that produces the best results, i.e., synthesized speech that most closely matches the original sound. This is a fairly brute-force process; we're talking tens of DSP MIPS to do this in real time. I don't know anyone who has done it in assembler on a widely available general purpose CPU, but I would be ecstatic to be proven wrong. Phil

1 0

ANON: remailer list
by nobody＠alumni.cco.caltech.edu 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Cypherpunk anonymous remailers, 11/1/93 Q1: What are the anonymous remailers? A1: 1: remailer%chaos(a)bsu.edu 2: nowhere(a)bsu-cs.bsu.edu 3: hh(a)cicada.berkeley.edu 4: hh(a)pmantis.berkeley.edu 5: hh(a)soda.berkeley.edu 6: 00x(a)uclink.berkeley.edu 7: cdodhner(a)indirect.com 8: hal(a)alumni.caltech.edu 9: cs60a-qu(a)cory.eecs.berkeley.edu 10: ebrandt(a)jarthur.claremont.edu 11: catalyst(a)netcom.com 12: sameer(a)netcom.com 13: remailer(a)rebma.mn.org 14: elee6ue(a)rosebud.ee.uh.edu 15: elee7h5(a)rosebud.ee.uh.edu 16: hfinney(a)shell.portal.com 17: sameer(a)soda.berkeley.edu 18: remail(a)tamsun.tamu.edu 19: remail(a)tamaix.tamu.edu 20: remailer(a)utter.dis.org 21: remailer(a)entropy.linet.org 22: elee9sf(a)menudo.uh.edu 23: remail(a)extropia.wimsey.com NOTES: 1-7 no encryption of remailing requests 8-22 support encrypted remailing requests 23 special - header and message must be encrypted together 13,20,21,23 introduce larger than average delay (not direct connect) 13,20,23 running on privately owned machines 14 requires "cash" payment for remailing 22 supports RIPEM encryption, caches remailing requests ====================================================================== Q2: What help is available? A2: Check out the pub/cypherpunks/remailer directory at soda.berkeley.edu (128.32.149.19). chain.zip - program that helps with using remailers dosbat.zip - MSDOS batch files that help with using remailers hal's.instructions.gz - in depth instruction on how to use hal's.remailer.gz - remailer code pubkeys.tar.gz - public keys of remailers which support encryption pubkeys.zip - MSDOS zip file of public keys scripts.tar.gz - scripts that help with using remailers For MAC's, at 129.82.156.104 in /pub/pgpc/ are two files: pgpc22.tar.gz, pgpc22.tar.Z which assist in using the anonymous remailers, including anon.penet.fi. Mail to me (klbarrus(a)owlnet.rice.edu) for further help and/or questions. ====================================================================== Q3. Email-to-Usenet gateways? A3. 1: group-name(a)cs.utexas.edu 2: group.name.usenet(a)decwrl.dec.com 3: group.name(a)news.demon.co.uk 4: group.name(a)news.cs.indiana.edu 5: group-name(a)pws.bull.com 6: group-name(a)ucbvax.berkeley.edu NOTES: * This does not include ones that work for single groups, like twwells.com. #6 blocks from non-berkeley sites (so use the berkeley remailers :-) -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLNSsq4OA7OpLWtYzAQGG+wP/QIdQsJxTVtZ30WYvueGyhiMO8rBA5kS8 Pf7ZRHNqq5vXTQ6j1z+g3De6m+IL0gf3Zs2cWYrGiMkpw1AOvOwiPLFPwaMsKtqi GCikwzrvf2vNSwOjZ6S+fzo37BXqFibNbWX7v+UrwZAC8zeSAaLWMm3EiUZUjI1/ HXrZU/PgjAM= =i9Y6 -----END PGP SIGNATURE-----

1 0

Increasing subscriber base (fwd)
by szabo＠netcom.com 17 Dec '03

17 Dec '03

Cypherpunks, Enclosed below is a call for help. imp-interest deals with Internet commercial protocols, with special interest in secure billing. The future of cypherpunks' goals, most obviously digital cash but also much of the rest of our varied agenda, ranging from privacy to freedom on the net, is deeply tied in with what direction the emerging world of Internet commerce chooses to pursue. Will these businesses move us towards a world of freedom and privacy on the net, or a world in which our credit card numbers and IDs will be tracked to "ensure accountability", and our every purchase and data access on the commercial Net tied to our True Names to build lucrative marketing databases and fodder for future snoops? Contrariwise, what insights can those pursuing the everyday practicum of net.business contribute to the cypherpunks vision? It would be a tremendous advance, I daresay more important than stopping Clipper (important as that task is), to get Internet commerce on board with the commercial privacy-enhancing protocols of Chaum et. al. -- digital cash, DC-nets, per-organization pseudonyms with transferable credentials, etc. And contrariwise, to invigorate those protocols with doses of practical, real-world business considerations. Those of us with an interest in promoting free and private Internet commerce, and motivation to pursue this, I urge you to get deeply involved in the "imp" movement. Nick Szabo szabo(a)netcom.com Forwarded message: Date: Sun, 31 Oct 93 22:00:54 PST From: ptrubey(a)shl.com (Phil Trubey) Message-Id: <9311010600.AA25672(a)technet1.shl.com> Subject: Increasing subscriber base No offence meant to anyone subscribed to this mailing list, but this mailing list does not seem to have enough of a critcal mass of interested people to ensure a good level of dicussion and the ability for collaborative work. I am suggesting that we advertise the existence of this list to a selected few other mailing lists and newsgroups to increase awareness and participation. If there are no violent objections I can send out a short note to cypherpunks, com-priv, the Internet List of Lists. .... Phil Trubey | Internet: ptrubey(a)shl.com Systemhouse Inc. | Voice: 310-809-5491 | Fax: 310-860-9668

1 0

RE: Nazis/Privacy/Cypherpunks
by James Still 17 Dec '03

17 Dec '03

>Personally, I don't rule out examination of Nazi tactics as a >worst case scenario model. Let's face it, as ugly and dark as >Nazi rule was, they did some things quite efficiently indeed. > > [...] > >To rule out Nazi approaches, especially when dealing with >intelligence and counter-intelligence issues (which IMHO is >basically what cypherpunks is all about on some level or >another...) is plain silly. Current intelligence practices are If I understand your basic point to be: "consider the worst possible scenario in order to better prepare for it" then I agree completely. However I have serious reservations with emulating or (gadzooks!) *admiring* those Nazi tactics that seemed to "work" because I would disagree that, first they actually did work, and more importantly, that their ends justified the means. Which brings me to your second point: >[Note 2] >No one writes code from "the bottom up" in the manner that you >suggest. If that were the case we'd see the wheel invented time >and time again. One of the reasons this mailing list exists is to >accomplish exactly the opposite. That being to incorporate common >or even fringe ideas into the development of code for the common >purpose (The Prize as you adeptly put it.) so we don't HAVE to >build from the ground up every time. I disagree. (Semantics check: I'm not talking about a mouse driver or a basic windowing interface here. Obviously, there's no need to hammer out that wheel again.) I am talking about what I see as a basic cypherpunk mission, that being, "the constant reevaluation of the approach towards privacy." We have the ability to constantly rip apart our own ideas, like children's ABC blocks, and see if they fit back together again in a better way. I would prefer to see constant rewrite's of a "given" (like PGP for instance) than to stagnate and rely on the one idea, concept, or proof just because we've always done it that way. Our code should be like our ethics: constantly re- evaluated, questioned, and tested for validity. --- still(a)kailua.colorado.edu --------------------------------

2 1