December 2003 - cypherpunks-legacy

Unsubsrive
by John Robert LoVerso 17 Dec '03

17 Dec '03

Unsubsrive me!

3 3

Re: DANGER! Baby-Food Bombs on the Internet! [was Re: (Fwd)]
by Peter Trei 17 Dec '03

17 Dec '03

> From: Rich Graves <llurch(a)networking.stanford.edu> > > On Thu, 18 Apr 1996, the intrepid anonymous-remailer(a)shell.portal.com > FUDded to cypherpunks: > [Senatorial panic at the spread of knowledge deleted] > Does anyone know the documents that Senator Biden is quoting? I *must > know* how to build The Dreaded Baby-Food Bomb. As usual, altavista comes to the rescue. *A* baby food jar bomb is described at: http://studentweb.tulane.edu/~llovejo/explode.txt and echoed overseas at http://ps.cus.umist.ac.uk/~vivaldi/boom/original.txt I could not find the article on harvesting gunpowder from shotgun shells. Neat stuff in australia on making primary and secondary explosives however (neurocactus). With the Internet in place, government attempts to legislate the flow of ideas and knowledge are about as effective as attempts to legislate the migration routes of birds. Peter Trei trei(a)process.com

1 0

Re: Spaces in passwords
by frantz＠netcom.com 17 Dec '03

17 Dec '03

>Ben Rothke writes: >> Do spaces (ASCII 20) in passwords make them less secure? > >Of course not. In a normal Unix password, adding spaces to the >password search space increases the search space, so it necessarily >makes the search harder. I used to recommend that passwords be a phrase of at least 15 characters. Spaces fall naturally into that model. If your spelling is as bad as mine, then your password is resistant to dictionary attacks. However, then I discovered that there are many brain damaged systems which restrict passwords to 8 characters. (e.g. IBM's VM/ESA, Netcom's UNIX) For those systems, I can only parrot the conventional wisdom, no words, include numbers and/or punctuation, no acronyms, include both upper and lower case, etc. etc. ------------------------------------------------------------------------ Bill Frantz | The CDA means | Periwinkle -- Computer Consulting (408)356-8506 | lost jobs and | 16345 Englewood Ave. frantz(a)netcom.com | dead teenagers | Los Gatos, CA 95032, USA

1 0

Re: [NOISE] Suscrive toasterpun
by SBinkley＠atitech.ca 17 Dec '03

17 Dec '03

>> If cypherpunks made toasters... >> Jim B and Black Unicorn would argue about whether toast should be >> buttered, and what the appropriate flavor of jam/jelly should be; TC May >> would point out that it wasn't really toast, but rather, sliced and >> slightly-burned bread; Perry would kvetch about the lack of crypto-relevance >> of toasters; and a few others would form a new listserver for toasterpunks. >> The service department would be flooded with calls from newbies, asking how >> to make toast. >> >> If Netscape made toasters... >> They'd beta-test the toasters for months, then make one slot too >> wide and the other too narrow. It wouldn't be until a cook in a diner >> pointed out that the toast wasn't coming out right that they'd have their >> design reviewed by a 3rd-party Toaster Engineer. >> >and during daylight savings time, you wouldn't be able to reload the >toaster for an hour unless you set your toaster to standard time or >created a timezone variable. And newbies would start crying when the forgot how to get off the list!!

1 0

Re: (Fwd) RE: Noise Sphere in Java
by Deranged Mutant 17 Dec '03

17 Dec '03

