- cypherpunks-legacy - lists.cpunks.org

Re: NSA on GAK
by Rich Salz 17 Dec '03

17 Dec '03

Yeah, really. I didn't say it isn't true, I just said it's more like a cute quote than truth. Compare the number of bits downloaded in TCP/IP and routing infrastructure to the number of bits that are purchased at the store or via a P.O. Miniscule. r$

1 0

Re: Gary Burnore vs. Earth (Was: Value of Annon. Remailers)
by Anonymous 17 Dec '03

17 Dec '03

Missouri FreeNet Administration <sysadmin(a)mfn.org> wrote: > First off, let us state up front that this is an aside to the previous > poster, and not totally on-point: feel free to hit the delete key, and > accept our apologies if this is a problem. > > About two months ago, we met the infamous Burnore & Company while > defending a semi-annonymous UseNet poster calling himself "Outlaw-Frog-Raper". > It seems that in classical Burnore style "OFR" found himself the sudden > victim of [literally] daily TOS/SPAM complaints by Burnore and Co. for making > use of UseNet to air his decidedly anti-police positions (it's odd how "pro > police" Burnore is, isn't it?). Given Gary Burnore's criminal record, he needs all the sucking up to the police he can get. In addition to his arrest and conviction for molesting his girlfriend's daughter in Santa Clara, CA, he was also arrested for unlawful assembly for his participation in Critical Mass' bicycle blockade of the streets of San Francisco during rush hour. (See: http://www.e-media.com/cm/sac.html ) And this criminal has the chutzpah to try and be a net Nazi as well. This same self-righteous individual once lectured another netizen about how it's wrong to "fight abuse with abuse". > Obviously, as defenders of this man's right to post material offensive > to Burnore, we too came under attack. Fortunately, we have been with > our upstream provider for a long time, and are on *very* good terms: they told > Burnore to keep his complaints to himself. But I digress... The best defense against censorious cretins like Gary Burnore is education. That's what the victims of the infamous "Rev." Steve Winter (who also lives in Raleigh, NC, BTW) had to do to counteract his abusive tactics. A "Steve Winter FAQ" was compiled and posted to Usenet as well as being published on the web. People who are the subject of his harassment tactics have something to show to their ISPs, employers, etc. when Winter makes his bogus threats. > As this "war" intensified, we attempted to determine just who in the hell > this lunatic *was*, as nobody here is a regular Usenet follower (just when > we have our slow periods, we'll check in with the loons to kill a couple of > hours...). To our surprise, we discovered that while Burnore/Databasix/etc. > are known far and wide, the actual traffic that passes between them and the rest > of the Earthly population is pretty well eradicated. Here's a guy who has actually > sat down and deleted (according to DejaNews) *tens of thousands* of his -own- posts! > Not to mention the unknown number of posts which he has "thoughtfully taken care of > for those others who forgot to do so themselves"... This is the same Gary Burnore who cajoled an anonymous whistleblower for "hiding behind a remailer" and boasted "I have nothing to hide", although he himself attempts to gain plausible deniability for his own posts by preventing an impartial third party from archiving them, then claiming they were "forged" if he inserted his foot too far into his mouth. Not only does Gary hide his own posts behind an X-No-Archive header, but posts critical of him have a tendency to be cancelled through forgery. He screwed up once and cancelled a post critical of him that was cross-posted to one of the news.admin.net-abuse.* NGs. Unfortunately for him, an anti-cancel-bot on that NG reposted the cancelled message along with a copy of the forged cancellation message sent by ... guess who ... Gary Burnore! Oops, Gary, can you say "busted"? > The point here is that what little survives about this lunatic child > molester (he has even successfully had his North Carolina Sex Offender record > removed!), has almost all come through *some* annonymizer. Whether a MixMaster, > or Cajones (RIP) "intentional annonymizer", or an "unintentional annonymizer" > such as a large [cypherpunks] listserv with "bad headers". By his own account, Gary Burnore spent nearly $30K getting the child molestation charge plea-bargained down to a misdemeanor. My guess is that he has no money left to carry through on his idle threats of frivolous legal action against those on his lengthy enemies list. For example, when Jeff Burchell demanded a letter from Gary's lawyer when he was demanding that Jeff turn over his remailer logs to DataBasix, what Jeff received was a letter from Gary's girlfriend Belinda Bryan <eridani(a)databasix.com> impersonating a lawyer. For Jeff's account of that episode, visit: http://calvo.teleco.ulpgc.es/listas/cypherpunks@infonex.com/HTML-1997-11/ms… > We submit that it only takes one successful argument, even though there be > a million such arguments available, to "proof" the value of an annoymous remailer. > we then extend the original Burnore story (presented in part below) in further > support. It proves that censorship need not originate with a governmental body. All it takes is a determined individual with more time available to harass than his victims do to defend against it. > Yes, I know, at least half of you are sitting here going "now why did they > bother us with that?". The answer is we feel VERY strongly that if not for > what [little] we were able to find as a result of A/R's, we would never have > been able to figure this clown out at all. And loco though he may be, he is > also a *prodigious* pain in the ass, who represents a real, true threat to > what little freedoms we still have in the US. Burnore isn't a loner in the > political sense: he's actually becoming pretty mainstream. If A/R's can help > to keep scum like him in the light, where he can't hide his hypocrises [sp?] > through a cancel or "DejaNuke", then they are one of our most important national > resources, and should be defended (and *funded*) as such! The problem is that most dissidents have a weak point somewhere where they are vulnerable, whether it be a censorious hate mail campaign to his/her ISP or employer, mail bombing, spam baiting, forged mailing list subscriptions, or one of countless other denial-of-service attacks that Gary Burnore, Belinda Bryan, Billy McClatchie (aka "Wotan"), or otther members of the DataBasix abuse factory can conjure up. > Just our [very biased] $.02 worth... > > The full-time [yet totally volunteer] staff of Missouri FreeNet: > > J.A. Terranson, sysadmin(a)mfn.org > John Blau, jb214(a)mfn.org > Beatrice Hynes, beatrice(a)mfn.org > Frescenne "M", support(a)mfn.org > A. Pates, support(a)mfn.org > > </LURK ON> > --------------------------------------------------------------------- > > <huge brevity snippage> > > Consider the episode last year with Gary Burnore and DataBasix vs. > Jeff Burchell and his Mailmasher and Huge Cajones machines. > Made-to-order abuse appeared right on cue to reinforce the claims > that Burnore and his girlfriend Belinda Bryan had made. And now > we've learned the real truth behind the whole episode. While Gary > Burnore was living with another girlfriend in Santa Clara, CA, he > was also molesting her teenaged daughter. An anonymous > whistleblower attempted to warn the girl's mother as well as her > school officials by anonymous e-mail. Burnore went ballistic and > falsely claimed "harassment". But the whistleblower was ultimately > vindicated when Burnore pled guilty to the molestation charge, was > placed on probation, and was required to register as a sex offender. > Unable to silence the whistleblower, Burnore began a campaign of > harassment against the operators of the remailers that were being > used to expose him. IOW, if you can't refute the message, shoot the > messenger. And if you can't shoot the messenger, attempt to disable > his means of communication (the remailers net). > > I recounted this case history, which can be researched in various > usenet archives by anyone interested, just to demonstrate that one > man's "harassment" can well be another man's investigative > journalism, even if the journalist or whistleblower is not in a > position to expose him/herself to retaliation by the wrongdoer, > which has been (coincidentally?) reported by virtually anyone who > has dared to challenge Gary Burnore publicly.

1 0

Re: More on ECheques (retry)
by Peter Trei 17 Dec '03

17 Dec '03

Gah - it's easy to click on 'send' before you really mean to > You are welcome to test ECheques on our live floristry service. To > do this: > > 1. Download WorkHorse ftp://193.119.26.70/mktnet/pub/horse.zip > 2. Follow the instructions for generating a key. > a) Generate Key System/security/key gen (please use 512 bits) > b) Specify your user details Alter/my details (put in a bank a/c no) If you received a phone call from someone you did not know, who asked you for your bank account number, would you comply? If a stranger handed you a floppy and asked you to run the binary on it. while connected to the Internet, and give it your bank account number, would you do so? If email from an unknown person asked you to download a binary over the internet, and run it, giving it your bank account number, would you do it? That's exactly what is being asked here. Peter Trei Senior Software Engineer Purveyor Development Team Process Software Corporation http://www.process.com trei(a)process.com

1 0

Re: Why ecash is traceable
by dsc＠swcp.com 17 Dec '03

17 Dec '03

Timothy May wrote, >I don't think all systems must be able to deal with double spending. > >For example, the first person to read this number: 45%2)d[12ks&Qmdx and to >then submit it any form--in person, by e-mail, via remailer, etc.--to The >First Bank of Cyberspace will have $10 sent to him or her, as cash or as a >spendable amount of digicash (untraceable to recipient, of course). I would expect that services might emerge that would strengthen this without the bank getting involved and without loss of anonymity. It might emerge that because of the bank's lack of handling of double spending that in some transactions some payees would request a money order from a trustee. The payee might supply the list of money order suppliers allowed for that day. If the payee does not want the money order addressed with a public key, he can supply a set of alternate keys each encrypted for an acceptable trustee. The money order allows the payee to be as sure that the cash is good as he trusts the trustee (and the bank). With or without the use of a remailer this can add to hiding the payer. However, unless the payee provides a hidden key, the trustee does know who received some payment. The trustee is highly motivated to operate a memoryless system (except for the trustee's own cash) and might be audited to ensure this to both customers and potential physical raiders. The cash bundled in the money order need not be that returned from exchanging the money order payment. Some trustees might return a money order containing cash that has other properties, too. If the payee really trusts the trustee, then no race to exchange the cash is needed--hiding the payee further. The payee can exchange it over a period of time or as needed. Exchange includes indirect exchange as in buying money orders. I'm new to protocols and I mention details below only to add hopefully clarifying material, not to suggest that I have any idea of the right ways to do these things. These can be implemented using PGP. Money Order: The automated trustee checks the money (for money order amount and fee). If it is bad the trustee sends it back. Otherwise, the trustee exchanges the cash and then selects from cash on hand cash of the amount of the money order. This is encrypted for the payee. (The buyer must supply something the trustee would know how to use to encrypt for the payee: public key or message addressed to the trustee containing information on how to encrypt for the payee.) The money is encrypted with that. A description is added to this and it is signed by the trustee and sent back to the payer. The description may or may not mention the payee depending on whether the money was wraped with a public key or not. Escrowed Money Order: The trustee creates a money order that can be opened by either the payer or payee and encrypts that for the escrow agent. A description and signature is added. Generalization: Payees and escrow agents can be abstract recipients such as and/or lists. I wonder how much I could charge for this. Dar =========================================================== Dar Scott Home phone: +1 505 299 9497 Dar Scott Consulting Voice: +1 505 299 5790 8637 Horacio Place NE Email: darscott(a)aol.com Albuquerque, NM 87111 dsc(a)swcp.com Fax: +1 505 898 6525 http://www.swcp.com/~correspo/DSC/DarScott.html ===========================================================

1 0

Re: CYPHERPUNK considered harmful.
by tcmay＠got.net 17 Dec '03

17 Dec '03

At 1:58 PM 9/15/95, K. M. Ellis wrote: (quoting my response) >> We fill a certain niche which is useful to have filled, a more radical >> facet of things. If we didn't exist, or renamed ourselves "Concerned >> Citizens for Cryptographic Protection," CCCP, then somebody would have to >> _invent_ the Cypherpunks! >> > >True, but if the majority of active participants see an alternative >agreeable to them, they may just switch and start calling themselves >something else. If the list owner likes it and changes the name of the >list, then what of the cypherpunks unwilling to change? It would appear, >then, that they would be the ones who would have to find somewhere else >to go. Indeed, if a majority of folks on this list start calling themselves "Martians" or "Crypto Tools," then I suppose this list will _gradually_ adopt that name. Though even then there are no guarantees, as this list is run on a machine not controlled by a list democracy. Go for it! If you wish the folks on this list to call themselves "Concerned Citizens for Cryptographic Freedom," then start calling yourself that. What I think would be a waste of everyone's time is a drawn-out series of proposals for new names, a debate which is unlikely in the extreme to result in a new name. >Better than a vote (and more effective in western culture, where only 39% >of the population votes anyway but just tends to go with the flow) is to >propose an alternative, flat out, adopt it for yourself, and whoever >prefers it will follow your lead. If nobody likes it, then the >cypherpunks are simply here to stay. Indeed, some people here have been calling themselves by various names ("CypherGeek," "Crypto Rebel," etc.) for a long time. Personally, I despise the terms "geek," "dweeb," and "nerd," and think anyone who calls themselves by these insults is not "reclaiming and deconstructing the labels of the oppressor class," as the slogan goes, but is merely insulting themselves. Blacks who call themselves "niggers," homosexuals who call themselves "queers," and computer programmers who call themselves "geeks" and "dorks" are all playing the same game. >"long-haired wierdo". I think a slightly more conservatively named >organization similar to the cypherpunks would be a good thing, however, >simply because I like the idea of having something more low-key to compare >c-punks with, sort of like the IRA to Sinn Fein. I'm just offering some >humble advice, knowing full well that I am for the most part an unknown >lurker without much reputational weight to throw around. It's also part >of a leadership dynamic that is, I feel, underused. (Furthermore, if it >works, I could use it as a paper topic for my social psychology class ;). ) The problem is not a "leadership dynamic," the problem is that name changes are not easily arranged. With 700 people on this list, many of whom appear to _like_ the name, how long will it take before enough want to change to make it so? And who says democracy is such a good thing? What if 200 want to change, 100 don't, and the rest don't care or don't "vote"? A better approach is for the "conservatives" who want a "more conservative" name to simply do what I suggested: form a new group and name it what they like. They wouldn't have to quit this list, they would just be able to cleanly recruit for their new list. Seems simple to me. And honest. And less devisive than trying to change the name of a group with a long history (by modern standards) and with several well-known achievements. --Tim May ---------:---------:---------:---------:---------:---------:---------:---- Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)got.net 408-728-0152 | anonymous networks, digital pseudonyms, zero Corralitos, CA | knowledge, reputations, information markets, Higher Power: 2^756839 | black markets, collapse of governments. "National borders are just speed bumps on the information superhighway."

