December 2003 - cypherpunks-legacy

(fwd) Re: BSD random() - any good (source included)?
by Jim choate 17 Dec '03

17 Dec '03

Newsgroups: sci.math,sci.stat.math Path: bga.com!news.sprintlink.net!hookup!ames!lll-winken.llnl.gov!overload.lbl.gov!dog.ee.lbl.gov!ihnp4.ucsd.edu!usc!howland.reston.ans.net!europa.eng.gtefsd.com!MathWorks.Com!news.kei.com!ssd.intel.com!carr From: carr(a)ssd.intel.com (George Carr) Subject: Re: BSD random() - any good (source included)? Message-ID: <Cs4B6w.IqE(a)SSD.intel.com> Sender: usenet(a)SSD.intel.com Nntp-Posting-Host: shiva Organization: Supercomputer Systems Divison, Intel Corp. References: <deleydCs1L9A.2L6(a)netcom.com> <iFwLoc3w165w(a)hakatac.almanac.bc.ca> Distribution: na Date: Tue, 28 Jun 1994 17:28:08 GMT Lines: 34 Xref: bga.com sci.math:14998 sci.stat.math:1241 In article <iFwLoc3w165w(a)hakatac.almanac.bc.ca>, rbursey(a)hakatac.almanac.bc.ca (robert bursey) writes: |> deleyd(a)netcom.com writes: |> |> > I did a research paper on Computer Generated Random Number Sequences in |> > 1991. Included are the results of testing numerous popular generators. |> > The code used for testing the generators is also available if one |> > is so inclined to do some testing of a particular generator. (The only |> > thing is a thorough test to determine the limits of the generator can |> > take many hours of CPU time). |> > |> > Perhaps later this week I'll post the paper and see what the response |> > is. I'm always a bit apprehensive to post. Never sure what the |> > response will be. Maybe someone will think it's interesting. |> > |> > David Deley |> > deleyd(a)netcom.com |> |> Does anybody know of a good test for randomness? I would definitely like to |> know how good computer RNG's are. Post away! The classic reference is Volume 2 of Donald Knuth's The Art of Computer Programming, Second Edition, Seminumerical Algorithms. I highly recommend it to anyone wanting to know what "random" is all about. If you really need to know whether your generator is random-enough for your application you should expect to do your own testing and yes it will require many hours of your time in addition to that of your computer. -- George R. Carr, Jr. Intel Supercomputer Systems Division Parallel Systems Engineer NOAA Forecast Systems Laboratory carr(a)ssd.intel.com Research Lab 3, Rm A227 carr(a)neko.fsl.noaa.gov 3100 Marine St, R/E/FS5 voice: 303-497-6130 Boulder, CO 80303 fax: 303-497-6821

1 0

(fwd) Re: BSD random() - any good (source included)?
by Jim choate 17 Dec '03

17 Dec '03

Path: bga.com!news.sprintlink.net!hookup!ames!lll-winken.llnl.gov!noc.near.net!pad-thai.aktis.com!la-jiao.aktis.com!not-for-mail From: don(a)cam.ov.com (Donald T. Davis) Newsgroups: sci.math,sci.stat.math Subject: Re: BSD random() - any good (source included)? Date: 28 Jun 1994 17:52:48 -0400 Organization: OpenVision Technologies, Inc. Lines: 65 Distribution: na Message-ID: <2uq63g$g5c(a)la-jiao.aktis.com> References: <deleydCs1L9A.2L6(a)netcom.com> <iFwLoc3w165w(a)hakatac.almanac.bc.ca> <Cs4B6w.IqE(a)SSD.intel.com> NNTP-Posting-Host: la-jiao.aktis.com Xref: bga.com sci.math:15008 sci.stat.math:1243 (George Carr) writes: >(robert bursey) writes: >|> deleyd(a)netcom.com writes: >|> >|> > I did a research paper on Computer Generated Random Number Sequences in >|> > 1991. Included are the results of testing numerous popular generators. >|> > The code used for testing the generators is also available if one >|> > is so inclined to do some testing of a particular generator. (The only >|> > thing is a thorough test to determine the limits of the generator can >|> > take many hours of CPU time). >|> > >|> > Perhaps later this week I'll post the paper and see what the response >|> > is. I'm always a bit apprehensive to post. Never sure what the >|> > response will be. Maybe someone will think it's interesting. >|> > >|> > David Deley >|> > deleyd(a)netcom.com >|> >|> Does anybody know of a good test for randomness? I would definitely like to >|> know how good computer RNG's are. Post away! > >The classic reference is Volume 2 of Donald Knuth's The Art of Computer >Programming, Second Edition, Seminumerical Algorithms. I highly recommend >it to anyone wanting to know what "random" is all about. > >If you really need to know whether your generator is random-enough for >your application you should expect to do your own testing and yes it will >require many hours of your time in addition to that of your computer. >-- knuth's chapter's practical results are about linear-congruential rngs, their optimization and testing. though these rngs are still distressingly common, nonlinear rngs are the way to go for two burgeoning areas that consume random numbers: graphics and cryptography. both areas are concerned with getting extremely long periods, but cryptography is also concerned with proving unpredictability of secure rngs. that is, knowing some outputs of an rng as applied to a given seed, it should be impossible to deduce or predict other outputs' values. so, you see, the "good test for randomness" depends strongly on which features of a random variable you want to use. if you're careful, knuth's approach will work fine for some statistical applications, like monte-carlo techniques. but knuth's is by no means the last word on the subject. btw, for cryptographic purposes, the received wisdom is that there is NO adequate test for randomness; if an rng passes lots of tests, that's very nice, but the presumption is that the variable's deterministic structure is simply hidden, and that the clever-enough test was not yet applied or devised. nevertheless, in the cryptographic field, the list of tests used is long. typically, you design the test to probe the weaknesses of a specific rng algorithm. period tests, runs tests, and substring-interarrival tests are common, and some people like entropy estimates. one of the trusted names in the crypto-rng literature is marsaglia; he has published extensively on the subject of rng-testing. i don't know what the graphics literature on rngs is like; i only know that if you want to simulate textured surfaces, like grass, a bad rng makes a striped texture. be forwarned: the rng literature is amazingly vast, with a low signal- to-noise ratio. it seems that everyone thinks he can design a "good" rng. btw, i favor hardware rngs. -don davis openvision technologies cambridge, ma

1 0

Re: (fwd) Re: BSD random() - any good (source included)?
by jamiel＠sybase.com 17 Dec '03

17 Dec '03