On 18 Apr 96 at 11:13, Hal wrote: [..] > There was a post on cypherpunks a few days ago claiming that the output > of "pgp +makerandom=2000 rand.pgp", which uses the PGP internal RNG, > showed visible structure in the output of a noise sphere program. I > tried modifying Chuck's Java version and ran it with data from pgp > +makerandom, and it looked fine to me. Hm. I didn't see that post... (I wonder if he plotted an ASCII file... or I suspect a troll?) > However, that isn't very meaningful, because I find the that program > output looks fine even with Chuck's version, which is using the Java > internal RNG, a LCM from Knuth. Specifically the Java code is: [..] A lot of bad PRNGs look good with noise spheres.... but what I found while experimenting with them was data based on timer drift samplings that passed a variety of randomness tests but showed up with very clear patterns on a noise sphere... so I made the original post to the list and sci.crypt about it. Noise spheres will show certain correlations in the data. It doesn't mean that the RNG is crypto-usable if it looks good. But if it looks bad then you know to be suspicious.... a visual image makes a clear point better than analyzing a lot of numbers on a page. By no means should it be relied upon as a sole test. [..] > see it. Oh, sometimes I can almost convince myself I'm seeing structure, > but it is never repeatable from run to run. And I see as much with the > output of pgp. Particularly when the graph is sparse you can see some > clumping, but I think it is just random noise. > If the noise sphere can't even reject an LCM RNG, it doesn't sound > that useful to me for crypto purposes. If you see definite spirals and loops then it's more than random noise. It doesn't pass or reject anything. It plots data. If the data shows *definite* patterns, you can reject the RNG. If not, use more sophisticated tests. [..] > at right angles to this. Because polar coordinates are not uniform in > space, the points are clustered along the north-south axis inside the > globe. You can see this in the views, where the upper right view should [..] That's probably what the poster to c'punks wrote about... *sigh* Rob. --- Send a blank message with the subject "send pgp-key" to <WlkngOwl(a)unix.asb.com> for a copy of my PGP key.

1 0

[CDA] "Million Geek March" on Washington
by Dave Del Torto 17 Dec '03

17 Dec '03

[fwd from: Keith A. Glass <salgak(a)dcez.com>] >Friends of Free Speech on the Net: > >On June 30th, 1996, a large anti-CDA rally, the Electronic Freedom March, >is planned for the Ellipse, in front of the White House. But without your >help, it won't happen. > >We need volunteers to help us plan the EFM and the logistics required for >it, people to help us raise funds to pay the expenses (the Park Service >has required us to provide 80 porta-potties, at a cost of nearly $4500.00 >alone, and that's not our only requirement. . .), and people to help us >run the March on June 30th. Not to mention publicity, etc. > >We need your help. **I** need your help. I've posted this to the DC area >groups, as well as to a few groups that I feel might be useful in >gathering more volunteers and interested people. But I need your >committment to help NOW, or we won't be able to run the EFM, or as it's >been called, the "Million Geek March". Come on, out there: help us out!!! > >-- >* Keith A. Glass, Annandale, Virginia, USA, Filker/punster at large * >* Washington Coordinator, Electronic Freedom March * >* 30 June 1996, Washington DC URL: http://www.efm.org * >* Note: the following line is an intentional act of Civil Disobedience: * >* FUCK THE TELECOMMUNICATIONS DECENCY ACT--DEFEND THE FIRST AMENDMENT ! *

1 0

Re: Cypherpunks Death Penalty for "take me of" messages?
by Henry Huang 17 Dec '03

17 Dec '03

On Apr 17, 21:38, Timothy C. May wrote: > >take me of your emailing list > > She (or he) can't even spell "off." > > This clown also sent me the same message privately, so anything done to her > or him is only fair.. > > The Cypherpunks Death Penalty? Someone suggested that certain people were being signed up on Cypherpunks as part of a two-fold spam attack: 1.) in order to flood victim's mailbox with Cypherpunks' Welcome messages, and list postings, 2.) to re-direct victim's ire at the Cypherpunks list, thereby killing 2 birds with 1 stone. Hence, the "Death Penalty" may be jumping the gun, so to speak. ;) Not sure how one would go about looking into this, though. -H

1 0

e$: The CDA and Mrs. G vs. the MTB and Mr. T. -- SINless DBCs?
by rah＠shipwright.com 17 Dec '03

17 Dec '03

