December 2003 - cypherpunks-legacy

Re: Talking to Jim
by anonymous-remailer＠shell.portal.com 17 Dec '03

17 Dec '03

On Sat, 2 Dec 1995 anonymous-remailer(a)shell.portal.com wrote: > > The market seems to "think" that it's a better present judge > > of what Netscape has than he does. It's almost as though > > the "market" has developed a "mind" of its own. > > Well, of course! Markets are the most efficient integration of the minds > of the participants, hands down. Hands down efficient integration?? Not especially. First you have to really wonder what and who the "participants" in this market are. As an example, year-ends have certain particular momentums. So do capital gains considerations. All part of the mind of Buddha, as some of the fruitcake players might say ... and all part of the known interplaying "participants". > > It's own particular neural network. > > Exactly. Literally. And huge, too. Except that this one doesn't listen to any of its sensors or input devices. It's learned to ignore all of *that* information, because all of *that* information is inherently untrustworthy, so it simply listens to it's very own dialogue. Sort of like feeding off of a feedback loop. > > It's almost as though there is automated software at work. Just like October, 1987. It simply listened to itself and kept telling itself that it was "actually" making money all the way down. Portfolio Insurance be damned, it was doing "OK". > There is: Wetware. Massive concurrent processing, heavy parallelism, > inefficient I/O. Distributed, redundant memory. Inefficient but infinitely > adaptable interprocessor routing. Capable of handling any degree of > outage. All elements individually expendable. Self-replicating processors > that have significant lead time but integrate smoothly into the net. > Designs and builds its own outboard peripherals and interconnects. Best > damned planetary computing system in this star system. But I diverge... IMHO, there is very little wetware left in the market. This is now the 90's. Time to get with the programs. > It's not always right (though self-fulfilling prophecy is often a big > part of the equation), and it often misses the anolamies, but because it > IS an integration is precisely why it may mean something different than > you suggest. Oooo ... duelling programs ... especially one which is designed to ignore the other one and not listen to any of its "blather" ... this oughta be interesting to watch ... Luckily, I'm outside this theatre of operations. > Netscape's share price more directly reflects the personal involvement and > upward view of real people with respect to the Internet/WWW than anything > else we have. "Personal" involvement and "real" people have very little to do with a market that is driven by institutions and other vectors. Institutions which have to "show" what their exposure to the "technology and Internet" sector is when they file their portfolio reports will want to show something on their book. And they'll look for a safety in numbers thing, and will flock to the "darlings". "Real people's views" also won't count for much if Netscape defines an entire new economic sector -- the ground floor of the Internet. "Real people" don't factor in if it becomes part of the S&P 500 and every index fund "has" to -- by definition -- buy it. "Real people" also have very little impact on the blow crazed trader who's on a run and actually actively managing and turning-over the pension funds or mutual funds of some group. (Or even a sector fund, whose by-laws won't allow it to sit on cash, as it flows in the door.) These guys have far more influence than the aggregate of individuals who might buy or sell "small" lots at the market. "Real people" don't impact nor control the communications networks of block trading reports. And they don't impact systems which *must* put their money out, and put it to work. Real people are really just noise in the flow. The idea that individual supply/demand is what moves prices is a fallacy. It's not the "reality" behind the shell game. Buying or selling pressure doesn't ever function as a price mover, because for every "buyer" there is a corresponding "seller". Zero-sums type of stuff. It no more reflects the inherent strength of the Internet, than the Dutch Tulip craze reflected the inherent strength of Tulips. > Remember, there are still naysayers out there, declaiming in places > from books to columns to TV, while the reality is that computers are > now outselling televisions, and a key new form of synergistic human > communication is exploding in exponential growth. Humans deal on a > personal level only moderately well with linear processes, and > poorly with geometric processes -- it's understandable that the > growth of the Internet/WWW and the implications of thereof would be > late in being recognized and be incorrectly understood until > sometime AFTER the changes have rocked the society. Nonsense. (No offence, btw ...) We're back to the man who simply closes his eyes to what's happening, or the ostrich sticking its head in the sand. We've already got the experience to understand how these things work. They've got the "play book", and are following it step by step. > Capitalize ME to the tune of $5 billion, for instance, and I may > be influential not only during the course of your life but the lives of > your great-grandchildren. Capitalize how? Balance sheet? Or market? A $1 Billion or $2 Billion rights issue might be one thing, but this one is another. > Selling Netscape short may or may not be a wise move -- selling market > processes short is usually a fool's exercise in self-delusion. It really depends on what and how you use that tool, doesn't it?? As an example, short sales are excellent ways of "creating" stock in thin markets. They can work to create a virtual share. This might sound strange, but it's a feature of the "market". "Shorts" usually sell borrowed stock hoping to buy it back cheaper at some later date. A broker goes out and "borrows" the stock from another broker, and then that stock is sold to a buyer. The two legs of the short sale actually work together to create a "virtual" share of the corporation. This creates "volume" by trading a "virtual share". At some point, these used to be called derivative plays, before that word became dirty in and of itself. To explain. Let's say that XCO owns 100 shares of Spyglass. And YCO "shorts" 100 Spyglass. What actually happens is that YCO has simply signed a note saying that they "owe" XCO's broker 100 shares of Spyglass. If YCO now sells that stock to ZCO, then there are actually now 200 shares of spyglass out there. 100 actual ones owned by XCO, and 100 virtual ones owned by ZCO. (And a note to someone that says ... I owe ya, a 100 Spyglass.) But the "virtual" stock is indistinguishable from the "actual" stock. Of course the generally known risk is that with price movements that YCO could loose a lot of money on its short. Especially in a "squeeze" play. But if YCO and ZCO are actually "friendly" then all they have to do is shift a lot of money around as the price gyrates. Back-to-back credit facilities usually suffice for this purpose, since all that they really need is a "note" from their banker saying that they're "good people" and are "good for the money", if something does go wrong. That their credit is good in the casino. (And mathematically in fact ... they are good for the money ... cause they don't have a market "position" or opinion, even though they can trade one heck of a lot.) In this case, the short can't be "squeezed" cause he's actually covered. But it can lead to some really interesting optics. And these programs do listen to optics. Especially if YCO and his ZCO friend are up against ACO and his BCO friend. I think it's all just a virtual war at that point. Something to watch via Quotron. But then you'd need a Quotron for that, wouldn't you?? Alice de 'nonymous ... ...just another one of those... P.S. This post is in the public domain. C. S. U. M. O. C. L. U. N. E. > > We Jurgar Din > (that will have to suffice: I do not yet live in a free country) > > +"The battle, Sir, is not to the strong alone. It is to the+ > +vigilant, the active, the brave. Besides, Sir, we have no + > +election. If we were base enough to desire it, it is now + > +too late to retire from the contest." -Patrick Henry 1775 + > > > -----BEGIN PGP SIGNATURE----- > Version: 2.6.2 > > iQBVAwUBMMCsBEjw99YhtpnhAQE04QH8C+jk59lxyAqkVlfhd2VLw3TJKnECdXXJ > fNE7S0QZyd5eqFnZ4wTyHeX18YfTg+xiFZPPfxpRCdgO/x2K8sxFWQ== > =/2cN > -----END PGP SIGNATURE----- > > > > > > > >