1 0

No Subject
by syrinx＠c2.org 17 Dec '03

17 Dec '03

> Meaning: In all cases, if a page is being shown and >it links to another page, then the other page is being >shown. >I wonder if I have a pornopage. Does this mean that if I have a link to Infoseek or another search engine, that I, too, am hosting pornography? Which would be an interesting idea as far as trying to present a "safe" way to search the Internet. A web- crawler or other search mechanism of choice could be started up, and simply refuse to run searches for certain keywords. Ideally (but impractical) any pages dug up that contain the questionable words could be manually checked.

1 0

Applied Cryptography, Second Edition: Ordering Information
by Bruce Schneier 17 Dec '03

17 Dec '03

The SECOND EDITION of APPLIED CRYPTOGRAPHY is coming in November. This is a major rewrite: 50% more words, 7 more chapters, and over 1600 references. Not only did I make corrections to the first edition and add developments since it was published, but I also included topics left out of the first edition. (See table of contents--attached.) The second edition has lots of new algorithms (including GOST, Blowfish, RC4, and A5), more information on the Clipper Chip and key escrow, dozens of new protocols, more information on how PGP works, detailed information on key management and modes of operation, and new source code. The second edition will be published in paperback and hardcover. Right now I am making both available at a 15% discount. ***************************************************************** ORDER FORM Applied Cryptography, 2nd Edition (Hardcover): $70 * .85 = $59.00 Applied Cryptography, 2nd Edition (Softcover): $50 * .85 = $42.00 Shipping: Air (U.S.): $5 per book Surface (U.S.): $3 per book Canada/Mexico: $7 per book Everywhere else: $9 per book Send to: Counterpane Systems, 101 E Minnehaha Parkway, Minneapolis, MN 55419 ***************************************************************** APPLIED CRYPTOGRAPHY, SECOND EDITION Table of Contents ((Sections in all capitals are either new or substantially rewritten.)) Forward by Whitfield Diffie Preface Chapter 1: Foundations Terminology; STEGANOGRAPHY; Substitution Ciphers and Transposition Ciphers; Simple XOR; One-Time Pads; Computer Algorithms; Large Numbers Part I: Cryptographic Protocols Chapter 2: Protocol Building Blocks Introduction to Protocols; Communications using Symmetric Cryptography; One-Way Functions; One-Way Hash Functions; Communications using Public-Key Cryptography; Digital Signatures; Digital Signatures with Encryption; Random and Pseudo-Random Sequence Generation Chapter 3: Basic Protocols Key Exchange; Authentication; AUTHENTICATION AND KEY EXCHANGE; FORMAL ANALYSIS OF AUTHENTICATION AND KEY-EXCHANGE PROTOCOLS; Multiple-Key Public-Key Cryptography; Secret Splitting; Secret Sharing; Cryptographic Protection of Databases Chapter 4: Intermediate Protocols Timestamping Services; Subliminal Channel; Undeniable Digital Signatures; DESIGNATED CONFIRMER SIGNATURES; PROXY SIGNATURES; Group Signatures; Fail-Stop Digital Signatures; Computing with Encrypted Data; Bit Commitment; Fair Coin Flips; Mental Poker; ONE-WAY ACCUMULATORS; All-or-Nothing Disclosure of Secrets; KEY ESCROW Chapter 5: Advanced Protocols ZERO-KNOWLEDGE PROOFS; Zero-Knowledge Proofs of Identity; Blind Signatures; IDENTITY-BASED PUBLIC-KEY CRYPTOGRAPHY; Oblivious Transfer; OBLIVIOUS SIGNATURES; Simultaneous Contract Signing; Digital Certified Mail; Simultaneous Exchange of Secrets Chapter 6: Esoteric Protocols SECURE ELECTIONS; Secure Multiparty Computation; Anonymous Message Broadcast; DIGITAL CASH Part II: Cryptographic Techniques Chapter 7: Key Length SYMMETRIC KEY LENGTH; PUBLIC-KEY KEY LENGTH; COMPARING SYMMETRIC AND PUBLIC-KEY KEY LENGTH; BIRTHDAY ATTACKS AGAINST ONE-WAY HASH FUNCTIONS; How Long Should a Key Be?; Caveat Emptor Chapter 8: Key Management Generating Keys; NONLINEAR KEYSPACES; Transferring Keys; Verifying Keys; Using Keys; UPDATING KEYS; Storing Keys; Backup Keys; Compromised Keys; Lifetime of Keys; Destroying Keys; Public-Key Key Management Chapter 9: Algorithm Types and Modes Electronic Codebook Mode; Block Replay; Cipher Block Chaining Mode; Stream Ciphers; Self-Synchronizing Stream Ciphers; Cipher-Feedback Mode; Synchronous Stream Ciphers; Output-Feedback Mode; Counter Mode; Other Block-Cipher Modes; CHOOSING A CIPHER MODE; INTERLEAVING; Block Ciphers vs. Stream Ciphers Chapter 10: Using Algorithms Choosing an Algorithm; Public-Key Cryptography vs. Symmetric Cryptography; Encrypting Communications Channels; ENCRYPTING DATA FOR STORAGE; Hardware Encryption vs. Software Encryption; COMPRESSION, ENCODING, AND ENCRYPTION; DETECTING ENCRYPTION; HIDING CIPHERTEXT IN CIPHERTEXT; DESTROYING INFORMATION Part III: Cryptographic Algorithms Chapter 11: Mathematical Background Information Theory; Complexity Theory; NUMBER THEORY; FACTORING; Prime Number Generation; Discrete Logarithms in a Finite Field Chapter 12: Data Encryption Standard Background; Description of DES; Security of DES; DIFFERENTIAL AND LINEAR CRYPTANALYSIS; THE REAL DESIGN CRITERIA; DES VARIANTS; HOW SECURE IS DES TODAY? Chapter 13: Other Block Algorithms Lucifer; Madryga; Newdes; Feal-N; Redoc; LOKI; Khufu and Khafre; RC2; Idea; Mmb; CA-1.1; SKIPJACK Chapter 14: Still Other Block Algorithms GOST; CAST; BLOWFISH; SAFER K-64; 3-WAY; CRAB; SXAL8/MBAL; RC5; OTHER BLOCK ALGORITHMS; THEORY OF BLOCK CIPHER DESIGN; USING ONE-WAY HASH FUNCTIONS; CHOOSING A BLOCK ALGORITHM Chapter 15: Combining Block Algorithms DOUBLE ENCRYPTION; TRIPLE ENCRYPTION; DOUBLING THE BLOCK LENGTH; OTHER MULTIPLE ENCRYPTION SCHEMES; CDMF KEY SHORTENING; WHITENING; CASCADING MULTIPLE BLOCK ALGORITHMS; COMBINING MULTIPLE BLOCK ALGORITHMS Chapter 16: Pseudo-Random-Sequence Generators and Stream Ciphers Linear Congruential Generators; Linear Feedback Shift Registers; LFSRs in Software; DESIGN AND ANALYSIS OF STREAM CIPHERS; Stream Ciphers using LFSRs; A5; HUGHES XPD/KPD; NANOTEQ; RAMBUTAN; ADDITIVE GENERATORS; GIFFORD; ALGORITHM M; PKZIP Chapter 17: Other Stream Ciphers and Real Random-Sequence Generators RC4; SEAL; WAKE; FEEDBACK WITH CARRY SHIFT REGISTERS; STREAM CIPHERS USING FCSRS; NONLINEAR FEEDBACK SHIFT REGISTERS; Other Stream Ciphers; System-Theoretic Approach to Stream Cipher Design; Complexity-Theoretic Approach to Stream Cipher Design; Other Approaches to Stream Cipher Design; CASCADING MULTIPLE STREAM CIPHERS; CHOOSING A STREAM CIPHER; GENERATING MULTIPLE STREAMS FROM A SINGLE PSEUDO- RANDOM SEQUENCE GENERATOR; REAL RANDOM-SEQUENCE GENERATORS Chapter 18: One-Way Hash Functions Background; Snefru; N-HASH; MD4; MD5; MD2; Secure Hash Algorithm (SHA); RIPE-MD; Haval; Other One-Way Hash Functions; ONE-WAY HASH FUNCTIONS USING SYMMETRIC BLOCK ALGORITHMS; Using Public-key Algorithms; CHOOSING A ONE-WAY HASH FUNCTION; MESSAGE AUTHENTICATION CODES Chapter 19: Public-Key Algorithms Background; Knapsack Algorithms; RSA; Pohlig-Hellman; Rabin; ElGamal; McEliece; Elliptic Curve Cryptosystems; LUC; FINITE AUTOMATON PUBLIC-KEY CRYPTOSYSTEMS Chapter 20: Public-Key Digital Signature Algorithms Digital Signature Algorithm (DSA); DSA VARIANTS; GOST DIGITAL SIGNATURE ALGORITHM; DISCRETE LOGARITHM SIGNATURE SCHEMES; Ong-Schnorr-Shamir; Esign; Cellular Automata; Other Public-Key Algorithms Chapter 21: Identification Schemes Feige-Fiat-Shamir; Guillou-Quisquater; Schnorr; CONVERTING IDENTIFICATION SCHEMES TO SIGNATURE SCHEMES Chapter 22: Key-Exchange Algorithms DIFFIE-HELLMAN; STATION-TO-STATION PROTOCOL; Shamir's Three- Pass Protocol; COMSET; Encrypted Key Exchange; FORTIFIED KEY NEGOTIATION; Conference Key Distribution and Secret Broadcasting Chapter 23: Special Algorithms for Protocols Multiple-Key Public-Key Cryptography; Secret Sharing Algorithms; Subliminal Channel; Undeniable Digital Signatures; DESIGNATED CONFIRMER SIGNATURES; Computing with Encrypted Data; Fair Coin Flips; ONE-WAY ACCUMULATORS; All- or-Nothing Disclosure of Secrets; FAIR AND FAILSAFE CRYPTOSYSTEMS; Zero-Knowledge Proofs of Knowledge; Blind Signatures; Oblivious Transfer; Secure Multiparty Computation; Probabilistic Encryption; Quantum Cryptography Part IV: The Real World Chapter 24: Example Implementations IBM Secret-Key Management Protocol; Mitrenet; ISDN; STU-III; Kerberos; KryptoKnight; SESAME; IBM COMMON CRYPTOGRAPHIC ARCHITECTURE; ISO Authentication Framework; Privacy-Enhanced Mail (PEM); Message Security Protocol; PRETTY GOOD PRIVACY (PGP); SMART CARDS; PUBLIC-KEY CRYPTOGRAPHY STANDARDS; UNIVERSAL ELECTRONIC PAYMENT SYSTEM; CLIPPER; CAPSTONE; AT&T MODEL 3600 TELEPHONE SECURITY DEVICE Chapter 25: Politics NATIONAL SECURITY AGENCY; National Computer Security Center; National Institute of Standards and Technology; RSA Data Security, Inc.; PUBLIC KEY PARTNERS; International Association for Cryptologic Research; RACE Integrity Primitives Evaluation; CONDITIONAL ACCESS FOR EUROPE; ISO/IEC 9979; PROFESSIONAL, CIVIL LIBERTIES, AND INDUSTRY GROUPS; Sci.Crypt; CYPHERPUNKS; Patents; U.S. EXPORT RULES; FOREIGN IMPORT AND EXPORT OF CRYPTOGRAPHY; Legal Issues AFTERWARD BY MATT BLAZE Source Code DES; LOKI91; IDEA; GOST; BLOWFISH; 3-WAY; RC5; A5; SEAL; WAKE References

