- cypherpunks-legacy - lists.cpunks.org

PGP utils?
by mgraffam＠idsi.net 17 Dec '03

17 Dec '03

Is there a utility for Unix (or source available?) that reads a PGP encrypted message and displays some information on it, like what key ID the message was encrypted with, and what ciphers were used? Michael J. Graffam (mgraffam(a)idsi.net) http://www.mhv.net/~mgraffam -- Philosophy, Religion, Computers, Crypto, etc They (who) seek to establish systems of government based on the regimentation of all human beings by a handful of individual rulers.. call this a new order. It is not new, and it is not order." - Franklin Delano Roosevelt

2 1

Re: Australian "calculatorcard"
by vin＠shore.net 17 Dec '03

17 Dec '03

Cees de Groot (cg(a)bofh.toad.com) tore himself from the tube to tell us: CG> Yesterday, on UK Discovery, there was an item in the programme CG> Beyond 2000 about an Australian card which implements a CG> challenge-response protocol and can be used for banking, etcetera. CG> Basically, you give your card number (over the phone), get a CG> challenge number, enter your pin and the challenge, and then give the CG> response. All in CC format... Could be one of seven or 8 vendors of so-called "challenge/response" tokens or calculators. Most of those sold in the US and Australia use straight DES (and a token-specific key) to encrypt the "random" challenge number in the token -- but it could be any secret-key algorithm. Actually, the particular environment described -- phone authentication -- is often used as the most notable example of a market where so-called "time-synchonous" tokens hold a notable advantage over challenge/response token. A TS token generates its pseudo-random token-codes continuously and automatically: no buttons, no input. With TS tokens, exact time and a token-specific key are used in a keyed hash to generate a token-code displayed on an LCD on the token for 30 or 60 seconds. The authentication server uses its database record of the token-specific key, time, and the hash to generate the same token-code for a match. This allows a PIN and token-code two-factor authentication to be submitted by touch-tone phone, and it avoids a lot of the hassle (listen/tap/calculate/touch-tone) associated with C/R authentication. As amp <Alan.Pugh(a)internetMCI.COM> noted, the most prominent international vendor of time-synch tokens is a US firm called Security Dynamics, Inc. I've done consulting projects for SDI, off and on, for years. >sounds like the card i use for remote dialup to certain non-public >systems i use at work. it has a six digit number on the front that >changes every 60 seconds. the card is registered to me. when i enter >my username/password i'm prompted for the number. SDI's token is called a SecurID. <http://www.securid.com> SDI uses a <sigh> proprietary hash. The most common app uses a SecurID in a protocol which prepends the PIN, in the clear, to the PRN token-code. (In client/server environments, of course, all communication between an SDI ACE/Client and the ACE/Server is fully encrypted.) SecurIDs can also be loaded with up to three different seeds or keys -- with a pressure-point in one corner to switch between each series of key-based PRNs. For greater security in open networks, SDI sells a PinPad token with a keypad that allows a PIN to be "added" to the PRN token-code -- so the LCD displays a 6-8 digit number (or alphanumeric) which still offers two-factor authentication, without exposing a PIN. > it's Pretty Good >(tm) security, but like anything not biometric, it is vulnerable to >black-bag attacks. physical possession being all that is required. Actually, all ACE/Server or ACE software modules _require_ a user-memorized PIN. Physical possession of a stolen token is not enough to gain illicit access. >if >you know the algorithm and the serial number of the card and the >time, even that isn't necessary. Bleep! Earth to amp! Check your voltage, lately? The token's serial number has nothing whatsoever to do with the generation of a SecurID's PRN token-code. Just because SDI ships its SecurIDs pre-loaded (most token vendors ask the buyers to program their authentication tokens) SDI embosses a serial number on the back of the token to manage shipping and distribution. The serial number stuck to the back of a SecurID after it is programmed with its secret key -- a unique PRN "significantly longer" than 56 bits -- but they are not the same thing. The cpu in a SecurID doesn't even "know" the serial number stuck on the back of the token. (It would be Pretty Stupid <TM> to glue or emboss a secret on the back of the damn token, wouldn't it?) I should note that Alan is just regergitating one of the most widely circulated rumors about SecurIDs -- which like any popular crypto device attracts a lot of wiLd & w00ly speculation. Getting the algorithm for SDI's one-way hash is no big deal, given that it sits in software in thousands of SDI customer installations, protected only by contract and trade secret status. (The integrity of the product -- the unpredictability of the token-code PRN series, and the secrecy of a specific token's seed or key -- rightly depends cryptographic strength of the hash, not the secrecy of the algorithm.) Getting a token-specific secret key would hopefully be a much greater challenge. CG> Can anybody provide me with pointers to more in-depth information CG> about this device and the algorithm(s) behind it ? >i don't know if there are any net sources for them, but i'd be >suprised if not. my card references "security dynamics" of cambridge >massachusetts. Suerte & Happy New Year to all, _Vin <*><*>< Vin McLellan + The Privacy Guild + vin(a)shore.net ><*><**> Heed, fellow citizens, Justice Felix Frankfurter (Butler v. Michigan): "The State insists that, by thus quarantining the general reading public against books not too rugged for grown men and women in order to shield juvenile innocence, it is exercising its power to promote the general welfare. Surely this is to burn the house to roast the pig.... The incidence of this enactment is to reduce the adult population of Michigan to reading only what is fit for children."

1 0

SecurIDs (was Re: Australian "calculatorcard")
by vin＠shore.net 17 Dec '03

17 Dec '03

amp <Alan.Pugh(a)internetMCI.COM> described his SecurID: >> sounds like the card i use for remote dialup to certain non-public >> systems i use at work. it has a six digit number on the front that >> changes every 60 seconds. David Lesher <wb8foz(a)nrk.com> asked: >Do these card systems use a window to handle clock-slip? SDI's ACE/Server or ACE access control module (ACM) has a Progress RDBS built in which maintains a constantly-updated historical record of the _relative_ drift in a particular token's clock-chip, relative to the clock in the server or host. When it receives the first identifier from a user (Name) submitting a SecurID authentication call, the server checks the database for the recorded drift and then predicts what that particular token will use as Current Time. CT, together with a token-specific secret key, is then hashed to generate a token-code which is matched with that submitted by the user, together with the user's memorized PIN. >I'd think you could have the server safely accept # N, N-60 sec, and >N+60 seconds; and adjust the server's idea of your card's clock speed >from that. You have it almost exactly right (or, at least, that's how SDI's ACE/SecurID system handles it;-) SDI throws in a couple other factors: the ACE system handles Current Time in 30 or 60-second blocks (depending on the model of SecurID token being authenticated,) so it needs a little leeway to handle a token which, because of drift, slips into the next time-slot or the one behind. The ACE system actually pre-calculates three token-codes -- each a pseudo-random number, so one will not inform your guess of another -- as it waits for a user's incoming authentication call to be completed. The server will approve access if it receives a token code generated from either its _projected_ Current Time (for this particular token,) or the token-codes generated from Current Time plus or minus one time-slot. When the ACE database indicates that this particular SecurID token has not been used in the past 60 days (many sysadmin make this 90 days) it also kicks in a search mode to minimize the false rejections. In search mode it calculates a series of prospective card-codes, sweeping out to a maximum of 10 time-slots (the actual scope of the search is defined by the sysadmin) fore and aft of whatever the database suggests this token should consider Current Time. If it finds a match between the token-code submitted from a long-unused SecurID and one of those calculated by the server in search mode, it updates its database projection for the drift of that particular token and then requests the use to submit another PRN token-code. A search-mode "match" alone will never result in a user being authenticated -- it only sets him or her up for a second formal authentication cycle where a new PRN card-code is matched against a new set of three token-codes. There are also a number of additional security devices and rules which the server enforces to protect against security threats, racing spoofs, stolen PINs, stolen tokens, etc. The most obvious is a secured record of all incoming authentication calls, recorded by token-code and GMT time. All incoming authentication calls are checked against this file. A SecurID PRN token-code is never accepted twice, and the virtual "time-stamp" within an incoming SecurID token-code must always be later and in proper sequence to all other recorded authentication calls. > >What new risk would that create? If the SDI hash algorithm is of sufficient strength, very little, I would think. (SDI just asked me to create an FAQ for their SecurID, so all queries are welcome -- on-line or off.) Suerte, _Vin Vin McLellan +The Privacy Guild+ <vin(a)shore.net> 53 Nichols St., Chelsea, Ma. 02150 USA Tel: (617) 884-5548 <*><*><*><*><*><*><*><*><*>

1 0

(NOISE - LONG) Re: PLA_gue Germ Terrorism
by jonnyx 17 Dec '03

17 Dec '03

Crypto relevance: absolutely none! Good lord, what nasty reactions! Maybe there's hope for us after all. I'll allow myself one reply. Sorry 'bout the length. < snip re: my bits on targetting specific genetic traits > zinc wrote: > this is so much shit. targetting anything is very difficult. > just ask all those people about the wonders of gene therapy. > hell, even the economist had an article about it's failures > recently (Dec 16-22 1995, p77). Putting a person on the moon was considered impossible by most folks 50 years ago. The German v-series rockets were cutting edge technology. Now licensed hobbyists can buy solid fuel motors that are just as powerful some of the ones the Nazis had (source: _High Power Rocketry_). Things change. > in any event the so-called 'differences' you are imagining > are phenotypes. these are a long cry from DNA. i'm not > aware of any genetic markers available to distinguish a > black man from a white man. and, even if there were, > recombination requires long stretches of homology between > DNAs, not small differences. i'd bet it's nearly impossible > to target black vs white vs yellow vs a gorilla. Good. The article I read that suggested the possibility (I'm pretty sure it was in _Science_ or _Scientific American_) was rather spooky. I wish you'd said FLATLY impossible, though. I'm (obviosly) not a biologist/geneticist/whatever, but aren't there bugs that go after only chimps? And didn't that ebola strain in Virginia only go after the lab monkeys, not the people? ...and from Jim Choate: > Malarky. < snip > > Most of the threat of this type of experiments are from simple > infections since viruses are not easily raised with this form > of equipment. People will have access to more and better equipment, though. > One of my favorite 'technology rulers' is when the first strain > of commen yeast is released which produces THC or LSD. Heh. Guess they'll have to post extra guards at the Wonder Bread plant, eh? Woudn't want terrorists dosing little Jimmy's lunch. < interesting stuff snipped > > I do not believe we will see this in the near term using the > micro-manipulater systems which do direct injection of genetic > material because of the cost and utility requirements of such > equipment. Which will probably become simplified, streamlined, and cheaper. Who knows what techniques will be used 20-50 years from now? Even though (fortunately) it seems that this kind of virus would be much tougher to produce than I thought (if not impossible), I can still see someone trying it and infecting EVERYONE in his neighborhood/city/state. And if it is possible, well, I'd rather have the idea explored and cures developed (with the info available to all) before any would-be Hitler surprised us. Finally, from E. ALLEN SMITH > E. Coli (the workhorse of prokaryotic genetics) can be a pathogen > if the right plasmid is inserted. > Incidentally, thanks to the person who quashed the > "black-seeking virus" idiot. Not my idea (I'm not that twisted; I find the idea horrifying). I read the suggestion in either _Science_ or _Scientific American_ (early 1993?). Incidently, the idea was a virus that went after people with specific racial traits, not a "black-seeking virus". Don't attribute me with quotes that aren't mine. I have enough problems with idiots who assume I'm a racist KKK country-music loving redneck simply because I'm from Nashville. > Human races are so far from being proper genetically distinct > subspecies that nobody competent would call them that, Guess what sunshine, they still teach this in mid- and high-schools. Hell, even my dictionary sez "race - 1) a division of the human population distinguished by physical characteristics transmitted by genes." (Webster's II New Riverside Dictionary, if anyone cares) > if they only weren't us. Huh? Now back to our regularly scheduled crypto (yeah, right). -- || ______ || comments, criticisms, and/or death-threats may be sent to: || || \__ /\ || jonny anonymous, c/o jonnyx(a)edge.net || || __/ / \ || or snail-mail pobox 23001, nashvegas tn 37202-3001, usa || || \__/_/\_\ ||______"DRIVING DRUNK ON THE INFORMATION SUPERHIGHWAY!"______||

1 0

put me on the list
by Basspunx＠aol.com 17 Dec '03

17 Dec '03

i would like to be put on the cypherpunks mailing list

1 0

(fwd) e$: Looking down, not up, to the future
by rah＠shipwright.com 17 Dec '03

17 Dec '03

--- begin forwarded text Sender: e$(a)thumper.vmeng.com Reply-To: rah(a)shipwright.com (Robert Hettinga) Mime-Version: 1.0 From: rah(a)shipwright.com (Robert Hettinga) Date: Fri, 29 Dec 1995 15:07:53 -0500 Precedence: Bulk To: Multiple recipients of <e$(a)thumper.vmeng.com> Subject: e$: Looking down, not up, to the future -----BEGIN PGP SIGNED MESSAGE----- e$: Looking down, not up, to the future 12/29/95 First a little administrivia. Going forward, I'm going to be posting my rants here first at e$(a)thumper.vmeng.com, with a forward from e$ of the given rant, after some arbitrary delay, to any other lists that might be appropriate to the subject. My sponsors have paid for this list, and the readership of the e$pam and e$ are there to hear what I and others have to say about e$ and its consequences here, and so my stuff goes onto the e$ list first from now on. Like all my writing on the net, redistribution with attribution to me and the other people I cite (When remember to cite them all...) here is just fine. If you're publishing it, and you pay your authors, I'd like to be compensated too, of course. Not that what I say here is going to be all that earthshaking, but I thought I'd clear the air a bit. I've read a lot of interesting things about the future of the net in the last few weeks, some of which I've sent on to e$pam, and I'd like to talk about them, by way of clearing the decks for the New Year. First, I'd like to go revise my model of net.reality a bit. Most of people look at the net as a hierarchy. Architecturally, it is exactly that, from the IP addressing scheme, to the object super-hierarchies in component software models, to server-mirroring, to just about any kind of structural component of the net you would care to look at. Physically, big lines get broken up by big switches into smaller lines which get broken up by smaller switches into smaller lines, in a fractal process which ends up at you or me, where it goes back up each larger level to get where it needs to go. In software, the CORBA object model, and the super-object-model that the research people have been cooking up at Microsoft, all have a "root" somewhere; the "top" of their taxonomical system, if you will. In information, there's a source of the information, and it gets accreted with other information and synthesized and averaged and summarized and rolled up into some larger aggregate which allows you to have some knowlege about that information and other information like it. In finance, my money gets pooled with other people's money through several larger aggregation layers and then invested or spent centrally somewhere. The recipient of capital or cashflow then spends or invests it in fractally smaller chunks until I get it in a check for something I do. I could go on and on with this, but you can see my point, and it is the same point Rich Lethin loves to use on *me* when I start talking about "geodesic" anything, that is, the idea that Moore's law exponentially collapses switching costs, making nodes cheaper than lines, making the network and the software processes mapped onto it more geodesic instead of hierarchical, and "surfacting" information and software into fractally smaller and smaller pieces. What I've been saying to Rich, particularly when I talk about geodesic networks, is that the message itself is point-to-point, even though the actual electrons may flow more or less hierarchically around the network. That's kept him busy while I made my getaway. It always felt like a sophistic shuck, myself, but I'd learned to live with it until now. I don't know if I've gotten anywhere, but I've been thinking about it a bit, thrashing anologies from other parts of the world, --the major way I think, unfortunately -- to describe what I see out there. I've been thinking about biological models, because in my stranger moments, I like pretend that the net is an electro-biological entity. For instance, the circulation of blood is a good anology, I think, because all the endocrine messages in the blood stream are ultimately broadcast from a single cell and paradoxically sent point to point to another cell -- just like things are on an ethernet wire, or on Gilder's fanciful dark fiber, even though the circulatory "backbone" is hierarchical. The most obvious example of course is the organization of neurons, in that the brain pathways are essentially geodesic, but we still have to deal with the hierarchy of nerves outside of the brain. The one thing I think that differentiates these models from the hierarchies we encounter in social life, the industrial induced control hierarchies we all rail against, and the stuff I like to quixotically do battle with on the net, is that every one of those biological hierarchies is chaotic. There is no pretense of top-down control of the system. The load of the system is hierarchical, and so the system organizes itself hierarchically. There are physical forces which create physically hierarchical stuctures, but they're usually set up to solve the problem of efficient distribution of something over a distance, like draining a watershed, or getting blood to a central heart and lungs, or nerve impulses back and forth to the brain. When distance isn't a problem, networks, like the brain, tend to get more geodesic. Bandwidth is maintained by an abundance of neuronic "switches", doubling as processors, tripling as memory, each with some number of connections to other neurons, rather than a bunch of "fat" nurons doing all the signal processing. As an exception which proves the rule, note there *are* in fact "fat" neurons, more precisely redundant neuron pathways, particularly between the two halves of the brain, and between the brain and the rest of the body. So, what else is new? We still have hierarchies on the net, right? We're about to bump up by many orders of magnitude the number of possible IP addresses real soon, so that someday your toaster can tell your alarm clock to wake you for breakfast. I've ranted, tounge-in-cheek, about the "dangers" of the "X.blabla" book-entry view of the world, with hierarchical, government-as-root certification "authorities", and the consequences of having an audit trail on your every net-based financial activity. Most of this X.blabla stuff will come to pass, mostly because it's the easiest thing for the financial system as it's currently organized to do. It's sort of like financial "shovelware", moving the contents of one financial medium, the hierarchic industrial paradigm of government regulated central banking systems onto the new medium of the internet. However, in a world of micro-pay-as-you-go packet routing, where routers may someday spot-auction their bandwidth on a demand basis at packet prices displayed best in scientific notation, all those audit threads could lead to a Gulliverian restraint on personal freedom, much less on individual privacy. Fortunately, I don't think that's going to happen, because those same Lilliputian audit trails will just get in the way and slow the system to a standstill. We need to get more chaotic. I think my contention on this is that as we get smaller and smaller, the more chaotic it's going to have to be. Book-entry based transaction processing systems will choke on their own accounting at those levels. To look at the extremely-hypothetical router above, it will be easier to attach some digital bearer microcertificates to an information packet, so that the packet pays its way through all the routers it needs to go to, than it will be for some giant book entry system to account for it all. People have said that those microcertificates could work like stamps, where the first router cancels the stamp and pays back the other routers in the route some fraction of the "stamp" price to be settled later, or it may be possible to simply endow a packet with all the certificates nessary to get from point to point in a network someday. It kind of reminds me digital cash-as-processor-food, a bit. Note that this kind of bio-economic thinking is not new, the Agorics folks and Stewart Brand have been talking about this stuff for quite a while. My point here is that "down" the network, not up, is the place to look for the interesting stuff in the future. There are several interesting micropayment certificate systems out there, and there will be more. As software gets smaller and smaller with component architectures like OpenDoc and its eventual successors, it will be more and more economic to charge rediculously smaller and smaller amounts for rediculously smaller and smaller network behaviors. Just wait until someone figures how to get software to really "evolve", or gets software to write other software on a practical basis. Most of the people I read, on the net or off, don't see this. They're looking "up" the net, how connections are made up, at the level of the grosser network features, like how monolithic corporations, or book-entry database and financial control systems, or government regulations, will happen on the net. How the net will integrate itself with the "real" world they're familiar with. 8 years ago, I used to talk about people who lived "on" microcomputers versus the ones who lived "in" them. I used to say that Macs were more for people who lived "in" computers because they weren't hindered by the mechanics of the interface so much. I think that there are still a lot of mainframe-cum-client/server folks out there who still live "on" the net, and not in it. Those are the people who are looking "up" at how the "big" players will behave, when they should be look at their feet, where the real action is. Where the very ground is in the process of dissoving out from under them. Cheers, Bob Hettinga -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMORJaPgyLN8bw6ZVAQG+WQP/X4j2qn9tnhDoJKdqctxBCoQzH4F//kKc zsau7Cxs49XGHAaoZo2Pk2svU79FWG7HyWsm0VAPR9ezHiWf8W/Tyi1NgxCkNwjo 62HFNsE0U6Rfo0Itd26WuICe9aC2SG5J6tX8+MzJZqHzzx2xhBUNPKFqt/ZwVtFZ KNLAGkM/7Hg= =jc3o -----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! 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 "Reality is not optional." --Thomas Sowell The NEW(!) e$ Home Page: http://thumper.vmeng.com/pub/rah/ >>>>Phree Phil: Email: zldf(a)clark.net http://www.netresponse.com/zldf <<<<<

1 0

No Subject
by mixmaster＠remail.obscura.com 17 Dec '03

17 Dec '03

FYI: "Cash Crunch" _Wall Street Journal_ by Neal Templin 6/17/96 "Companies are coming up with ways to deal with one of the biggest obstacles to on-line purchases: how to pay for what you buy"

1 0

Re: Fwd: Re: Fwd: Re: FH radios [Dave Emery] [Vaughan Pratt]
by andr0id＠midwest.net 17 Dec '03

17 Dec '03

>think I underestimated how hard things could get. If you're just >trying to track a frequency-hopping signal where the rest of the power >in the band is some mix of Gaussian noise and non-hopping signals, the >carrier should be clearly visible as a spike hopping around in the >band. As soon as you have two or more frequency-hopping signals >however, keeping track of which carrier is which as they hop around >looks *much* harder. If they hop at discernibly different times then >you can correlate a carrier that disappeared with the one that appeared >elsewhere at the same time. This easily described and implemented >approach breaks down when two or more signals hop at the same time. >Here you might try to associate some sort of signature with each signal >to allow you to pair up the new carriers with the old, but you'd have >to know more about the situation to say what signatures would be good. > RF finger-printing would do the trick. Any and all RF equipment has its own RF fingerprint no matter how closely they are made at the factory. Now having equipment to RF fingerprint and identify that fingerprint fast enough is another story! Dr0id (andr0id(a)midwest.net callsign: N9XLM) ( Computer Consulting & Management ) (P.O. Box 421 Cambria, IL 62915-0421) -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2 mQENAzCsIi4AAAEH/1hb5+tO/n99Nbppf0ImLJ6AaVZ3NlZP0ZHwRQor00uA129i d4zWixNXxc8t2auaqN+asV99LpIip3/nQzBnjydiumeBdGLF2PR9+6X8X/RrqKa1 dVIukxM5Agg2eM6ih+0J38hgKJ3qzKXSz6sjYmpaxvbXZoHHOLUk/ZtHUKvvEyPw hnJEYnut8NUnIeK56lqeqRw86yoeRKymbfCdjdpgeY2aRwK2FJts8sbb7Fs10s4y jgxWIxIipBznbGUTh1hb2XrLGPENwk3E/qqXQJEsrySbtwdl6VgTVQjhDDEJMitL DYeiQ3W5EgxfcdbM1j2FwYu3P/dM6Y0I8xLMYT0ABRG0NmFuZHIwaWRAb2ljdTgx Mi5jb20gKG9pY3U4MTIuY29tIHN5c3RlbSBhZG1pbmlzdHJhdG9yKYkBFQMFEDCs LO90C7R/GkJcSQEB01cH/0KC3sd+u4OxMku5378SJktoN6QIQYLJ7uVbuV4S51yK NAotCGf4Wl6wwjynzZvXKU0H87oDuMiq7FybgMNL2n+4bQIZi0iz0lIuzwoMDu63 NrHUW9Kz42pOnhrEhrdkHhHL9O5GgD1yc40fJ3qw5h7LQEjDxgypyw0IFILFc34u LeRLliNibxKp8JwAxXNHWSgxu28TQvmnkHi0AHP6tJ/uZYe+4dqJtrMMsYFjzZaz DPmxD+dzbTwlQKtJaP1ZkDI0Sr072wrZDv+G86GyGBMX2lpSafpRitnxuUttjU9o wsQ9Qo5xiH1nZRCs/bDzJe/gng+GHzevixDIITurtNA= =SgPT -----END PGP PUBLIC KEY BLOCK-----

1 0

throwaway
by an201465＠anon.penet.fi 17 Dec '03

17 Dec '03

[from: WEIRDNUZ.410 (News of the Weird, Dec 15, 1995 by Chuck Shepherd)] LEAD STORY * A 62-year-old woman pleaded guilty in Roanoke, Va., in November to stealing about 500 pieces of mail from her neighbors' mailboxes--her third such offense in five years. She had been found sane and competent for trial but nonetheless diagnosed as having an "irresistible impulse" to steal other people's mail. The judge had kept her confined to her home since her arrest, allowing her full freedom only on Sundays, when there is no mail delivery. [Roanoke Times, 11-21-95] --****ATTENTION****--****ATTENTION****--****ATTENTION****--***ATTENTION*** Your e-mail reply to this message WILL be *automatically* ANONYMIZED. Please, report inappropriate use to abuse(a)anon.penet.fi For information (incl. non-anon reply) write to help(a)anon.penet.fi If you have any problems, address them to admin(a)anon.penet.fi

1 0

-lucre 0.8.1: ecash library for Unix available (with source, no blinding)
by lucre＠alpha.c2.org 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- We are pleased to announce the 0.8.1 ALPHA release of -lucre, a C library which implements the protocols of ecash(tm). This library was developed for research purposes, so source is available, but to avoid patent issues, blinding of coins is not currently supported. Please read the README (appended below) for more detailed information. You can currently get -lucre by anonymous ftp to csclub.uwaterloo.ca, in the directory /pub/-lucre. If you need to reach us, the development team for -lucre, you can try <lucre(a)alpha.c2.org>. Our public key is in the README, below. There is also a mailing list set up for discussing the library. To subscribe, send email to <majordomo(a)c2.org> with a message (_not subject_) of "subscribe dev-lucre". We are providing this library so that people can study how ecash works, and possibly come up with innovative ways of incorporating ecash into existing systems. Paying for remailers, for example, is a topic that seems to come up again and again on some mailing lists. Hopefully, it will also encourage more people to open an account with Mark Twain Bank; the more people who are using ecash, and the more shops that accept ecash, the better the system will be. We believe in open systems, not "security through obscurity", or the "trust me" model of security, and so we saw a full-source release to be important. The distribution comes with the library itself, as well as a very simple ecash client. The client should be usable to accept or pay ecash (or, if you discover it doesn't fit your needs, you can change it yourself), but, of course, you don't get the anonymity offered by the patented blinding feature of ecash. The README is attached below; please read it, as it contains more useful information about the use of this library. - -lucre version 0.8.1 README - --------------------------- This is version 0.8.1 of -lucre (We pronounce it ``dash lucre''; you can pronounce it however you like), the Unofficial Cypherpunks Release of Ecash (or ``Coderpunks'', if you want). As the ``-l'' indicates, this is a C library that implements the protocols of DigiCash's ecash (version 1.8.5, the kind used by Mark Twain Bank, not EUnet). This is an ALPHA release. That is, future release may not even adhere to the same API. This library was developed for, and is provided for, research purposes; adjust your expectations of support accordingly. As far as we know, - -lucre will only work on Unix-style machines; it is unlikely that we will release a Windows or Mac version. - -lucre provides all of the basic things you would like (payment requests, payments, deposits, withdrawals, opening accounts). The format of the wallet is somewhat different from that of DigiCash's standard client, so it would probably be tough to use both that and -lucre with the same MT bank account (maybe not, though; we haven't tried). Most of the information used to produce this program came from information published on the Web, Usenet, and various mailing lists, and from analysis of the output of a logging packet forwarder. The rest was obtained from talking to various people, and from simple experimentation. Because these are not ``official'' sources, some things may be incorrect. Use at your own risk; there is always the possibility, when using ecash, that your money will vanish into the bowels of the network. To use this code, you will need the SSLeay package, which you can get from ftp://ftp.psy.uq.oz.au/pub/Crypto/SSL/SSLeay-0.5.2a.tar.gz, and the Berkeley db package, which you can get from ftp://ftp.cs.berkeley.edu/pub/4bsd/db.1.85.tar.gz. Note especially that the use of SSLeay is subject to restrictions in some countries, including the US. Also, as distributed, this package does _not_ do blinding of withdrawn coins, as that process is patented by Dr. David Chaum. If you manage to license the patent, or if you fall under the ``Experimental Use Exception'' (in the US, and possibly other places), it's up to you to add in the blinding code yourself. In any case, and especially if you plan to use ecash for commercial purposes, we would recommend that you contact competent legal counsel. Note that DigiCash publishes an ``official'' library for ecash, though (at time of writing) it is much higher-level, and without source available. If that library would suit your needs, you are probably better off using it instead of -lucre. This library is _not_ in the public domain. Currently, you may not modify it, redistribute it, or distribute any program linked to it (dynamically or staticly), without our explicit permission (signed by the public key below). This restriction is a reflection of the ALPHA version of the library; it is likely that future versions will have more lenient licensing agreements. Some things we would like to put in future versions: o Resending aborted withdrawals: the code to do this is in there, but the bank seems to think the repeated withdrawal message is a new withdrawal [We lost $0.23 learning this... :-( ]. We'll look into this further. o An interface into resending and cancelling payments: all of the right info is currently being stored in the databases; only convenient functions to actually do the work are needed. o Make the function names more parallel: currently, some are like ``wallet_open'' and some are like ``free_msg'' (we're talking about verb-object order, here). This isn't a big deal, especially if you have lucre.h in front of you. o Put in better differentiation of error conditions, and more logging. o More complete client-to-client communications. Right now it is limited to payment requests and payments. We are, of course, open to suggestions [and ecash donations! :-) ]. You can reach us, the development team for -lucre, at either of the addresses below (in fact, use both, as the nym servers seem to be flaky). Better yet, there is a mailing list to discuss the library; send mail to majordomo(a)c2.org with body "subscribe dev-lucre" to subscribe. Type bits/keyID Date User ID pub 1024/E9E2AC75 1996/06/13 Development team for -lucre <lucre(a)alpha.c2.org> Key fingerprint = 63 94 0D F7 D9 6F 2D E5 08 0F EE 19 CB 6B A9 17 sig E9E2AC75 Development team for -lucre <lucre(a)alpha.c2.org> Development team for -lucre <lucre(a)nym.jpunix.com> sig E9E2AC75 Development team for -lucre <lucre(a)alpha.c2.org> - -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2 mQCNAzHANI0AAAEEANYAvtkmYoH/Mav1A8fuwm+ZsDD4t3NY7nYd6zBKkepLLHWd Ue1Wnyr3mFHcrQBbJshwOJOCCUvYwDHST1TOqssaK/vAVavvubD8kRam+SET04b/ 477krJbCycnbBJ5FSugR4kKKs3S3BkrFWIJaBVTSzsocp+eGrrpcpsjp4qx1AAUR tDBEZXZlbG9wbWVudCB0ZWFtIGZvciAtbHVjcmUgPGx1Y3JlQGFscGhhLmMyLm9y Zz6JAJUDBRAxwDTfulymyOnirHUBAeqmBACfy2V57n/kAWMaUT5cFjW/C9ErL9JD 2ej5xr2vXNsYqXVIGGAc1ZNWIRKdxIp5fs+eBwf6mPRcwHe62a50hp9nTmhNnNCr HLLr6g4KkIgNslYtIma+U7ojysAWrcU0Ng8dse8bheO6OiXPoBVI+stp9Uijl60f tTOCPEP9ldY34LQyRGV2ZWxvcG1lbnQgdGVhbSBmb3IgLWx1Y3JlIDxsdWNyZUBu eW0uanB1bml4LmNvbT6JAJUDBRAxxegrulymyOnirHUBAb+MBADErPAtQdo4X8UU 8uGrFsDvSIfzRVgaz+HarEB1PNW5gsEiw9xhHizT6cKM0L9F7BCJWye2jHDm8DSP a5GdQNEmg+siFOw7+97hELqOzJsOjTBrF+mZ5flEeGQJHKub1D5hRChIqI/bwa5A 6e8AKbLB+mfaO2hfXJtnlroUx9foTg== =GvP2 - -----END PGP PUBLIC KEY BLOCK----- -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMchcGbpcpsjp4qx1AQEVrQQArRPfJgQQq7rRgIl5mBoS5Ju2Hq4aR7u3 mV90yLTHpQq8mC59O2NCxtJzRqfnA9sASVWDZWFudwmzwj6V6f6Kwxb8i8PO4EZ0 28A+BBf+jtpDNG2bsTYxEbIxQM1eE+GuUjSatbW0sYW3J3df7YeYyQAVU/7b2dni +BLOnD4tqvw= =Jozg -----END PGP SIGNATURE-----

1 0