1 0

Do the Right Thing
by tcmay＠got.net 17 Dec '03

17 Dec '03

My thesis is that both Netscape and Microsoft are in positions at this time to either do the right thing (tm) or to help build in the tools for a police state, an Orwellian surveillance state. Netscape, being the dominant browser company, and Microsoft, being the dominant OS company, are in special positions to "build in Big Brother." I'm not claiming they are, just that they are clearly in a position to make it technologically more feasible to make non-GAK illegal. They both need to carefully think about the role that's been "given" to them (whether by fortune, hard work, or being in the right place at the right time) and do what's right. Strong words, perhaps, but the implications of mandatory key escrow are quite clear. We debated these points for a long time during the Clipper debate, and later when "Software Key Escrow" began to rear its head. I won't repeat these arguments against GAK here, but will take this opportunity to quote from a new book that actually quotes my words: "May, ever the idea juggler, also weighed in with some powerful arguments _for_ PGP that appealed to a stodgy old Democrat (small "d" as well) like me. Even the Feds should have grasped them. "Could strong crypto be used for sick and disgusting and dangerous purposes?" May asked. And then he answered himself: "So can locked doors, but we don't insist on an 'open door policy' (outside of certain quaint sorority and rooming houses!). So do many forms of privacy allow plotters, molesters, racists, etc. to meet and plot." Whatever May was, anarchist, libertarian, objectivist, or nothing, he was making more sense in those three sentences than Baker could have in a 1,000 essays." [David H. Rothman, "NetWorld! What People are Really Doing on the Internet, and What it Means to You," Prima Publishing, 1996. Note: I don't recall meeting Rothman, and didn't know about this book until I stumbled across it last night in a bookstore.] It is important that such companies as Netscape and Microsoft fully understand that crypto policy will largely determine civil liberties in this country and other countries for a long time to come. And they must understand that they can influence the direction. Bill Gates, after some early waffling, seems to now fully understand the implications of GAK and has written persuasively against it. Jim Clark does not seem to me have thought about it as deeply, or perhaps has views of civil liberties which are not at odds with mandatory key escrow, the "open door policy" mentioned above. And time is of the essence. Things move very fast. It is no longer the case that a law is passed, then companies respond to the new legal regime with their own policies and products. Companies, especially in high tech, are "partners" from the start, as we saw with the Clipper development (where AT&T had known about Clipper for years prior to the first public announcement, and was cooperating in the development of it, not to mention the other companies such as Mykotronx, VLSI Technology, etc., which were involved in secret for years). It is only sheer speculation on our part (some of us, at least) that negotiations about GAK have been going on with the major software companies. Jim Clark, for example, learned what he knows about key escrow _someplace_, and it probably wasn't from our list or from articles he'd read. I'm betting, but could of course be wrong, that he and other folks at Netscape (and I mustn't leave out Microsoft, Sun, SGI, Apple, etc.) have been briefed on key escrow and that various negotiations are already underway. This would match how things were done with Clipper, and would explain Clark's voiced support for the need for GAK. I hope Jeff W. and Jim C. can have some _long_ chats. The stakes are too high for product decisions to be made without full awareness of the implications. The statements from Jim Clark do tend to imply a kind of defeatism, and even Jeff's comments seemed laden with qualifications about "only if the government requires us to." As Hal Finney noted in his post, it's as if the Netscape people are preparing for the inevitable. Maybe it's not an indication that GAK is being considered within Netscape, but maybe it is. After all, one rarely hears "only if we have to" qualifications on things that are truly from out in left field. And what Netscape agrees to put in future releases of its browsers or its servers could have dramatic effects on the whole climate. (A side point, somewhat abstract: The dominance of Netscape, rising from nowhere to becoming the major player in this debate, illustrates a point about "monocultures" and their ecological effects. If yellow corn is good, replace other strains of corn with yellow corn. Pretty soon, the world's corn output is 96% yellow corn. Some ecological downsides to this. In this case, Netscape is becoming the yellow corn of the Web, and an obvious "choke point" for the NSA and its sisters to mandate crypto policies. Hence, the role of non-yellow-corn alternatives...) Should Netscape play ball with the NSA or refuse to cooperate? I'm not suggesting that Netscape "break the law." Actually, there are *no* laws at present about GAK or about the use of strong crypto within the U.S., and most of us want to keep it that way. Thus, Jim Clark and Netscape could strongly lobby for keeping things the way they are, and could even say "If foreign governments demand GAK, let them build it in themselves--we will not produce the software to run a police state." And if export laws demand GAK in exported products, Netscape should "do the right thing" and have two versions. It may add to their costs a little, but it's better than building in the machinery for a GAK law to later be passed. (Explain something to me. I have never, ever understood why it is a concern of the U.S. government that we help build in GAK for foreign governments, that we make sure that products intended for export to France or Syria have GAK that allows those governments to read the traffic of their citizens. And if the concern is that exported versions of software must be readable to the _United States_, then this is a non-starter in terms of sales in many or even most foreign countries! I'm sure France will welcome with open arms a version of Netscape that allows the NSA to read the traffic of French citizens. Oh, by the way, what legal jurisdictions will be involved in obtaining the escrowed keys of foreigners? The answers are both clear and murky, if you catch my drift.) If the U.S. insists on GAK _within the U.S._, as many of us fear is the long-term danger, then all bets are off anyway. But I would hope that Netscape does nothing to make it _easier_ to make this the case! A viable thing for Netscape to do is to announce forthrightly that it will separate the issue of export from what it sells in the U.S., that there will be NO GAK included in any U.S.-sold packages. The quest for an "all world" version, freely exportable, should not take precedence over the civil liberties issues. And I predict that any slight losses in market share or slight increases in product cost will be _less_ than the effects Netscape will see if their product comes to be associated with "Big Brother Inside." Enough for now. --Tim May Views here are not the views of my Internet Service Provider or Government. ---------:---------:---------:---------:---------:---------:---------:---- 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

toy story: more power
by amp 17 Dec '03

17 Dec '03

-- [ From: amp * EMC.Ver #2.3 ] -- obcrypto: i'd like to see how bruter.c would have run on their 'renderfarm'. MOUNTAIN VIEW, CALIF. (Nov. 30) BUSINESS WIRE -Nov. 30, 1995--The making of "Toy Story," the stunning new movie from Walt Disney Pictures that is the world's first full-length completely computer-generated animated film, involved the use of more than 100 high-powered computers from Sun Microsystems -- which together comprised one of the most powerful graphics rendering engines ever created. =snip= For the movie, Pixar created a networked bank or "cluster" of 117 Sun(TM) SPARCstation(TM) 20 workstations -- each containing at least two microprocessors, and running on Sun's Solaris(TM) operating environment -- to handle the critical task of "rendering" each of the 114,000 frames in the 77-minute movie. =snip= Sun worked closely with a team from Pixar to create its RenderFarm, which serves as Pixar's central resource of computer processing power. The RenderFarm uses a network computing architecture in which a powerful SPARCserver(TM) 1000 acting as a "texture server" supplies the necessary data to the many rendering client workstations needed to complete the rendering process. The RenderFarm was assembled by Sun and Pixar engineers in less than a month and drew upon Sun's own experience in setting up "farms" of many systems linked together. Some facts about Pixar's RenderFarm and the computing aspects of "Toy Story": -0- -- The RenderFarm is one of the most powerful rendering engines ever assembled, comprising 87 dual-processor and 30 four-processor SPARCstation 20s and an 8-processor SPARCserver 1000. The RenderFarm has the aggregate performance of 16 billion instructions per second -- its total of 300 processors represents the equivalent of approximately 300 Cray 1 supercomputers. -- Each system is the size of a pizza box, and all 117 systems work in a footprint measuring just 19 inches deep by 14 feet long by 8 feet high. -- Sun is the price/performance leader, in Pixar's own rankings. The SPARCstation 20 HS14MP earned a rating of $80 per Rendermark (a Pixar measurement for rendering performance), while the comparable SGI Indigo Extreme came in at approximately $150 per Rendermark. -- Using one single-processor computer to render "Toy Story" would have taken 43 years of nonstop performance. -- Each of the movie's more than 1,500 shots and 114,000 frames were rendered on the RenderFarm, a task that took 800,000 computer hours to produce the final cut. Each frame used up 300 megabytes of data -- the capacity of a good-sized PC hard disk -- and required from two to 13 hours for final processing. -- In addition to the high-resolution final rendering, the RenderFarm was also used to generate the test images animators needed to plan and evaluate lighting, texture mapping and animation. Since fast response is key in doing tests, RenderMan could produce test frames in as little as a few seconds. -- Scalability is built-in: the RenderFarm can be upgraded (with more processors and disk storage) to a nearly four-fold performance level, without requiring any additional space. The RenderFarm also integrates seamlessly with Pixar's existing computer network containing different types of machines. =snip=

1 0

No Subject
by 103155.2774＠compuserve.com 17 Dec '03

17 Dec '03

Hello...i'm new to this, but love it...Tell me how exciting this is!!!!!///

1 0

Re: EXO_ner
by Dave Del Torto 17 Dec '03

17 Dec '03

At 9:34 AM 12/2/95, John Young wrote: >SenXon and The Washrag blow today about which has the most to >be ashamed of and hide from the filthy lingerie leering >republic. Exon, Exoff, XON, X-off, Exxon, ex-off. dave ____________________________________________________________________ "Packwood's supporters were left groping for answers." --news anchor

2 1

Re: Remind me why we're so mad at Netscape
by Bill Stewart 17 Dec '03

17 Dec '03

At 09:33 PM 12/2/95 -0500, Matt Blaze <mab(a)crypto.com> wrote: >Could someone please remind me what it is we're mad at Netscape about? >As far as I can tell it's some combination of the following offenses: > >(a) - Jim Clark made a speech in which he revealed that he thought the >government would be a player in determining the way cryptography ends >up being deployed on the Internet. He was quoted in the trade press, >but it was unclear exactly which words were actually his. Asked to >clarify, he said that Netscape would implement mandatory government >access across its product line only if required to by law, but he >observed that things seem to be moving in that direction. I share his >pessimism, unfortunately, unless we find a way to shift the winds. I give Netscape a lot of credit for the way they've handled things so far; their US commercial version supports strong crypto (modulo a few bugs :-), and interoperates with their free exportable version, which is itself far stronger than a minimal 40-bit version could have been. And they're adding secure email to the new version. And (while they can't officially say this, of course) anybody overseas can pirate the strong-crypto version if 40 bits aren't enough. PGP gave anybody who wanted to do a bit of work the ability to do trusted communications, but it's still not widely used because it does take extra work; the most important things it's done have been to raise public awareness and make it obvious to everybody that the cat's out of the bag, which also pressured the government into dealing with the issue. Netscape is putting built-in strong crypto in the hands of tens of millions of people; fait accompli like that make it much harder for governments to impose stupid and offensive rules. Maybe Netscape will come out with GAKed versions for export to nosy-governmented countries like France and the US; as long as the main version has secure communications, and they're open about how their crypto really works, we can talk securely domestically, and other folks can pirate them to use instead of GAKware. If the government wants to pay extra to support special hardware crypto modules for their own use, and the modules do GAK, that's an internal problem (as long as we can subpoena their records.) Of course, in case the main US versions ever have GAK as a default, I do reserve the right to flame Netscape again :-) >(d) Their stock price is very high, many times greater than their >profits and physical assets would seem to justify. I'm not sure I >understand the implication here. I think it's that "Netscape is now in a financial position that pushes them to care more about making some profits to justify their appallingly high stock price so they're more likely to lose big bucks if they don't sell out, and I should have bought it at $70..." >Disclaimer: I'm employed full time by a soon-to-be-tri-vested major >player in the military industrial complex, and us sellouts like to >stick together. Definitely. Back when I was a tool of the military-industrial complex, I was two floors down from Matt, in an RF-shielded room :-) #-- # Thanks; Bill # Bill Stewart, Freelance Information Architect, stewarts(a)ix.netcom.com # Phone +1-510-247-0663 Pager/Voicemail 1-408-787-1281 # Anybody notice that Microsoft's Wide Open Road ad has barbed-wire fences # on both sides of the road?

1 0

Re: Use of PGP as an export?
by Bill Stewart 17 Dec '03

17 Dec '03

At 09:09 PM 12/2/95 -0800, Ted Cabeen <cabeen(a)netcom.com> wrote: >I think this has been brought up before, but I could only find one reference >to it in the archives and it wasn't too helpful, so I'll ask again. If a >university provided a copy of PGP for use on their unix machines and a >non-resident, non-citizen *used* the copy of PGP on the server, but did not >download it onto their own machine, but instead just ran PGP on the server >alone, would it be a violation of the ITAR? My school is interested in >putting a copy of PGP on the university server and wants to know if they >should somehow restrict access to citizens and legal residents only. Thanks. That's not giving technical data to the foreigner, that's providing a service; the ITAR doesn't seem to restrict that. It's not an especially secure way to operate, but that's an inherent problem with multi-user systems or file servers. One way to implement it that would be only mildly insecure would be to put PGP on a file server, with execute-only permissions; users of client machines still could be attacked by somebody faking out NFS, but they wouldn't have to send their passphrases across the net the way they would in a telnet session. #-- # Thanks; Bill # Bill Stewart, Freelance Information Architect, stewarts(a)ix.netcom.com # Phone +1-510-247-0663 Pager/Voicemail 1-408-787-1281 # Anybody notice that Microsoft's Wide Open Road ad has barbed-wire fences # on both sides of the road?

1 0

Re: Questions/Comments on ecash protocol
by Hal 17 Dec '03

17 Dec '03

From: Ian Goldberg <iang(a)cory.EECS.Berkeley.EDU> > I read these specs for a little while last night. Here are some of my > questions/comments. To prevent this message from becoming huge, I won't > quote much from the protocol document itself; the URL is above if you want it. > I'll ignore the spelling/grammar; they can be fixed later. I was also reading it, and I share some of Ian's questions, but for some things I have a few different guesses. > What is the function f, used in the payment_hdr to hash the payer_code > and desc fields, as well as in WITHDRAW3 to calculate N = f(n) * r**h? > There is reason to believe it is SHA, but I thought I saw some stuff in the > client that indicated that the output of f is 132 _bytes_ long (but I'm > not exceptionally sure of this, not having source and all). One rather cryptic sentence, which Ian alludes to later, relates to cancelling payments: "The 'payer_hash' is the one-way image of a by the payer generated random number...". In the diagram it shows it as f(payer_code), where payer_code is shown as "random code generated by player". (And, as Ian points out later, the document inconsistently says that "the player generated random number" should be kept secret while requiring that it be sent to the shop - at least, this is inconsistent if it refers to payer_code.) Assuming the use of the word "a" is not a typo but refers to some number, this suggests that f() is at least potentially a two-input function, some value a and a player generated random number. > Please clarify what parts of the payment_hdr are shipped around. The document > says that the shop checks if the descr_hash matches the description. > Since the description is in the second part of the payment_hdr, does that > mean that both parts are sent to the shop? Noticing that the payer_code > (which the payer is supposed to keep secret) is in the second part, this > doesn't seem to be right. Also, the document states that the payment hash > is not sent from the payer to the shop or from the shop to the mint. However, > the payment hash is just the SHA of the first part of the payment_hdr, > which _is_ sent around, so although the payment hash isn't transmitted > per se, it can certainly be calculated. It seems that the whole payment_hdr is sent to the shop, and only the portion before the line is sent to the bank. This is enough, as you say, to calculate the payment hash, so the bank can decrypt the coins. This prevents the shop from changing any of the information in that first part of the payment header before sending it to the bank. My question in this part relates to coins made out to "@" which we have been told can be deposited by anyone. How does the bank know to which account to deposit such a coin, given a deposit message? The shop's ID does not seem to be present in such a message, assuming that the shop_accID field of the payment_hdr just has "@" in that case. Is it the userid field in the userhdr message which tells the bank this info? BTW since apparently both deposit and payment messages are not encrypted, coins made out to "@" are in danger of being stolen both while en route from customer to shop and from shop to bank. This is significant from the point of view of payee anonymous systems, which will need to use such coins. More encryption will be necessary when such coins are passed around. > A (very slight) privacy concern: the payer's bank is sent in the clear, > which gives a very small amount of information about the identity of the > payer. More on who knows what later. Well, I would think identification of the payer's bank will be necessary for any coin based system so you know where to cash in the coins, so I don't think this is going to go away. Of course as of now everyone has the same bank so it is not an issue. > Is it in fact the case that all coins on one payment use the same payment hash > when encrypting their signatures (the field sig in onl_coin)? The signatures are xor'd with the payment hash, but this is not the main way they are encrypted - they are then encrypted with the bank's public key. The purpose of this xor is not so much to protect the coins as to bind them unbreakably to the payment header. Since the coins are always sent around with that payment header I think they all do use the same payment hash. > If (M,e) is the mint's public modulus/exponent, and (N,h) is public mod/exp > for a particular coin denomination, are the following statements true: > > o If n is the coin number (in onl_coin, assumedly the same n as used in the > withdraw request), and hdr is the first part of the payment header, > then sig (in onl_coin) equals > > ([ SHA(hdr) XOR ((f(n)^(1/h)) mod N) ] ^ e) mod M I was wondering about this too. There is a reblocking problem in trying to concatentate "pure RSA" operations. In particular M must be at least as big as N. This is not necessarily a problem, but it is a slightly unusual constraint on key creation. However I agree overall that this formula is a reasonable reading of the doc. > o A deposit (which contains a userID in the userhdr, a payment_hdr in > the dep record, and a pair (n,sig) for each coin) is accepted by the bank iff > > ([ SHA(payment_hdr) XOR ((sig^(1/e)) mod M) ] ^ h) mod N = f(n) > > _and_ either payment_hdr.shop_accID corresponds to userID, > or a payer_code is supplied such that > payment_hdr.payer_hash = f(payer_code). There also needs to be some clause for the "@" payee. In that case I think the payment is accepted if the signature checks, with credit to the userID account. That business about cancelling via payer_code I agree is not very sensible. It doesn't seem necessary - the coin can just be re-spent, made out to someone else. > Where is the facility for tracing double spenders? Perhaps it's just > part of the "incomplete" part of the document, but I can't even see > where it would fit in to what we've got; neither the withdrawal nor the > payment messages seem to encode _any_ information about the payer in > the coins, and the bank cannot seem to know who withdrew the coin that > ended up being spent twice (due to the blinding). There is no such thing! This is one of the most common misconceptions. This version of ecash does not trace double spenders. It prevents double spending by checking each coin to make sure it has not already been spent. Tracing of double spending is only necessary in offline systems where coins are not checked right away, but that is not present here. > Is there a way to change the public key associated with an account? > Is it just a meeter of sending another OPENACC1 message? My guess is there would need to be some manual intervention to do this. > Exactly what kind of anonymity/privacy/security does ecash offer? > Let's examine who knows what. > [...] > If Eve or Mitch can determine either r (the blinding factor) used in > the withdrawal, or the payer_code, used in the payment, they can steal the > money. This has ramifications to Doug's "agnostic" banks; more security > has to be added to the present ecash system if unblinded withdrawals are > allowed. This also brings up the "Netscape" question: how are these numbers > generated? Does it have to do with that 25 character string you enter > at the beginning? I've noticed a bit in the program that seeds a RNG with > (time(0) ^ ((getpid()<<16)|getuid())). I think publication of _at least_ > the code pertaining to blinding factor and payer_code generation is > _absolutely vital_. Well, as I said, I think this payer_code business is pretty questionable. I'm sure the next version of the doc will clear that up a great deal. As far as determining r, that is not possible from the protocol messages. Chaum has proven that it is absolutely indeterminate. So I don't understand what you mean about "more security has to be added to the present ecash system if unblinded withdrawals are allowed." Do you just mean that the coin messages should not be sent in the clear in that case? I observed that coin withdrawal messages can be sent in the clear in some postings I made last year - the use of r effectively encrypts them. But of course that can't be done with unblinded messages. There have been claims that the long string you type in at startup time deterministically seeds the RNG, so that if you lose your wallet but you tell DigiCash this string (via some secure channel, presumably) they can reconstruct the coins you should have. Presumably they could figure out what the r values were when you withdrew all your coins, reconstruct the coin numbers, and see which ones haven't been spent. This is both good and bad, in that it provides a well understood amount of entropy (rather than relying on whatever it can scrounge up), but of course is vulnerable to lazy typing. Also, you have to write down the string, and if someone found this they could perhaps get your coins. > I think I'll stop here; comments from anyone, and especially answers to my > questions from DigiCash people, are welcome. I'm sorry if it's not as > complete as you (or I) would like; I'm quite tired, as my building had > two fire alarms in a row at 3am this morning... > > - Ian "Well, it's a start..." Very good comments. I'm sure the next version will be much better if they are careful to clear up the kinds of issues you have raised. Hal

1 0

Questions
by rmarquis＠umich.edu 17 Dec '03

17 Dec '03

Hello. I was wondering if anyone would be able to help me out. I am writing a research paper and I need some interviews for it. If you could answer any of these questions about security, I would greatly appreciate it. Thanks for your time. --Bob Marquis Please send responses to rmarquis(a)umich.edu - How can PGP help secure something like e-mail? - Are there any encryption schemes which are "unbreakable"? - What would someone need to do to send an e-mail message which cannot be read or altered by anyone else, or is it not possible? ____________________________________________ Robert Marquis, Jr. University of Michigan - Dearborn e-mail: rmarquis(a)umich.edu www: http://www.umd.umich.edu/~rmarquis

2 1

Re: The future will be easy to use
by ahupp＠primenet.com 17 Dec '03

17 Dec '03

>That's today's method, more or less. It doesn't address my needs. The >name you pick for your key may or may not mean anything to me. It might be >pronounceable, giving it some advantage over a radix-64 string, but it >might also be non-unique, making it worthless as an identifier. > >What means something to me is whatever name (or symbol) I assign to the >person behind the key in question. That's the one in my mind and therefore >the only one of interest to me. You, however, don't know what's in my >mind. You don't even know my preferred symbol set. > Why not give it two names? A local name that could be a icon or something, and a universal name (i.e. MD5 hash of key) -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6 mQBtAzCNppQAAAEDALhWZl7IuGZ9zZT5bACo0b/1L0Nv0C72vKHIO3IHh+cwpHHa 2Ozb9aeO0UvXGwkkZIYgUm0EvmzKh7yb1GTLvBp5kXpR3I9w+Yj4LGlBDERpUWw6 x4ED49pwDnz1Hl5FBQAFEbQYYXNoIDxhaHVwcEBwcmltZW5ldC5jb20+ =PtJK -----END PGP PUBLIC KEY BLOCK-----

1 0