1 0

Crypto + Economics + AI = Digital Money Economies
by tcmay＠got.net 17 Dec '03

17 Dec '03

Dar Scott proposes some extensions to digital cash to deal with the issues being discussed here. He mentions "money orders" and "escrowed money orders," and he alludes to "trustees," or agents that would behave in certain well-defined ways. This is as good a place as any to address a point I've been thinking about for a long while, and which I've touched on before. Namely, that the "ontology" of digital money, the instruments and forms it can take, are _impoverished_ compared to the real world. In my eight years of following digital cash work, I've been struck with how little _economics_ enters the fray. Many of the protocols that seem to have problems from a purely cryptographic point of view seem to get fixed when additional _economic_ considerations are included (the consideration we cite the most is "reputation," and we debate this endlessly). The PGP "web of trust" is a kind of example of this additional consideration, if we make certain fairly reasonable assumptions about the nature of collusion. (Lots of stuff to get into here, but I want to make some other points and not get too sidetracked.) "Digital money" currently has only a few ways of dealing with transfers of value in transactions. A lot of the problems come, in my view, from this relatively spartan set of "primitives." Where are the cryptographic equivalents of: - money orders - promissary notes - receipts - warrants - lockboxes - bearer bonds - options - time deposits - coupons - escrow - IOUs - zero coupon bonds - checks ...and so on. The terms in any good dictionary of financial terms (such as the "MIT Dictionary of Modern Economics," ed. by David Pearce, 1992). (Many of these things are built up out of more basic things, with mix-ins from other classses, or with modified methods.) A look at any book on money and finance shows a rich "microworld" of "things" and "procedures" (classes and methods attached to classes). The classes have subclasses, and the methods have various behaviors and "expectations" attached (more than just simple class behavior, more of an AI or agent flavor, in my view). (AI is somewhat of a dirty word these days, due to hyped expectations. But many of the methods have been useful in limited domains. The domain of financial transactions, with the classes and methods hinted at above, involve a lot of formal manipulations and expected behaviors.) In the real world, as the "base class" of "things traded" (tangible assets) reached various limits, a new class of "money" was created, where money was gold, silver, spices, etc., that could be more easily transported and stored. And so on, through levels of abstraction (marks on clay tablets, entries in ledger books, issuances of certificates, bonds, derivatives, etc.) My point is not to recap views of the history of money in its many forms, or even to give my views on the "ontology of money," but to say that many of the problems we think are present in current digital money systems may largely result from the impoverished set of base classes of digital money. To me, an exciting project is to take the basic cryptographic protocols and build up more structured objects (blobs, envelopes, seals, etc.), and then incorporate these into even more complicated financial instruments. There have been proposals for crypto class libraries, most recently in Ray Cromwell's detailed plan for C++ crypto classes. Others I have been in communication with have expressed interest in doing the same thing in Smalltalk, given that many financial companies are doing a lot of their complicated transactions in Smalltalk. And Java has just entered the scene.... My point is not to argue for any particular language approach, or even to argue for this "ontology of digital money" as a Cypherpunks project, but to share with you some thoughts. I think significant progress will have been achieved when these "financial objects" can be launched and used without a lot of hand-tuning and human intervention. In fact, an "economic microworld" of agents/actors interacting and trading in various forms of digital cash and derivatives would be an exciting "artificial life" example, and one which would test the robustness of protocols. I don't think this is beyond the current state of the art by too much. I'm working on bits and pieces of this, but progress has been slow.... --Tim May ---------:---------:---------:---------:---------:---------:---------:---- Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)got.net 408-728-0152 | anonymous networks, digital pseudonyms, zero Corralitos, CA | knowledge, reputations, information markets, Higher Power: 2^756839 | black markets, collapse of governments. "National borders are just speed bumps on the information superhighway."