At 3:20 PM 07/07/94 -0500, Jim choate wrote 69K of forwards (so far) that I would much rather look at in sci.math or sci.stat.math than in my mailbox, unrequested. Didn't we have a little forwarding talk recently enough for your avarage televangelist viewer to remember it? Kindly cut it out. -j -- "Blah Blah Blah" ___________________________________________________________________ Jamie Lawrence <jamiel(a)sybase.com>

2 1

real live Detweiler messages- anyone?
by jamiel＠sybase.com 17 Dec '03

17 Dec '03

I have a writing assignment coming up (nothing to do with much that is talked about on this list), and some example posts by Detweiler could be really handy as references. I have one from a long time ago, but could use some others- anybody save any for posterity? If so, could you forward me a couple of juicy ones? thanks- -j -- "Blah Blah Blah" ___________________________________________________________________ Jamie Lawrence <jamiel(a)sybase.com>

1 0

cypherpunks mbone this sat.
by Katy Kislitzin 17 Dec '03

17 Dec '03

The monthly meeting of cypherpunks will be broadcast on the mbone this saturday, july 9, from noon to 6. The ports and ID's are as follows: audio: 64264 51421 video: 43185 51863 This is being advertised using sd as well. The main topic will be discussion of Phil Karn's swIPe package, which was announced at Usenix last month. It allows one to set up encrypted IP tunnels over the exisiting IP network. For those of you interested in attending in person, the meeting will be held at Silicon Graphics in Cafe Iris, building 5. To get there, get off 101 at Shorline, and head towards the ampetheater. Turn right into the SGI parking lot after Charlston, and continue down to just before the circle. Building 5 will be on your right. NOTE: THE SGI PARKING LOTS ARE BEING RE-SURFACED THIS WEEKEND. SO YOU WILL HAVE TO PARK ON THE MAIN CAMPUS DRIVE OR ON THE CONCRETE PARKING AREAS. --kt Katy Kislitzin Silicon Graphics I/S Network Software ktk(a)corp.sgi.com

2 1

Re: (fwd) Re: BSD random() - any good (source included)?
by gtoal＠an-teallach.com 17 Dec '03

17 Dec '03

From: Jim choate <ravage(a)bga.com> Subject: (fwd) Re: BSD random() - any good (source included)? Jeezus fucking christ, you're just doing this to wind me up, aren't you? Any more of these turn up in my mailbox and they get bounced straight back to you. I have to pay by the minute for this connection. Keep it up and you'll pay too, believe me. G

2 1

(fwd) Re: BSD random() - any good (source included)
by an65＠vox.hacktic.nl 17 Dec '03

17 Dec '03

> At 3:20 PM 07/07/94 -0500, Jim choate wrote 69K of forwards > (so far) that I would much rather look at in sci.math or > sci.stat.math than in my mailbox, unrequested. Didn't we have > a little forwarding talk recently enough for your avarage > televangelist viewer to remember it? > Kindly cut it out. I guess cypherpunks would rather not write or even read code, but simply gossip about usenet kooks and pedophiles. > ___________________________________________________________________ > Jamie Lawrence <jamiel(a)sybase.com> > c@lib@n -------------------------------------------------------------------------- To find out more about the anon service, send mail to help(a)vox.hacktic.nl Please report any problems, inappropriate use etc. to admin(a)vox.hacktic.nl Direct replies to the sender of this message are -not- anonymised..<YuK>..

9 15

(fwd) New ITAR Indictment
by Anonymous User 17 Dec '03

17 Dec '03