--- begin forwarded text Comments: Authenticated sender is <rah(a)shipwright.com> From: rah(a)shipwright.com (Robert Hettinga) To: "e$" <e$(a)thumper.vmeng.com> Date: Wed, 17 Apr 1996 19:47:19 -0400 Subject: e$: The CDA and Mrs. G vs. the MTB and Mr. T. -- SINless DBCs? Reply-to: rah(a)shipwright.com CC: Priority: normal Sender: postmaster(a)thumper.vmeng.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- e$ Robert Hettinga The CDA and Mrs. G vs. the MTB and Mr. T. -- SINless DBCs? 4/17/96 Recently, Mark Twain Bank (MTB, for short) of St. Louis, Missouri, cancelled the ecash accounts of known pornographers. We haven't heard anything about this from Frank Trotter (Mr. T, for short), the bond trader who runs MTB's ecash program, or anybody else at the bank, for that matter, and it dawns on me today that we shouldn't really expect to. MTB is completely within its rights, as any bank is, to refuse an account to anyone, for any reason whatsoever, except where required *not* to do so by statute. Now, there's a paradox, yes? Fortunately, we don't have to do too much tweaking to get an underwriting system for digital bearer certificates (DBCs, for short) which gets us around around the current unpleasantness, one which scales nicely into a totally anonymous system, and which still allows heavily regulated (and censored) banks of deposit like MTB to profit quite well from cash-settled digital commerce on the internet. An interesting thing about this particular epsiode of self-censorship is that MTB did this *before* the Communications Decency Act (CDA) made offensive discourse -- of any kind, anywhere on the net -- illegal in the United States. As an aside, the CDA reminds me of the old chestnut about politically correct Cambridge (Massachusetts) during the first convulsions of second-hand-smoke mania: "In Cambridge, it's illegal to smoke in Boston." MTB, or its antecedants, has probably *always* cancelled a pornographer's bank account upon discovery, and has been doing this since long before *computers* existed, much less geodesic public networks. Rather than excoriate Mr. Trotter and company for bobbling the future, we should remember that Robert Heinlein's famous nosy-spinster next-door neighbor, Mrs. Grundy (Mrs. G, for short), *also* lives in Missouri. I spent middle-to-late adolescence there, and believe me, having moved late one July in the mid-1970's from Anchorage, AK to Ballwin, MO -- which I once likened to going from Haight-Ashbury to Happy Days in a single plane ride - -- I have first-hand knowlege. Mrs. Grundy, god bless her whalebone corset, is a pivotal fact of the universe in Missouri, which, also from personal experience, is a great place to be, er, from. Don't get me wrong. I mean, some of my best friends are from Missouri. I just wouldn't let my daughter move there. Anyway, as a bank of deposit, MTB does *lots* of business with Mrs. Grundy, thank you very much, and, frankly, it does a *lot* more business with Mrs. Grundy than it does with the net. Frank is following the imperatives of his market, and, he is no fool. Lots of moneypunks out there would say that this only highlights the need for more issuers of ecash, in locations safe from government interference, where they can issue digital cash certificates to whomever they choose. This is, of course, the concept of jurisdiction-shopping, or, as Eric Hughes likes to call it, "regulatory arbitrage". I've been giving this some thought, lately. Advocates of jurisdiction shopping forget, of course, that there is no real bandwith, much less competitive free-market bandwidth, in places like Vanuatu, or the Cayman Islands, or probably even Leichtenstein. *.li domains are more likely to get bandwidth faster than the Small Island Nation (SIN, of course ;-)) of one's dreams. If we lived here, we'd be home now. The market, in it's current state, is efficient. Big drag. On the other hand, statists argue that nation-states should pass legislation (so, what else is new...) saying that issuers of digital cash should not be liable for the acts of people using their product. After all, we don't restrict the sale of cars to known bank-robbers, do we? Actually, I've used a straw man here, though a necessary one, as there are more f*ckingstatists out there than there are eL33t mone$ypunk d00ds. Almost by definition, there's no legislative constituency for digital cash, so legislation mandating its liberal issuance sounds more than a little silly. Ecash is under the regulatory radar for the moment, probably because the market is virtually nonexistant. Regulatory stipulation of ecash non-liability actually puts yet another's camel's nose under the tent of banking freedom, which is what we're really fighting for here, right? No need to put one nose there before its time... What moneypunks and (imaginary) statists fail to realize is something that lots of cypherpunks, particularly Eric -- and Tim May -- have been saying all along. The problem should be solved, not by laws, or even regulatory arbitrage, but by cryptographic protocol. That way, it doesn't matter *where* the bank is, or *who* its customers are. Unfortunately, even though we have Eric's great open books idea, so that we might be able to anonymously audit an anonymous bank's books, and we have good hope of location-blinding someday, with things like web-proxies and maybe even IP-spoofing, it doesn't seem like we're really there yet. There's another problem, though. What happens when a previously-secret bank is exposed for the feelthy porno-grubbing perverts that they really are? Enter Mrs. Grundy. We're back to square one, or, more properly, in a low-bandwidth SIN (heh...). Someday, when we have truly anonymous banks, probably through some combination of SINs-with-bandwidth and strong two-way anonymity, legal or not, all of what I'm about to say will be moot. In the meantime, I have a quick-and-dirty fix, using what we have now. The trick is to use the right kinds of organizational entities to do the right things, and stay under the regulatory radar as long as possible. That is, until SINs-with-bandwidth exist and force the issue. By then, the digital bearer certificate market will be too big to control by state-sanctioned force, we hope. To do this, I will, for the final time (Really. Honest to god. I'll include it by URL-reference next time. ;-)), trot out my current world-according-to-Hettinga market model for digital bearer certificates. This won't hurt a bit. Really. Well, maybe just a *little*... Remember, we're talking about a many-to-many relationship between each type of entity below. In addition, anyone who sells something is assumed to have competition. In fact, the more there are of any given entity, the more robust a given DBC market would be. Finally, there's nothing new here to anyone who knows how securities are presently issued, except that the intermediaries (like exchanges, market makers, etc.) can be much smaller and more decentralized, because lower net-borne transaction processing and distribution costs reduce barriers to entry. It ain't rocket science, folks. 1. Protocol Designers. People like Chaum, Shamir (MicroMint), etc., who develop cryptographic e$ protocols. 2. Underwriters. Markets, issues, and validates the DBCs they issue, in this case, ecash. Charges fees to ecash buyers, redeems ecash certificates at "par". Exchanges for other denominations or expired cash are probably free. In addition, underwriters should have some kind of cross-issuer clearing arrangement, so that certificates of the same type issued by different underwriters would look all the same to the user. This should be peer-to-peer, with their trustee (below) acting as trusted intermediary, settling exchanges off the net. They could also all agree to use a central clearinghouse, but that becomes a major failure-point for the entire system, and a possible target of Mrs. Grundy, or worse, her more er, avuncular, associate, the nation state, sometime in the future. Cross-issuer clearing could also be a non-issue with inter-certificate standards, enough bandwidth and the right kind of client software. 3. Trustees. Real-live banks of deposit. Each one has wire connections to SWIFT, probably to the ATM system, and holds the collateral account for the funds on the net. Responsible to the users of ecash, even though the users are anonymous. Pays seignorage (interest on the collateral account) to underwriters, maybe protocol designers. Charges account, transaction fees to same. Insert MTB, or an equivalent, here. 4. Buyers/Sellers. People who buy and sell stuff using ecash, on- or off- line. Merchants can be called a high-volume subclass of on-line users, and they probably have special software and relationships to issuers. 5. Software Developers. Develop and sell software to underwriters, trustees, buyers/sellers under license to designers, where necessary. My favorite transaction model for purchasing and redeeming ecash involves a waterb^h^h^h^h^h^h, er, secure web-page, a card-swiper, a trustee bank with a SWIFT and ATM link, and an underwriter. By the way, Goldberg, Shostack, Parekh(?), and the hardware guy who does HP-XXX crypto -- forgot your name, very sorry -- have some king-hell ideas for card-swipers that emulate floppy disks, both in hardware and software, and output an encrypted DOS-readable file to be read by whatever application needs it. They figured all this out, right there in front of me, between trips to the nosh table at the trade-show section of CFP96. I was so impressed, I bought their dinner later on. Talk to them about development rights. ;-). Anyway, the buyer goes to the underwriter's web-page, punches in the amount desired, swipes his ATM card and punches in his PIN. This information is read and encrypted by the card swiper, and is sent through the underwriter and the trustee, ala Cybercash, to the buyer's bank. The trustee gets a transaction confirmation to issue cash from the buyer's bank on the ATM network, just like an ATM machine does, to be settled on SWIFT later. The trustee then issues a confirmation to the underwriter, who issues the ecash, which is stored by the buyer until use. Redemption does the same thing in reverse. The neat thing about this business model is that it's not only robust -- Metcalfe's law talks about the value of a network being directly proportional to the numbers of nodes connected to it, and that certainly maps well to financial networks like this -- but *every one* of the players in it can eventually be anonymous on the net side. The relationship between the buyer of ecash and his off-net bank is probably biometrically identified, but that's what we have over there anyway, and it certainly that can be changed someday, SIN-wise, as soon as some fiber is pulled or the sattelites fly. The trustee bank cannot see who the buyer/redeemer is, because the transaction can be blinded through to the buyer's off-net bank. The underwriter certainly doesn't need to know anyone's identity on the net side, because of the blind signature protocol, or on the trustee side, because it can only get its financial ability to issue certificates from its trustee, who we've shown doesn't know who the money's from, either. To repeat, this can scale into a system where *nobody* has to know *anybody* to reliably transact business on a cash basis. Trustees, underwriters, protocol designers, buyers/sellers (transactants?), software developers: No one. The real beauty of this in the present environment, where Mrs. Grundy is such a "pivotal fact of the universe", is that the trustee bank, a bank of deposit like Mark Twain Bank, is abstracted completely away from transaction events. The only account Mark Twain has to deal with is a trustee account, one for each underwriter, and, if the underwriters have any sense about protecting their liability against key theft (Hello, Mr. Borenstein...), one for each underwriter's DBC issue, each issue with its own expiration date. This account sees nothing but debits and credits, irrespective of their pornographic content, for the day's traffic on and off the net. The bank can be in any current legal jurisdiction, for the time being, anyway, because it's just taking money on and off its books based on SWIFT and ATM transactions, just like any normal bank would do. The only difference is its network connections to its DBC underwriters, which are no different from it's other on-line connections, analog and digital, with all its other customers. Now, the ability to do this may change, especially if the volume of cash business on the net gets high enough for nation states to begrudge the seignorage being made by the bank and its customers this way, or, more likely, if the local Mrs. Grundy is FUDded by the media into banning cash-settled internet commerce on, heh, principal. Hopefully, by that time, maybe small island nations will have enough bandwidth. Or, better yet, utter two-way anonymity will allow banks to become invisable, at least as far their contacts with other entities on the net are concerned, which means they could again be anywhere, and functionally out of the reach of the law. Finally, as much as I'm rooting for Mr. T at MTB, he is still stuck doing business with Mrs. G, who may actually be on his board or management, and not just in his customer base. And, don't forget the legal consequences of a creatively-applied CDA. There is even a silly sod or two on the ecash email list at the moment, talking seriously about age-differentiated ecash, god help us all, not to mention the Mormon-from-hell who wants to us to include a minor-flag in IP packets, of all places. (I really suppose I *should* talk, as I'm all for sticking micromoney on packets to pay for routing them someday...) The point is, unless Mr. T can figure a way to financially unwind his underwriting role now, he's probably stuck as a combination underwriter/trustee, which actually has some advantages, one being the innecessity to report any information to the ecash userhood about actual contents of the ecash "mint" collateral account (Backed by the Full Faith and Credit of the Mark Twain Bank, of course...). But, it does him absolutely no good with regard to the aforementioned "grundiness": in his client base, on his board, or management heirarchy, or maybe even in his own moral paradigm, god bless *him*. However, it doesn't mean that somebody, or, better, lots of somebodies, can't step in and implement either side (but not both!), of the trustee / underwriter model, sidestepping the problem of Mrs. G completely. It also seems to me that doing this would be much easier if someone was a trustee exclusively, from scratch, but I may be wrong. So, I guess I'm hoping, possibly in vain, that someone at Digicash will wake up one morning and do what they did on the software side: get out of the manger with the other monopoly dogs like Microsoft, and break up the functionality of their business model some more, so that the more prosaic bovine entities of the banking world, i.e., institutional trustees (sorry, ladies...) can have their breakfast. I bet there are whole bunches of successful institutional trustee banks out there, who could hold hold the money while it's on the net, and, as long as they don't have to do much else with it except communicate electronic transaction confirmations back and forth to an underwriter, would love to do so. This kind of business is something they already understand quite thoroughly. If not, I bet there are more than a few pioneers out there who actually understand ecash and other DBC technologies, and would get into the business of being a trustee as their primary focus of business. Certainly Mr. T himself is an existence proof of that, his adventures in Grundyland notwithstanding. Also, turning scads of independent underwriters loose on the net to bash away at the problem of marketing cash-settlement digital commerce might do wonders for David Chaum's mortgage payments on that brand-new Digicash building. So, even though Mrs. Grundy currently has her bloomers in a bunch, CDA or no, and is letting Mr. T and MTB know all about it, Mr. T, or someone like him, can still save the day, for a while, anyway, with SINless DBCs. .....Which is the plaintext of the title, I believe... w5 ;-). Cheers, Bob Hettinga -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMXWCGvgyLN8bw6ZVAQFLrQP9EDRjyYuafbzjEhLOEk/BKDRUQD+Ucf4+ oS2JYV4ooVzBDjIwQxrKH2+RH4SbEMIEpq2+pPpRMin0PJEol5XP5QxtOsYZz37I U6J1qpvk4v+LkA+8v+9oIQSuXAynN6Lagn5I8ZTLf2eZY/bWDVezEbEwKHYrmluw WKYASgw3B64= =/Ojq -----END PGP SIGNATURE----- -------------------------------------------------- The e$ lists are brought to you by: Making Commerce Convenient (tm) - Oki Advanced Products - Marlboro, MA Value-Checker(tm) smart card reader= http://www.oki.com/products/vc.html Where people, networks and money come together: Consult Hyperion http://www.hyperion.co.uk info(a)hyperion.co.uk See your name here. Be a charter sponsor for e$pam, e$, and Ne$ws! See http://thumper.vmeng.com/pub/rah/ or e-mail rah(a)shipwright.com for details... ------------------------------------------------- --- end forwarded text ----------------- Robert Hettinga (rah(a)shipwright.com) e$, 44 Farquhar Street, Boston, MA 02131 USA "If they could 'just pass just pass a few more laws', we would all be criminals." --Vinnie Moscaritolo The e$ Home Page: http://thumper.vmeng.com/pub/rah/