1 0

Minutes of IEEE public-key standardization meeting
by Rich Salz 17 Dec '03

17 Dec '03

Date: Fri, 15 Sep 1995 11:08:56 -0800 >From: rschlafly(a)attmail.com (Roger Schlafly) Subject: Crypto '95 P1363 minutes To: p1363(a)RSA.COM MINUTES IEEE P1363: Standard for RSA, Diffie-Hellman, and Related Public-Key Cryptography Burt Kaliski opened the meeting at 1:10 pm. The announced agenda was: IEEE P1363: Standard for RSA, Diffie-Hellman and Related Public-Key Cryptography MEETING NOTICE Thursday, August 31, 1995, 1:00-6:00pm Friday, September 1, 1995, 9:00-6:00pm University of California, Santa Barbara, CA This meeting of the P1363 working group, open to the public, will focus on the editing of a draft standard for RSA, Diffie-Hellman and other public-key cryptography. The meeting follows the CRYPTO '95 conference, held August 27-31 at the same location. AGENDA 1. Approval of Agenda 2. Approval of Minutes from May Meeting 3. Officers' Reports 4. Update on Patent Issues 5. Proposals for New Sections 6. Meeting Schedule 7. Editorial Work (schedule to be determined based on availability of draft material) 8. New Work Assignments Depending on the amount of editorial work, the meeting may end sooner than 6:00pm Friday. If you'd like to participate, contact Burt Kaliski, the working group's chair, at RSA Laboratories, 100 Marine Parkway, Redwood City, CA 94065. Phone: (415) 595-7703, FAX: (415) 595-4126, E-mail: burt(a)rsa.com. Draft sections and copies of previous minutes are available via anonymous ftp to ftp.rsa.com in the "pub/p1363" directory. The working group's electronic mailing list is <p1363(a)rsa.com>; to join, send e-mail to <p1363-request(a)rsa.com>. There will be a meeting fee, though the amount has not yet been established, pending arrangements with the university. It will also be possible for participants to arrange accommodations at the university. DIRECTIONS (excerpted from the CRYPTO announcement) The campus is located approxmately two miles from the Santa Barbara airport, which is served by several airlines, including American, America West, United and US Air. All major rental car agencies are also represented in Santa Barbara, and AMTRAK has rail connections to San Francisco from the north and Los Angeles from the south. Santa Barbara is approximately 100 miles north of the Los Angeles airport, and 350 miles south of San Francisco. For more information on the CRYPTO '95 conference, contact Stafford Tavares, the general chair, at (613) 545-2945 or <tavares(a)ee.queensu.ca>. In attendance, we had: Terry Arnold, Vice Chair Eric Blossom Jean-Francois Dhem *Whitfield Diffie Carl Ellison Amos Fiat Walter Fumy John Gilmore *Roger Golliver Chris Gorsuch David Grawrock Stuart Haber Aleksandar Jurisic *Burt Kaliski, Chair *John Kennedy Katherine T. Kislitzin Judy Koeller Ray Kopsa *Michael Markowitz *Alfred Menezes *Mark Oliver Paul Van Oorschot Minghua Qu *Roger Schlafly, Secretary Sherry Shannon *Jerry Solinas *Scott Vanstone Michael J. Wiener Harold M. Wilensky Roger Zuccherato Those marked with an asterisk were qualified to vote, having also attended 2 of the last 3 meetings (and thus 3 of 4, including this one). Motion 1: (Arnold, Kennedy) The agenda is approved. Passed, unanimously. Motion 2: (Arnold, Markowitz) Approve the minutes. Passed, unanimously. Kaliski reported that he is still trying to get registered OID numbers for us, but it will take the IEEE another six months to get its act together. We can proceed on the assumption that the numbers will be filled in later. Kaliski reported that the IEEE is setting up a web site to store drafts of standards online. The address is http://stdsbbs.ieee.org. When we (and IEEE) are ready, we will set up an area for our drafts. We can limit who can upload and download if we wish. Motion 3: (Oliver, Arnold) Make online documents publicly accessible to anyone. Passed, unanimously. Kaliski will set up a P1363 area on the SPA server, as soon as it is feasible. The other officers had nothing to report. Kaliski gave us a patent update. We still don't have the necessary assurances. One difficulty is the lawsuit between Cylink and RSA Data Security which may drag on for a while. There is also an arbitration proceeding between the two companies, with a ruling expected in a few weeks. The application for a waiver from the IEEE patent policy is still pending. Schlafly suggested amending the application letter to limit the waiver to the Stanford patents on the theory that the situation with the Stanford patents is more likely to be resolved in the near future. (Among other things, the Stanford patents expire much sooner than the MIT RSA patent.) When support for this position was weak, he proposed amending the application to make it clear that there is a stronger case for a waiver on the Stanford, so that if the IEEE chooses to reject our broad request, they will at least know that we could live with a narrower waiver. Others argued that a broad waiver gives our committee maximum freedom, and that we could decide later the extent to which we take advantage of the waiver. Motion 4: (Kennedy, Oliver) Leave waiver request as is. Passed, 7-3. Arnold raised the issue of the removal of a private key syntax from the elliptic curve draft. Motion 5: (Arnold, Gilmore) We introduce a representation of private keys into the standard. Passed, unanimously. Motion 6: (Arnold, Markowitz) Archiving and protecting private keys is outside our scope, and we should not include it in the body of the standard. Passed, unanimously. This motion leaves open the possibility of having advisory material on archiving private keys. This issue also provoked a discussion of syntax alternatives to ASN.1. Ellison argued that ASN.1 has a corrupting influence on the mind, and should be scrapped altogether. Kaliski said that there is no actual requirement that we use ASN.1, and that we could just use bit strings if we wished. No new sections were proposed. The next meeting was scheduled for the Crown Plaza hotel in Toronto, on Nov. 15-16, in conjunction with the Public Key Solutions (PKS) conference sponsored by Mobius. We discussed having the following meeting in conjunction with the RSA Data Security conference. That conference is at the Fairmount hotel, San Francisco, Jan. 17-19. Another possibility is in conjunction with ISOC in Feb. 22-23 at San Diego. Either way, the P1363 would probably be the two days before. We were unable to reach a consensus, so we deferred the issue to the next meeting. Markowitz assumed to role of treasurer again. The meeting fee was $60, or just $25 if only attending one day. Money for the dorms was also collected. At the request of the IEEE editors, we are moving our documents to Microsoft Word format. Our outline is now as follows. 1. Overview, scope, purpose 2. Standards references 3. Definitions 4. Elliptic curves 5. Bibliography Appendices A. Mathematical background B. Supporting algorithms C. Test vectors D. Known state of attacks E. Random numbers F. Hardware support Arnold expressed doubt as to whether the hardware support section was going to come together satisfactorily. So we changed the name of that section to "Other considerations" so that we could include other miscellaneous remarks. Ellison took over the random number section. He wanted to ditch some of the randomness tests as not being strong enough, and include some other explanatory material. At 3:00 we took a break until 3:35. The rest of the meeting was devoted to a detailed discussion of the elliptic curve draft. Menezes handed out a new copy. Solinas handed out a paper on elliptic curve point counting, to be included in appendix B. It gives a nice way of choosing a curve with a predictable number of points. To make it more complete, he will add a couple of references, particularly to the forthcoming CRC handbook of applied cryptography, by Menezes, Van Oorschot, and Vanstone. Vanstone suggested switching the elliptic curve spec to multiplicative notation. Mathematicians prefer to use an additive notation because the curve is an abelian group. However, it is very confusing for cryptographers because the formulas are analogous to Diffie-Hellman and Elgamal protocols where the principal operation is multiplication in Zp. Motion 7: (Kennedy, Menezes) Stay with additive notation for elliptic curves, for consistency with the mathematical literature. Passed, unanimously. For various reasons, we decided that n, the order of the elliptic curve base point, should be required to be prime. Someone also thought "G" was better notation for the base point. Kaliski questioned the block splitting scheme in the ECES. Kennedy said it scored high on the hokey meter. At 9:10 Friday morning, the meeting resumed. The treasurer reported collecting $1662.70. This included $538.85 for dorm rooms and $1125 in IEEE fees. Kaliski demonstrated a cryptanalytic attack on these totals, as a way of verifying them. Vanstone gave an explanation of ECES. One rationale for the block splitting scheme is that a typical elliptic curve uses 160 bits for each of x and y. A triple DES key is 168 bits. A straightforward scheme would only use x, and thus not be able to encrypt the whole triple DES key. Using y would give 320 bits, but y is (nearly) a function of x, so there are some cryptographic subtleties in using y directly. In the end, we weren't that comfortable with it, so we decided to stick with a simpler one-block scheme. The simpler scheme just multiplies (or perhaps xors) the message by x. We took a break at 10:45. There was more criticism of ASN.1. Ellison offered to construct some simple data representations which would allow us to avoid ASN.1. Kaliski suggested that an elliptic curve point (x,y) with possible compressed y could be represented by [ x bytes ] 00 [ x bytes ] 01 [ x bytes ] 80 [ y bytes] That is, the last line is for the full x and y. If y is compressed down to one bit, the first or second line is used. Kaliski argued against the signature schemes directly referencing a hashing operation. Someone may want to sign something other than a hash value. An implementation may want to conform without having a hash function built-in. Solinas objected that there are risks to signing data other than hash values. This issue was not resolved. Solinas complained that there are various parameters buried in the draft without any indication as to how these are related to overall security. He volunteered to write some notes on how the various parameters were related to each other. How these are incorporated is to be determined. Someone pointed out we should check r = 0 or s = 0 in the signature schemes. At 12:20 we took a break for lunch, until 1:45. Vanstone gave a talk and handout on key agreement protocols. He showed how he and Menezes found weaknesses in other Diffie-Hellman type protocols, and they proposed a new one that overcomes the problems. We all liked it. We thought q and n should be part of the system parameter setup. There was some discussion of optimal normal bases versus using an irreducible polynomial. We also discussed advantages of restricting to p = 3 mod 4, and to curves with a = -3. At 3:20 we took a break until 3:30. Ellison handed out some introductory material on random numbers that he wrote since taking over the job the day before. The plan now is to have a draft standard at the next (Nov.) meeting, and then to polish it up for ballot at the following meeting. We adjourned at 4:20.