Are you serious? (fwd) From: chuckles(a)MCS.COM (Jason Skiles) Newsgroups: alt.security.pgp,comp.org.eff.talk,comp.org.cpsr.talk Subject: New ITAR Indictment Date: 8 Jul 1994 01:02:56 -0500 Reprinted with permission from the Chicago Sun-Tribune, 5 July 1994: >From Sun-Tribune Wires Washington, D.C.- In a Rose Garden press conference early this morning, Justice Department spokesmen announced the indictment of a Washington, DC. computer bulletin board system (BBS) operator, one Mr. Gil Bates, for violation of ITAR munitions export laws in connection with the operation of the infamous 'We got yer nudes here' BBS. According to federal authorities, many of the graphics files, or 'gif' files, named for their storage format, contained, when examined with a common hex editor, the value 0xAAAA, which can be used to encrypt data in such a way as to make it extremely difficult for intelligence and law enforcement agencies to recover the encrypted data. "0xAAAA first came to our attention a few weeks ago," explained Deputncrypted] file, by using a complicated algorithm known as 'exclusive or' and a 'mask' or encryption key, of, for example, "0xAAAA." Agents were stunned. "It's an entirely new and sinister turn of events in the field," said Miller. "We'd be helpless against such an attack." Miller went on to explain just how secure such a scheme would be. "When we need to crack some encrypted data, for example, email someone sends to his lawyer that we think may contain incriminating evidence," we usually just hand it to thenstitutional issues involved there, but we're working on it." He refused to elaborate. Once the technique was known, news spread quickly throughout the law-enforcement community. "This was a shot across the bow, a real wake-up call for us," said one Justice Department source. "We moved immediately, meeting with the vice-president and a professor from Georgetown. They were reluctant at first, but we mentioned organized crime and terrorists and they came around to our point of view." But why forbid the 'mask' or 'key' instead of the algorithm itself, the 'exclusive-or' technique? "That's sort of a funny story," explained Miller. "We were going to at first, but it turns out that the Clipper and Capstone chips [part of a government-designed key escrow system] make use of the algorithm in places. Of course, there were a few 0xAAAA's too, but the NSA assures us they've got a workaround." Bates loudly proclaims his innocence. "This is stupid, really stupid. It's just a 16-bit value, like any other. They can't restrict it. I'm... I'm at a loss. This is just too stupid to comment on." The case got weaker late this afternoon when it was revealed that the file in question didn't actually leave the country, but was retrieved by an FBI agent in Virginia. "Obviously this compromises our case somewhat," admitted Miller, "since Virginia isn't a foreign country. But someone in another country could have done the same thing, easily. That should count for something." Schneider noted that "Even though we'll probably have to drop the ITAR case, we did come up with something. He had a copy of PGP [a 'guerilla freeware' encryption package popular with subversives and criminals] and some files he'd protected with it." "We think they were maybe lists of children he an FBI agent in Virginia. "Obviously this compromises our case somewhat," admitted Miller, "since Virginia isn't a foreign country. But someone in another country could have done the same thing, easily. That should count for something." Schneider noted that "Even though we'll probably have to drop the ITAR case, we did come up with something. He had a copy of PGP [a 'guerilla freeware' encryption package popular with subversives and criminals] and some files he'd protected with it." "We think they were maybe lists of children he abused, or something," says Schneider. "Yeah, or something," added Miller. [Pre-flame apologies go out to those who object to the inclusion of 'serious' groups in the newsgroups list. If you know any silly ones where this would be more welcome, feel free to send it along.] ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ | Jason "Chuckles" Skiles | <Insert a clever quotation here.> | | chuckles(a)mcs.com | - <misattribute it here> | ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ | Any opinions I express are also those of every single school, company, | | and organization I've ever been in any way associated with. Honest. | ++++++++++++++++++++++++++finger for PGP public key+++++++++++++++++++++++++ ------------ To respond to the sender of this message, send mail to remailer(a)soda.berkeley.edu, starting your message with the following 8 lines: :: Response-Key: ideaclipper ====Encrypted-Sender-Begin==== MI@```%ES^P;+]AB?X9TW6\8WR:2P&2%`$A:^X<=%.A'J%;"Y7E2J[QT=&)]L M0`F:L=MI*O?R!?N6/E3TTZ6WF^B=ZP9][Y)B)J)4PF/%M3XOVYT^Y;!E*9Y9 $\U3XF@`` ====Encrypted-Sender-End====

1 0

Re: (fwd) Re: BSD random() - any good (source included)
by jamiel＠sybase.com 17 Dec '03

17 Dec '03

At 1:11 AM 07/08/94 +0200, Nobody wrote: >I guess cypherpunks would rather not write or even read code, but >simply gossip about usenet kooks and pedophiles. Nobody either - Is baiting for fun or - Actually thinks mailbombing 700+ people with easily accessible information on a subject tangental to this list is a Good Idea, and - doesn't have the slightest clue what proper conduct in a public forum is. For Nobody's sake, I hope it is the former. But if it happens to be the latter- Nobody, write me with an address I can reach you at and I'll send you lots and lots of code for you to read, every day, if you choose. That will help your productivity *immensely*. >c@lib@n -j -- "Blah Blah Blah" ___________________________________________________________________ Jamie Lawrence <jamiel(a)sybase.com>

1 0

cypherpunks mbone this sa
by Duncan Frissell 17 Dec '03

17 Dec '03

To: cypherpunks(a)toad.com K>The monthly meeting of cypherpunks will be broadcast on the mbone this K>saturday, july 9, from noon to 6. The ports and ID's are as follows: K> K>audio: 64264 51421 K>video: 43185 51863 K> K>This is being advertised using sd as well. Anyone in the New York area with a workstation? I'd love to listen (or watch). I'd bring beer! DCF --- WinQwk 2.0b#1165

2 1

Question: Key Distr. in realtimeo applications?
by Jonathan Rochkind 17 Dec '03

17 Dec '03

Well, I've gotten a few hundred pages into Applied Crypoto, and am now educated enough to realize what the things are that I don't know. One question I have is regarding how protocols for realtime communications work, like say a encrypted voice conversation. I know there are such things,such as Clipper, but I assume Clipper/skipjack is atypical in many ways. But maybe I'm wrong. Anyhow, I'd guess that in such applications, a random one-time session key is generated for a symmetric encryption method. Is this correct? If so, how is this key distributed to both participants? You could use public-key cryptography in some way to distribute the session key, similar to what DES does, but then how do you distribute the public keys so as to avoid a man in the middle attack? Ideally, you want to pick up your crypto-phone, initiate a call to another crypto-phone which you've never called before, and which was possibly manufactured yesterday, and be able to exchange keys with it in a secure fashion. But I can't think of any way to do this, without opening yourself up to a man in the middle attack. How does clipper solve this problem? How do other potential realtime protocols? Or do they just ignore it, and assume that it's going to be too hard to do a succesful man-in-the-middle attack quickly enough for a realtime conversation? That would seem to me to be a dangerous assumption. I'd appreciate it if anyone could help me out.

4 3

The Dining Cryptographers Protocol
by tcmay＠netcom.com 17 Dec '03

17 Dec '03

Cort mentioned the Dining Cryptographers, and since many of you have joined the list since I last posted this, I thought I'd post it again. This article is an informal introduction, written originally for the Extropians list. The full version of David Chaum's paper on the Dining Cryptographers is at the ftp.csua.berkeley.edu site in pub/cypherpunks. --Tim May >From: tcmay(a)netcom.com (Timothy C. May) >Subject: The Dining Cryptographers Protocol >To: cypherpunks(a)toad.com >Date: Mon, 16 Nov 92 1:10:10 PST >Cc: tcmay(a)netcom.com (Timothy C. May) >X-Mailer: ELM [version 2.3 PL11] >Status: OR > >Fellow Dining Cryptographers (and Cypherpunks), > >Hal Finney has been suggesting I forward to this list some articles I >wrote for another list of like-minded folks, the "Extropians" list. We >had some fascinating discussions of digital money, DC-nets, digital >pseudonyms (a la Vernor Vinge's "True Names," as Hal has noted), etc. >Basically the stuff I put in my .signature, and so on. > >These topics are, in my opinion, at the core of what we are doing on >this list. It is highly gratifying to see the pieces falling into >place. And at our crypto session at the Hackers Conference, it became >clear to many people just how close we are. > >So since Hal just forwarded me one of my old postings, how can I >resist? (I still _have_ my old posts, but no longer on my NETCOM >system, so reposting them takes a bit of effort. So I'll just forward >to you the posting Hal just forwarded to me!) > >Hal Finney writes: > >I was looking through some old Extropians messages and found this >one which you wrote about DC nets. I don't know if you archive your >old messages, but I thought this had some good stuff, especially at the >end where you talk about the applications of crypto anonymity. You >would probably want to change the use of Extropians to Cypherpunks or >some such, if you wanted to re-post it there. > >Hal > > >Return-Path: <uunet!gnu.ai.mit.edu!extropians-request> >To: Extropians(a)gnu.ai.mit.edu >From: uunet!netcom.com!tcmay (Timothy C. May) >Subject: Dining Cryptographers >X-Original-To: Extropians(a)gnu.ai.mit.edu >Date: Tue, 18 Aug 92 15:45:34 PDT >X-Extropian-Date: Remailed on August 18, 372 P.N.O. [22:46:47 UTC] >Reply-To: uunet!gnu.ai.mit.edu!Extropians > >Marc R. has opened the door for me to get into some really exciting >stuff: >> >> Tim May mentioned a new method from Chaum for defeating traffic analysis: >> >> > Chaum has since improved the tamper-responding "mix" by going to a pure >> > software scheme which he calls "the Dining Cryptographers Protocol." It's >> > described in Vol. 1, Number 1 of "Journal of Cryptology," 1988. If there's >> > interest, I'll summarize it. >> >> Yes, please, Tim! >> >> >> M. > >Complexity Warning: This stuff (I'm being informal) is easy once you >get the basic idea. But getting the basic idea usually involves reading >several articles on what RSA, digital signatures, etc., are all about, >working out some examples, thinking about it, drawing pictures with >other folks, and finally having an "Aha!" experience (in Werner Erhard's >terms, you "get it"). The ASCII nature of the Net is not conducive to learning >this stuff, despite the excellent summaries of crypto by Marc R. and Perry M. > >The almost-latest "Scientific American," August, has an article by David Chaum >on digital money, and the latest "Spectrum," available at selected newstands, >has several articles on security and cryptography. Also, there are lots of >books. Look 'em up in a university library or flip through them at a large >technical bookstore and pick the one you like the most. (I like a slim >Springer-Verlag paperback, "Modern Cryptology," by Gilles Brassard, 1988, as >a good intro to "modern"--as opposed to "classical"--crypto.) > >If the stuff in this posting, and on crypto in general, is beyond your >current understanding, either ignore it, skim it and try to get the gist, >or dig into the articles and books. > >Anyway, back to "The Dining Cryptographers Problem: Unconditional Sender and >Recipient Untraceability," David Chaum, Journal of Cryptology, I, 1, 1988. >Since this journal is hard to get, I'll discuss the article in some detail. >(The techniques have major implications for anarchocapitalism and for >Extropian ideas.) > >Abstract: "Keeping confidential who sends which messages, in a world where any >physical transmission can be traced to its origin, seems impossible. >The solution presented here is unconditionally or cryptographically secure, >depending on whether it is based on one-time-use keys or on public keys. >respectively. It can be adapted to address efficiently a wide variety of >practical considerations." > >A word on terminology: "Unconditionally secure" means what it says: no >computer will ever crack it. One-time pads are unconditionally secure...no >code or cipher is involved, except the one-time pad, so the message is >secure as long as the pad has not been compromised. "Cryptographically >secure" means secure so long as various crypto ciphers are secure, which >may be for a very, very long time (e.g., with very large primes, in RSA). > >Chaum describes some "dining cryptographers," which I will playfully change >to "dining Extropians." (The term is of course a variant of the seminal >"dining logicians problem" in computer science) > >Three Extropians are having dinner, perhaps in New York City. Their waiter >tells them that their bill has already been paid, either by the NSA >or by one of them. The waiter won't say more. > >The Extropians wish to know whether one of them paid, or the NSA paid. But >they don't want to be impolite and force the Extropina payer to 'fess up, >so they carry out this protocol (or procedure): > >Each Extropian flips a fair coin behind a menu placed upright between himself >and the Extropian on his right. The coin is visible to himself AND to the >Extropian on his left. Each Extropian can see his own coin and the coin to his >right. > >STOP RIGHT HERE! Please take the time to make a sketch of the situation I've >described. If you lost it here, all that follows will be a blur. I'm sparing >you folks my attempt at an ASCII drawing! > >Each Extropians then states out loud whether the two coins he can see are the >SAME or are DIFFERENT, e.g., "Heads-Tails" means DIFFERENT, and so forth. For >now, assume the Extropians are truthful. > >A little bit of thinking shows that the total number of "DIFFERENCES" must >be either 0 (the coins all came up the same), or 2. Odd parity is impossible. > >Now the Extropians agree that if one of them paid, he or she will SAY THE >OPPOSITE of what they actually see. Remember, they don't announce what their >coin turned up as, only whether it was the same or different as their neighbor. > >Suppose none of them paid, i.e., the NSA paid. Then they all report the truth >and the parity is even (either 0 or 2 differences). They then know the NSA >paid. > >Suppose one of them paid the bill. He reports the opposite of what he actually >sees, and the parity is suddenly odd. That is, there is 1 difference reported. >The Extropians now know that one of them paid. But can they determine which >one? > >Suppose you are one of the Extropians and you know you didn't pay. One of the >other two did. You either reported SAME or DIFFERENT, based on what your >neighbor to the right (whose coin you can see) had. But you can't tell which >of the other two is lying! (You can see you right-hand neighbor's coin, but >you can't see the coin he sees to his right!) > >This all generalizes to any number of people. If none of them paid, the parity >is even. If one of them paid, the parity is odd. But which one of them paid >cannot be deduced. And it should be clear that each round can transmit a bit, >e.g., "I paid" is a "1". The message "Attack at dawn" could thus be "sent" >untraceably with multiple rounds of the protocol. > >The Crypto Ouija Board: I explain this to people as a kind of ouija board. >A message, like "I paid" or a more interesting "Transfer funds from.....," >just "emerges" out of the group, with no means of knowing where it came >from. Truly astounding. > >Now there are many interesting wrinkles and elaborations to this protocol. I'll >note just a few. > >1. Collusion. Obviously the Extropians can collude to deduce the payer. >This is best dealt with by creating multiple subcircuits (groups doing the >protocol amongst themselves). Lots more stuff here. Chaum devotes most of the >paper to these kind of issues and their solutions. > >2. With each round of this protocol, a single bit is transmitted. Sending >a long message means many coin flips. Instead of coins and menus, the >neighbors would exchange lists of random numbers (with the right partners, >as per the protocol above, of course. Details are easy to figure out.) > >3. Since the lists are essentially one-time pads, the protocol is >unconditionally secure, i.e., no assumptions are made about the difficulty >of factoring large numbers or any other crypto assumptions. > >4. Participants in such a "DC-Net" (and here we are coming to the heart >of the "crypto anarchy" I have mentioned several times, and which is >perhaps foolishly advertised in my .sig) could exchange CD-ROMs or DATs, >giving them enough "coin flips" for zillions of messages, all untraceable! >The logistics are not simple, but one can imagine personal devices, like >smart card or Apple "Newtons," that can handle these protocols (early >applications may be for untraceable brainstorming comments, secure >voting in corportate settings, etc.) > >5. The lists of random numbers (coin flips) can be generated with standard >cryptographic methods, requiring only a key to be exchanged between the >appropriate participants. This eliminates the need for the one-time pad, >but means the method is now only cryptographically secure, which is >often sufficient. (Don't think "only cryptographically secure" means >insecure....the messages may remain encrypted for the next billion years) > >6. Collisions occur when multiple messages are sent at the same time. Various >schemes can be devised to handle this, like backing off when you detect >another sender (when even parity is seen instead of odd parity). In large >systems this is likely to be a problem. Solutions are left as an exercise. > >7. Noise. Some participants may try to flood the circuit with spurious >messages, to defeat the system or for whatever other reasons. This is >still an issue. (If there's anything to take away from crypto, it's that >nothing is as simple as it looks, that there are always devious ways to >spoof, jam, and forge. I expect you've seen this from some of the debate >on digital voting schemes.) > >What Can "DC-Net" Be Used For?: > >* Untraceable mail. Useful for avoiding censorship, for avoiding lawsuits, >and for all kinds of crypto anarchy things. > >* Fully anonymous bulletin boards, with no traceability of postings or >responses. Illegal materials can be offered for sale (my 1987 canonical >example, which freaked out a few people: "Stealth bomber blueprints for >sale. Post highest offer and include public key."). Think for a few minutes >about this and you'll see the profound implications. > >* Decentralized nexus of activity. Since messages "emerge" (a la the ouija >board metaphor), there is no central posting area. Nothing for the government >to shut down, complete deniability by the participants. > >* Only you know who your a partners are....in any given circuit. And you can >be in as many circuits as you wish. (Payments can be made to others, >to create a profit motive. I won't deal with this issue, or with the issue >of how reputations are handled, in this posting.) > >* The tamper-responding "digital mixes" can still be useful, and may supplement >this purely software-based approach. > >* Digital money gets involved, too, both for payments in this system, and in >terms of "alternative currencies." I'm not an economist, so I'll leave this >for others to go into in more detail. > >Enough for now. Chaum's work is just the start. These systems can initially be >set up for "innocuous" purposes like research into crypto techniques (not yet >banned in the U.S.), role-playing games, religions, and the like. Once >they get going, it'll be too late to stop the other things. > >Hope you liked this summary. Please read the articles...there's just no way >my posting can do justice to them (though I admit I've concentrated my efforts >on the political aspects, which "respectable" crypto researchers rarely >mention, so perhaps the flavor here is a bit more Extropian than you'll >find elsewhere.) > >--Tim (part of the "Too Many Tims!" Conspiracy) > >-- >.......................................................................... >Timothy C. May | Crypto Anarchy: encryption, digital money, >tcmay(a)netcom.com | anonymous networks, digital pseudonyms, zero >408-688-5409 | knowledge, reputations, information markets, >W.A.S.T.E.: Aptos, CA | black markets, collapse of governments. >Higher Power: 2^756839 | PGP Public Key: awaiting Macintosh version. > > .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)netcom.com | anonymous networks, digital pseudonyms, zero 408-688-5409 | knowledge, reputations, information markets, W.A.S.T.E.: Aptos, CA | black markets, collapse of governments. Higher Power: 2^859433 | Public Key: PGP and MailSafe available. "National borders are just speed bumps on the information superhighway."

1 0

RE: PGP Keys on a Floppy
by nobody＠kaiwan.com 17 Dec '03

17 Dec '03

frissell(a)panix.com "Duncan Frissell" wrote >> C.><< some suggestion to keep keys secure on floppy>> >> DOS users can always encrypt their keyfile on a floppy encrypted with >> SecureDrive. <G> Someone suggested keeping both the keyring as well as the PGP.EXE itself on a WRITE PROTECTED floppy. Doesn't RANSEED.BIN need to be in the same directory, and doesn't it need to be WRITEABLE? -

1 0

AA BBS case/update
by hkhenson＠cup.portal.com 17 Dec '03

17 Dec '03

[I wrote this for CuD, but decided the issue is urgent enough to post it other places before the next issue comes out. Apologies to Jim T.] ************* Re File 9 of the 5 July issue of CuD,--Some thoughts on the AA BBS, the Advocate writes: >Stuff about the AA BBS case. This case is essentially a war of ideas. >Can a backwards, pigheaded state like Tennessee set the moral and >cultural standard of a sophisticated state like California? So far they are making a serious attempt. >I say not, and like minded individuals agree with us. I would guess that 90+ percent of the people on the net agree, but they don't control the federal legal and police forces. >These "Reagan-Jungians" need to be beaten back. The best light is that >of the First Amendment. Bring the press in, point out the vital issues. While the press has been somewhat supportive, they don't get the connection between *their* presses and what an adult BBS provides. They don't understand the need to defend on the margins *before* you get your heart ripped out. ("First they came for the Pornographers . . .) >The judge will be embarrassed if the AP or Court TV is televising >what this action is about. Federal courts don't admit TV. The original bust with its obvious frame up of the sysop was reported on local (Bay area) TV. None of those involved seem to be embarrassed in the slightest. (Though Judge Brazil did remove himself from the case after being accused of serious breaches of conduct.) As a follow on what I posted mid January, it turns out that possessing kiddy porn is not a crime in the 9th district. The Excitement Video case in California ruled the law unconstitutional on appeal. Newsom (the TN prosecutor) specializes in porn and must have been up on this landmark case. The case was local to California, so the local prosecutors would have known about it as well. It has always been a mystery as to why postal inspector Dirmeyer did not have warrant for the kiddy porn he mailed to the sysop just before he came in. We now figure they left it off on purpose because even a corrupt judge who knew about the EV case would not issue a warrant for something he knew was legal! However, until the Supreme court rules on a case and unifies the law, possession of kiddy porn *is* a crime in the 6th district (where Tennessee is located). So, the sysop was indicted *there* after being framed for possession in California! Aside from the frame up, this raises the issue of: Can someone be charged with a crime in a different district of the country when what they did would not be a crime where it was done? The feds in Tennessee seem to think they can do it. (Ah, well. California has some odd notions of how far they can reach on things like sales and income taxes.) >Has anyone tried contacting the Playboy Foundation or the Guccione >Foundation. Contact people like Spider Robinson or William Gibson. >Publicity can only help. Yes Playboy Foundation, no Guccione. Playboy was marginally helpful. Does anyone have an address or number for any of those mentioned? >Especially given the candy ass tricks the prosecutors are trying out. Right you are! This is clearly political/religious persecution. (Does anyone know anything about the Conservative Caucus??) But what the hell can you do when the courts ignore their own rules and cater to the prosecutors? The court should dismiss this one on the speedy trial issue alone (40 days over the limit), but the judge has not ruled on several of the defendant's motions to dismiss, such as the NAFTA issue. The judge and prosecutor seem determined to break the defendant financially. For example, the last time Richard Williams (the AA BBS lawyer) went to Memphis for a hearing, neither the judge (Gibbons) nor the prosecutor (Newsom) assigned to the case showed up. All Richard could do was to turn around and come home with $2000 in plane fare and expenses down the drain. There is a hearing Friday, (July 8, 1994) at which the judge will ask Richard a single question--"are you ready for trial July 18" and to which he will answer "yes." This could be accomplished by telephone, but the judge said "show up or else." (Fortunately Richard was able to get a local lawyer to show up in his place and say "yes.") I very much doubt *they* will be ready for trial, since the judge has not ruled on the motions in anything approaching the time allowed by court rules. My bet based on watching this business since January is that the judge will stall till the trial starts, rule against all motions, and start a trial which will be overturned on appeal just to break the AA BBS sysop financially. There seems to be no rules against this vile misuse of judicial power--nor any forum in which you can complain. (Except the media--which is rather reluctant to support anyone whom the government has smeared with the "hot button" of child porn.) >Bring heat to Reno and Clinton. I haven't got a clue as to how to do this. I can't (and neither can anyone else who has tried) even reach Veronica Coleman, the local US Attorney, much less her boss Janet Reno. Actually, I feel for Clinton because there are likely people who *do* know how to hold his feet to the fire. My bet is that the NSA/CIA/FIB/XYZ knows (as someone put it on eff.talk) something Hillery does not. I am beginning to think that top politicians should fuck sheep and abuse children on live TV. Otherwise, those who know about their minor sins have an arm lock on them. J. Edgar Hoover abused the US Presidents this way for all of his long career. >If this case is to be tried, it should be in california. Judge Gibbons *did* rule on this one--denied. There wouldn't *be* a case in California. You can buy everything the AA BBS sysop was accused of selling within 10 blocks of the Federal Courthouse in San Francisco. >The Advocate. Keith Henson (who finds that the government disobeying the rules makes him itch!)

2 1

Detwiler's Crypto Mailing List
by sico＠hacktic.nl 17 Dec '03

17 Dec '03

Hello Graham, Thursday July 07 1994 15:07, Graham Toal wrote: GT> : From: Peterwheat(a)aol.com GT> : I found this by doing a keyword search (cryptography) in America GT> Online's : database of mailing lists. I thought it might be of interest GT> to the : cypherpunks mailing list: GT> Oh God :-( Either Detweiler has got himself an AOL account or all AOL GT> people are as clueless as they're reputed to be... Honestly, I wouldn't know. However, if you read FAQ's carefully as they are posted to (amongst others) news.answers, there are some which mention CRAM, an acronym used by Detweiler referring to a service he has for folks who don't wish to be bothered to handle anything except the content of their FAQ. In the blur with which those FAQ's end he always mentions his current email address, and lately that has been tmp(a)netcom.com. [rest deleted] CU, Sico (sico(a)hacktic.nl)

1 0

Re: Question: Key Distr. in realtimeo applications?
by kentborg＠world.std.com 17 Dec '03

17 Dec '03

There are two ways around the problem of a faked public key. 1) spread it widely enough that it is hard to fake the several lookups you might do before first using it (you gonna doctor every cypherpunk posting I see which includes a key? gotta have a good middle to not get caught sitting there) 2) have a single well known key sign a copy of the key you want to be accepted as legit--and if that is too busy a task for the very important single key holder, just sign a few keys (one for Oberlin, for example) and have *them* sign further keys (including a copy of their signed credentials). This signing of credentials can be extended indefinitely. (Apple uses this scheme with RSA coding in their forthcoming mail support for the Mac--or at least did, I have not played with the recent betas.) And these two approaches work together. If my keyring has dozens of keys from the same organization, all signed with the same organization key, it becomes very difficult to get me to accept a fake. (Assuming there is software support for easily doing this kind of checking, something I don't think is in PGP, etc.) Encryption of voice: same problems as other key authorization situations, but often easier. If I call my mother, I don't care what key she uses, I will recognize her voice, how she speaks, and what she appears to know--things that are not yet fakeable except by very good actors with lots of time to study their roles. One-time key, how to distribute to both participants: don't. Let each pick a random key and sent it to the other using the other's public key--no need to use the same key in both directions, in fact seems a bad idea. -kb, the Kent -- Kent Borg +1 (617) 776-6899 kentborg(a)world.std.com kentborg(a)aol.com Proud to claim 31:15 hours of TV viewing so far in 1994!

2 1

Fortune magazine
by P. J. Ponder 17 Dec '03

17 Dec '03

>From the July 11 _Fortune_ magazine, in an article about "25 cool companies": The battle over how to ensure the privacy and security of communication in cyberspace pits the spy masters at the National Security Agency, with thousands of people and a budget said to be in excess of $10 billion a year, against a small, privately held California company. Nearly everyone in Silicon Valley seems to be rooting for the little guy. RSA is a darling of libertarian hackers because it sells a way to keep digital exchanges indecipherable by unwanted eyes, including those of Big Brother. . . . Multiple authors, the RSA piece was by Alan Deutschman (deutschman(a)aol.com) Interesting blurb, two quotes from Jim@RSA. The article also covers Mosaic Communications, Enterprise Integration Technologies, McAfee Assoc., Cisco Systems, Infosafe, Scientific Computing Assoc., Security Dynamics, & others. On another subject, does RIPEM interoperate with PGP or other public key software? I have version 1.0.5 for DOS. Thanks for any replies. ponder(a)freenet.scri.fsu.edu

2 1

No Subject
by nobody＠rebma.rebma.mn.org 17 Dec '03

17 Dec '03

with all this talk about bank card transactions, you remind me that i did a software project for remote credit card verification a while back. my part was the interface to the auth network. anybody curious what's in those transaction messages?

2 1

Re: FW: Physical storage of key is the weakest link
by lcottrell＠popmail.ucsd.edu 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- chris.claborne(a)sandiegoca.ncr.com writes: ><< some suggestion to keep keys secure on floppy>> > ><<Lance Cottrel writes: >If your passphrase is good (128+ bits of entropy), then your private key is >as secure as the messages that you send. Although it need be broken only >once, I see no real danger of IDEA being compromised in the near future. >Given a good passphrase, I would suggest that you want multiple copies of >your key to prevent loss or accidental destruction. My passphrase is > 30 >characters. Fortunately Mac PGP remembers the key during any given session >so typing is kept down a bit. >>> > >If you are really paranoid, keeping your private keys super secure is a good >idea. If a bad guy were come and steal them all she needs to do find out >your passphrase (using all kinds of attacks.... camera over your desk....) >and bingo, they can read all past and future message traffic to you... There are two things to be paranoid about. One is that other people could get access to your information. The other is that you might loose access to your information and the ability to autheniticate yourself. My personal comfort level is currently: having a few coppies of the secret key which I keep physical control over, only using PGP on my personal computer, and protecting it with a very inconvinient passphrase. Should I also mention that I keep the key, PGP, and all my other crypto stuff on an encrypted partition? -----BEGIN PGP SIGNATURE----- Version: 2.6 iQCVAgUBLhz1+FVkk3dax7hlAQGNlgP9EYV7YWcLCeoNqGYJjZ46KcCglhB3zcpC mu/e1Jr26GPDyKNQySEvVuGNAKKQs0Ep9K1HIUmTt5jaalMh+SE4eeNwfuTV3RtT bsy32E0n7AwTMgOLNeA1jhkBFTxpCnT0lSTO/oKQecnukkkgtxlcl+7gzrs1yhn8 R+V4bZoukCc= =W255 -----END PGP SIGNATURE----- -------------------------------------------------- Lance Cottrell who does not speak for CASS/UCSD loki(a)nately.ucsd.edu PGP 2.3 key available by finger or server. "Love is a snowmobile racing across the tundra. Suddenly it flips over, pinning you underneath. At night the ice weasels come." --Nietzsche

1 0

ZiffWire article on PGP 2.6 (fwd)
by Michael Johnson 17 Dec '03

17 Dec '03

I asked Philip Zimmermann what he thought of the ZiffWire article on PGP, and this is what he said: ---------- Forwarded message ---------- Date: Thu, 7 Jul 1994 22:29:24 -0700 (MDT) From: Philip Zimmermann <prz(a)acm.org> To: Michael Johnson <mpj(a)csn.org> Subject: ZiffWire article on PGP 2.6 (fwd) Forwarded message: >From columbine!prz Thu Jul 7 20:58:25 1994 Date: Thu, 07 Jul 1994 20:55:20 -0700 (MDT) From: Philip Zimmermann <prz(a)acm.org> Subject: ZiffWire article on PGP 2.6 To: cypherpunks(a)toad.com (Cypherpunks) Cc: prz(a)pascal.acm.org Reply-To: Philip Zimmermann <prz(a)pascal.acm.org> Message-Id: <m0qM65x-0002vqC(a)maalox.ppgs.com> X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Transfer-Encoding: 7BIT Content-Length: 2943 I would like to correct a misleading assertion that appeared in an article dated 5 July, attributed to "PC Week via INDIVIDUAL, Inc" that came from ZiffWire. The apparent author of the article is Eamonn Sullivan. I think it was posted on the Cypherpunks mailing list. The article concerns Pretty Good Privacy, version 2.6, distributed by MIT. The misleading and damaging paragraphs follow: > MIT and RSA's distribution of PGP Version 2.6 is an attempt to short- >circuit PGP's popularity. After Sept. 1, 1994, PGP 2.6 will no longer work >with documents and keys generated and encrypted by older versions of PGP, >and it is licensed for use only in the United States. > > The release is already causing upheaval, since its public-key format is >different than in prior versions, and numerous public-key repositories will >have to be updated. > >[07-05-94 at 17:19 EDT, Copyright 1994, ZiffWire, File: c0705185.2zf] This assertion is erroneous and damaging to PGP's reputation. PGP 2.6 will always be able to read messages, signatures, and keys from older versions, even after September 1st. The older versions will not be able to read messages, signatures and keys produced by PGP 2.6 after September 1st. This is an entirely different situation. There is every reason for people to switch to PGP 2.6, because it will be able to handle both data formats, while the older versions will not. Until September, the new PGP will continue to produce the old format that can be read by older versions, but will start producing the new format after that date. This delay allows time for everyone to obtain the new version of PGP, so that they will not be affected by the change. Key servers will still be able to carry the keys made in the old format, because PGP 2.6 will still read them with no problems. The assertion made in the article has it backwards, which would indeed be bad if PGP were to start behaving that way. If it did, I wouldn't use it myself. I call upon ZiffWire and PC Week to issue a correction to this error. Also, note that any export restrictions on PGP 2.6 are imposed by the US government. This does not imply that MIT or myself agree with these restrictions. We just comply with them. We do not impose additional licensing restrictions of our own on the use of PGP outside of the US, other than those restrictions that already apply inside the US. PGP may be subject to export controls. Anyone wishing to export it should first consult the State Department's Office of Defense Trade Controls. I developed PGP 2.6 to be released by MIT, and I think this new arrangement is a breakthrough in the legal status of PGP, of benefit to all PGP users. I urge all PGP users to switch to PGP 2.6, and abandon earlier versions. The widespread replacement of the old versions with this new version of PGP fits in with future plans for the creation of a PGP standard. Philip Zimmermann

1 0

C-punks in print...
by Jim choate 17 Dec '03

17 Dec '03

Hi all, For those interested there is an article in the July 94 issue of Circuit Cellar Ink: The Computer Applications Journal on pp. 36. It specificaly mentions the c-punks and their position (ala Gilmore) on various issues of crypto and constitutional rights. Is a good article but shallow on technical details. It is intended more as a pump primer for those poor souls doing real-time control apps. I would say it is worth the time to read. Take care.

1 0

Announcement: PGS v0.99c
by ER CRAMER 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- PGS v0.99c is out there! This new version of PGS supports 8 bytes keyid's. This version will be able to run in a OS/2 DOS box. PGS v0.99c is available on the following site: wuarchive.wustl.edu:/pub/msdos_uploads/pgs/pgs099c.zip I hope that at the end of next week PGS v0.99c will be available at SimTel too... (oak.oakland.com:/SimTel/security/pgs099c.zip) Do not throw away 0.99b yet because we did the bugfix a bit fast because we want to have it ready before the hollidays... - -- ... If you outlaw Privacy, only Outlaws will have Privacy! Eelco Cramer <crame001(a)hio.tem.nhl.nl> ------ - -------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: 2.6 iQCVAgUBLh1SOYDAdPKe9hHLAQFkXAP/UTodjE7HqCGVZAazLAxdYrWcrVgMsYBa kPjn2litqpxZWusMjqTIS3+vHYHrEhXCzBexl69CEo1XQ46PNe1kbrbpwPxGCwzc uCryNVeZ+sOdpJOTAWmPmEYM151X2w7KEjI7vPMmgShQGjQlOBWR0PvQ3VOEd61U mUP6FCfW5HQ= =aEkc -----END PGP SIGNATURE-----

1 0

Re:
by lefty＠apple.com 17 Dec '03

17 Dec '03

>On Wed, 6 Jul 1994, Mike Markley wrote: >> can't be broken in a reasonable amount of time. I'm interested in what >> most of the people on this list would consider a reasonable amount of >> time though. > >NEVER is what I consider a reasonable amount of time. >I don't want my secure thoughts broken for public display >in my lifetime. Or any of my children's lifetime. Or there >children's lifetime. .......... You had better not have any "secure thoughts" then. "Forever" is enough time to break _any_ cipher. -- Lefty (lefty(a)apple.com) C:.M:.C:., D:.O:.D:.

2 1

RE: "Cypherpunk" vs. "Cryptorebel"
by lefty＠apple.com 17 Dec '03

17 Dec '03

>On Wed, 6 Jul 1994, Lefty wrote: > >> >I like the label "cryptorebel" better than "cypherpunk". The word >> >"punk" just does not seem right, while "rebel" does. I do have a >> >certain attachment to "cypherpunk". Comments? >> >> If it weren't for nitpickers, we'd all be knee-deep in nits. > > There is too much "name recognition" in "cypherpunk" for it to be dropped >now...IMHO. A more serious problem with the name "cryptorebel", which did not immediately occur to me, is that crypto-whatever generally means "someone who denies being a 'whatever' but, in fact, is one". In the words of Inigo Montoya, "You keep using that word, but I don't think it means what _you_ think it does". -- Lefty (lefty(a)apple.com) C:.M:.C:., D:.O:.D:.

1 0

Curve Encrypt 1.1 Release
by W. Kinney 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Curve Encrypt 1.1, IDEA encryption for the Macintosh is now available. Curve Encrypt is a freeware drag-and-drop encryption application for the Macintosh. It uses IDEA cipher-feedback mode with a 255 character pass phrase, encrypts both the data and resource forks of files, and will encrypt the contents of a folder or volume in a single operation. Source code is provided, natch. CE is System 7 only. (Note that this program has nothing whatsoever to do with elliptic curve encryption methods, just so nobody gets confused...) NEW FOR 1.1 The following changes have been made for the 1.1 release: o Faster encryption and decryption. o Faster file wipes. o Department of Defense standard file wiping is now an option. o The "Use as default pass phrase" selection is no longer present. Instead, Curve Encrypt 1.1 uses keyfiles, a more reliable way to reuse pass phrases. oJCurve Encrypt now saves the creation and modification dates of files when they're encrypted, and restores them to their original values when a file is decrypted. o An incompatibility with the Super Boomerang utility has been fixed. Ftp Sites: ripem.msu.edu:pub/crypt/other/curve-encrypt-idea-for-mac/ This is an export controlled ftp site: read pub/crypt/GETTING_ACCESS for information. ftp.csn.org:/mpj/I_will_not_export/crypto_???????/curve_encrypt/ csn.org is also export-controlled: read /mpj/README for the characters to replace ???????. Address for support: Curve Software <kinney(a)bogart.colorado.edu> Copyright and Distribution: Curve Encrypt (c)1994 Curve Software. Permission is granted for distribution within the United States only, including products containing Curve Software copyrighted source. Export of this software is a Federal crime. Don't do it. Curve Encrypt is free. All releases are verified with PGP signatures. Public key: - -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6 mQCPAiz+bEEAAAEEAMUbtdwYC1vY+s5559ERIvC1MT+Yaw3ozheaHcUciJe7cSAk k9TpAQd7iKukKnQe5kK1YtvYm0JP6fmNrcO8AmG5ukvcOlyuri618sjpXncpQ1cL 5xeV80f3JtmheGMnqAzTK8OyfJ7zRh1PhAZcT/vVzf+JGuCuVcJkEfxTVMrJABEB AAG0K0N1cnZlIFNvZnR3YXJlIDxraW5uZXlAYm9nYXJ0LmNvbG9yYWRvLmVkdT6J AJUCBRAuDZ3RwmQR/FNUyskBAd4wA/90tc6Fp0T3kSrmz0Vsbn+M7eND3fNp/XVy CW4xM6xzQK3ooRAjWBbnZbixTyhzlK33X2+EQGGYB5jWA5A+hgGOk3xYhApgBn+K rivF0xKJxNhR4CnsummIyXLn7UPXl0HrPvKszvSCVDhtky2Sy6jNKQcmN7vkFfY+ aAe8ox8944kAlQIFEC4CAaNLsloC2TxExQEBq2gD/2KeXbfrOC3i6FsTNNrODRI1 7i23XTMiquBWmRNheVIQV1dbNKB7DWawUNaykSZiGCEooW+HRKSv3iEGvQiBu1v1 1JB/7Id10a+bIpzCzzfGQ+RvbCCTt9+gACv3JpuXtBmcvIoHKAUpbuQhUd/vR17x 6U9tNhyEa4fdefHgmUsjiQCVAgUQLQSyUSA78To+806NAQECxQP/X5rfktz8h3Je DqX0c9IhobWL36vYGVvzqr8ViYkARMYI7Q4cKupHgDunO+Q+zKiSSsSFBlzlPe4f dg5hJ+eDOUircFRgz5Bu/CN1jAwPdElAHc4W12yiirTvq4HggR7j37aCPz1xsUmg zbKbiM6FI6SKTWK0faOoXoCCbGzA4v0= =IGUN - -----END PGP PUBLIC KEY BLOCK----- This key is also available from the key servers. Curve Software <kinney(a)bogart.colorado.edu> Cypherpunks write code! -----BEGIN PGP SIGNATURE----- Version: 2.6 iQCVAgUBLhsNVMJkEfxTVMrJAQEFfgP+K7NRta8HUqhlegb1d0r9K/DD2mHqy7tv vKF50VVZordlKxLDryv7O5kpXIQK9iGKSZIyu42WL/L25qNJw5DpmSruNPk80ChK n1vOwzJLSXg4qOmPcVU9ejbxzrUy+j7FUOWC3+mBeOBB/oHYBiAISx3o+UHlLDYC 52leB7ozW8U= =B0E/ -----END PGP SIGNATURE-----

1 0