1 0

Re: [Explanation] Re: "STOP SENDING ME THIS SHIT"
by rah＠shipwright.com 17 Dec '03

17 Dec '03

At 1:37 AM 4/18/96, Pat May wrote: > > Crypto relevance: This attack will be eliminated when more mail > agents support public key crypto and the mailing list software can be > modified to check signatures on subscription requests. In my ongoing quest for net.buckyness I sent a subscribe message to the synergetics-l list, and got back a password, which I had to use to actually subscribe. It looked like a majordomo hack of some kind... Cheers, Bob ----------------- Robert Hettinga (rah(a)shipwright.com) e$, 44 Farquhar Street, Boston, MA 02131 USA "If they could 'just pass just pass a few more laws', we would all be criminals." --Vinnie Moscaritolo The e$ Home Page: http://thumper.vmeng.com/pub/rah/

1 0

auto-spam of c'punks list
by John Gilmore 17 Dec '03

17 Dec '03

Someone or something bogusly subscribed a bunch of people to the cypherpunks list. Please don't post any more messages running down the "newbies". None of these people subscribed; they were victims of a nasty prank. I just removed 237 people from the c'punks and c'punks-announce lists who appear to have been subscribed by email forgery. I probably missed a few. For the folks who are getting this message and who don't want to be on the cypherpunks list(s), it's easy to unsubscribe. Send email to: majordomo(a)toad.com that contains these lines: unsubscribe cypherpunks unsubscribe cypherpunks-announce Sorry for any hassle, John

1 0