1 0

Re: CYPHERPUNK considered harmful.
by Peter Trei 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Tim writes: >Indeed, some people here have been calling themselves by various names >("CypherGeek," "Crypto Rebel," etc.) for a long time. Personally, I despise >the terms "geek," "dweeb," and "nerd," and think anyone who calls themselves >by these insults is not "reclaiming and deconstructing the labels of the >oppressor class," as the slogan goes, but is merely insulting themselves. >Blacks who call themselves "niggers," homosexuals who call themselves >"queers," and computer programmers who call themselves "geeks" and "dorks" >are all playing the same game. I fail to see how you can write this, and then claim it's OK to call yourself a 'punk'. >A better approach is for the "conservatives" who want a "more conservative" >name to simply do what I suggested: form a new group and name it what they >like. They wouldn't have to quit this list, they would just be able to >cleanly recruit for their new list. >Seems simple to me. And honest. And less devisive than trying to change the >name of a group with a long history (by modern standards) and with several >well-known achievements. Who is trying to be dishonest, and what are they trying to be dishonest about? I'm really confused by this. Tim, I don't want to take your toy away, or minimize the acheivements of the cypherpunks (among whom I somewhat presumptively include myself). OK. Let's NOT drop the term 'cypherpunk'. However, I do think we need to have available another term for 'people with our interests' if we're going to have maximal effectiveness. What follows is my original followup, written last night. - --------------------------------------------------------------- I've gotten a number of responses to my post 'Cypherpunk considered harmful." It's pretty clear that a lot of people did not really understand what I was getting at. This is my fault. I'll try to clarify. What is the situation on the ground, here in mid September 1995? It's utterly clear that the US and other governments, are dead set against the widespread use of strong, unencumbered crypto. 'They' are using many different (and weak) pretexts to delay or prevent it's incorporation into commercial software. If there is a hidden state agenda, 'our' belief is it is that the state wishes to retain it's current ability to spy unseen on the citizenry, wiretapping with or without warrents, and examine stored information without the cooperation of the owner. The general 'cypherpunk viewpoint', if I may generalize, is diametrically opposite: It's not really a hidden agenda, since frequent rants make it pretty clear. Since we're not a unified command and control system like the state, different cypherpunks have different goals, but I hazard that most would agree with: 'Strong, uencumbered cryptography is an empowerment tool for the electronic age; it strengthens the individual in relation to the state, allowing him (or her) to communicate privately, and store his data as securely as if it resided in his own head. The widespread use of strong cryptography will lead to social changes that we regard as desirable.' If you accept this arguably paranoid vision of our situation, then it's clear that we are in a battle for the hearts and minds of the people: The State wants to convince people that their safety and prosperity lies in trusting Big Brother to watch over and take care of them, and nothing but danger lies outside of BB's line of sight. The cypherpunks take a much more libertarian viewpoint; that the state is already too strong and intrusive, and that cryptography will not only allow us to engage in commerce and protect ourselves against crime, it will also allow us to act outside of improper state control. But time is running out. All the state has to do is convince people that strong unescrowed encryption is needed only by criminals - if you trust the state, there is no reason to object to it being able to listen in - after all, all laws are reasonable, and the state won't listen in without a warrant. 'We' have a harder task. We need to convince people that they need encryption - it will protect us against criminals, snoops, and hackers, and the state's proposals will not do this. It's a much more subtle thesis, without the easy emotional hooks that can be exploited by the state to promote it's position. I don't think we can turn people into libertarians, and then get them to adopt cryptography to protect themselves from the statists. At least, not enough people to count in the short term, and the short term is where we need to focus at the moment. I *do* think we can persuade people that they need cryptography to protect themselves against criminals, and that the governments proposed standards for key length limits and key escrow will make the crypto so weak and insecure that it will cause more crime than it will prevent. That's a critical point - that the individual can, without difficulty, use cryptography to protect him or herself against criminals more effectively than he could by relying on the state. The memes we want to propagate are 1. "I need strong unescrowed cryptography to protect myself against criminals." If we can convince a large portion of the population of this (and we have truth on our side), we'll be well on our way. 2. "The government's initiatives on encryption, while they may be well-intentioned, are worse than useless, and will endanger me and my loved ones." If we can get this through the public's collective head as well, we'll have won the battle. This goal is where the 'cypherpunk considered harmful' title comes from. I want to propagate these ideas. If I go up to an average person and tell them "The State is working to ensure that it can spy on your every communication, and can't be trusted to follow it's own rules for doing so. Use cryptography to help promote cryptoanarchy!", he will usually dismiss me as a nutcase. If I say "Criminals and hackers can tap your internet communications, defraud your cell phone account, eavesdrop on your calls, impersonate you, steal your credit card numbers, and spy on your business secrets. I can tell you how you can easily prevent this", then he is interested, and wants to know more. Terms like 'cypherpunk' and 'cryptoanarchy' tend to pigeonhole us as nutcases for many people, and are a barrier to getting our ideas across. I'm not saying this pigeonholing is correct - in fact I despise people who judge a book by it's cover, but so many people DO make such snap judgements that we need to take this into account when talking to the general public. For those who have responded, *I* do not have a problem with the term cypherpunk. However, I know that there are many people who do, people we want on our side. I propose that in communicating with the cryptographic laity, we should be emphasizing the anti-crime aspects of crypto, as well as it's enabling impact on commerce and the American software industry. We'll get a lot more converts with this approach than we would by emphasizing the political aspects of cypherpunk, no matter how important we think they are. Think about it. Which future would you rather see: 1. Lots of people demanding strong unescrowed crypto for what you consider rather peripheral and politically unaware reasons, which you have educated them in. 2. Unescrowed crypto banned, with those who promote considered aiders and abeters of the four horsemen, (but boy are they ideologically pure!). Peter Trei I probably won't see any responses till Monday. I'm going for a weekend at a resort on Lake Winnipesaukee. If you need me, I'll be in the hot tub. :-) -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMFmmK1QxhKXe9s8VAQE+tgP+NcKdGvBeJpa8AHGr/RhKCHudZP2qmRNP J699UCCvN006ywIjurjuis48VPj26uxBkcRbeuzNxGlKmZqXIkS0vEcFjrrZhBsK V9dLFFGTZ6JG3nK++mleW1wQB/F0azXXvXKJWa6R+Tnj1oo2ADUxGNQMs9IVmgR3 zsyK3fej+IQ= =YqDH -----END PGP SIGNATURE----- Peter Trei Senior Software Engineer Purveyor Development Team Process Software Corporation http://www.process.com trei(a)process.com

2 1