December 2003 - cypherpunks-legacy

Re: digital cash and identity disclosure
by tcmay＠got.net 17 Dec '03

17 Dec '03

At 7:48 PM 10/19/95, Bryce wrote: >-----BEGIN PGP SIGNED MESSAGE----- > > Someone claiming to be the nym calling itself tcmay(a)got.net (Timothy C. >May) wrote: >> >> As Hal notes, there are a lot of issues and attacks to consider. I'm sorry >> that my brief section on Chaumian digital cash in the Cyphernomicon doesn't >> adequately cover the issues (and as the debates here show, confusion still >> reigns, and no doubt some of my points are misleading, wrong, or >> incomplete). > > >Boy, if I were you I would want to fix the inadequacy in C'nomicon in >order to protect my positive rep... To each their own. There's not enough time in my life to fix all the things that are wrong, even if I knew what they all were. My "positive rep," such as it is with certain people, does not depend on producing flawless documents. In fact, there are different kinds of people. Some favor "closely reasoned" arguments (A implies B implies C implies D....), some favor "imaginative leaps." Where I am depends on my mood. - >> it tends to make >> identity-revealing attacks possible (such as the attack I alluded to, and >> that Hal more completely describes), > > >I hesitate to pipe up in such august company, but one of us is >confused. The attack that we have been discussing is possible because >Chaumian Ecash allows the payer to identify the payee. This would be >true whether or not there were any protocols related to >double-spending. (i.e., because the payer knows the actual ID number >of the bill, she can choose to relate it to the bank and then the bank >can identify who turns in that bill. Has nothing to do with >double-spending. If the protocol provided for re-blinding before >depositing the bill then this would not be possible, I think, and >would still have nothing to do with double-spending.) Oh, but it does. Suppose Alice pays out the same piece of digital cash to Bob, Charles, Ellen, Dave, etc. Each thinks they've been paid, each gets to the bank, each finds the bank will not honor the digital cash, as Alice has double spent. (Note: Any schemes for "re-blinding" must still allow "uniqueness"...and must still point back to Alice. Else the scheme/scam above will work. Online clearing, in which only the _first_ to present a digital cash claim gets paid, does not have this problem.) >Announcement: I'm about to fade out from c'punks list for a while, so >be sure and Cc: me if you want me to see your post. I will this time, but people generally should not expect out-of-band cc:ings. --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."

2 1

Re: SciAm Bye-Byes Privacy
by Duncan Frissell 17 Dec '03

17 Dec '03

>Scientific American, November, 1995 > >Rights of Privacy > >Technology has its eyes on you > >But the search for personalization in a high-tech world >may create an uncomfortable situation in the global >village. Villages are safe places but not very private >ones. Mrs. Grundy, peering from behind her lace curtains, >did stop housebreakers. but she also tried to halt many >other things of which she disapproved. There are signs >that Grundyism is returning to Britain. For those who have neglected their education: 1798 Theater --- "Speed the Plough" by English playwright Thomas Morton, 34. "Be quiet, wull ye [says farmer Ashfield]. Always ding, dinging Dame Grundy into my ears-What will Mrs. Grundy say? What will Mrs. Grundy think?" DCF

1 0

Re: Netscape rewards are an insult [NOISE]
by Richard.Johnson＠Colorado.EDU 17 Dec '03

17 Dec '03

Jeff Weinstein wrote: >John Young wrote: >> >> Responding to msg by stripes(a)va.pubnix.com ("Josh M. Osborne") >> on Sun, 15 Oct 12:0 AM >> >> The PR of Bugs Bounty is the aim, as the quick-market-adapter >> Netscape Chair speechified in FR. >> >> Promoting the notion that hackers are earnestly attacking >> Netscape and reporting its bugs increases its credibility to >> the stock market porkers. Is that not why dear >> all-too-attentive Jeff has been assigned duty on this list, >> feeding peanuts to chimp hackers and champ newshacks? > > I have not been "assigned duty" on this list. I'm here of my >own free will. I want to keep up on whats going on in the >cypherpunk world, and sometimes tap the expertise of the list. >I'm not some corporate flack assigned here to "feed the chimps". >My personal feelings definitely lean toward unimpeded strong >crypto, personal privacy, freedom from govt. surveilence, etc., >and I was interested in this stuff at a personal level before >joining netscape, or working on security stuff. > > --Jeff So a reviewer stepped in and accused the rock star of having "sold out"... Does working as a programmer for a "major label" on a top-40 hit mean you're not true to your artistic roots any more? Or does "working within the system" permanently disqualify you from rebel/outcast status? OK, sorry, enough of the cliches. :-) Richard

1 0

Re: REMINDER: SF Federal Building, Oct 20, 1015AM: Bernstein case
by Duncan Frissell 17 Dec '03

17 Dec '03

At 01:02 PM 10/19/95 -0400, Thomas Grant Edwards wrote: >Q: Will they allow CU-SeeMe in the courtroom? (over Metricom radio modem?) > >-Thomas > No cameras allowed in federal courtrooms. DCF

1 0

Re: [NOISE] Re: Postscript in Netscape
by patrick＠Verity.COM 17 Dec '03

17 Dec '03

Please stop dinging Dr. Fred on the list, I know he's brought it on himself, but it's painful to watch and pretty juvenile. It's also bring the signal to noise ratio on this list way down. Patrick _______________________________________________________________________ / These opinions are mine, and not Verity's (except by coincidence;). \ | (\ | | Patrick J. Horgan Verity Inc. \\ Have | | patrick(a)verity.com 1550 Plymouth Street \\ _ Sword | | Phone : (415)960-7600 Mountain View \\/ Will | | FAX : (415)960-7750 California 94303 _/\\ Travel | \___________________________________________________________\)__________/

1 0

Re: DalSemi: Add-Only Memory for Storage of Digital Cash (fwd)
by Dave Emery 17 Dec '03

17 Dec '03

Forwarded message:

1 0

Java power
by Raph Levien 17 Dec '03

17 Dec '03

At the recent cypherpunks meeting about Java, I was fairly skeptical of its power, especially its ability to do anything useful towards interesting cypherpunk projects. I've been thinking about it a bit more, and I believe I was overly pessimistic. My thinking problem was that I was envisioning Java as a replacement for ordinary HTTP server interaction (such as CGI scripts). I still believe that, absent HTTP server interaction, Java applets are quite limited. However, now that I've started thinking about systems that are built using a combination of Java and servers, the universe has expanded a lot. I'm still unclear about the exact security policy implemented by Java browsers, but this is my understanding: * No access to local files at all. * Can only access URLs on same server as applet came from. Actually, I'm pretty sure the latter is an oversimplification, that the applet can contact any socket as long as it is on the same IP host as the applet itself. However, since HTTP can do pretty much anything any other socket can, the only difference that makes is performance. Here's the "big insight" I had: the server can make up _both_ of these deficiencies, by acting as a file server and communications proxy. Essentially what this architecture does is shift the security burden from the client to the server. In this way, the applet can become "net complete," rather than merely Turing complete. I see one big drawback to this approach. Setting up a server like this is pretty expensive, and using it takes up precious resources. Not everyone has access to a fully scriptable server, which will limit a lot of people. One concern is the "parasitic" use of file system resources on the server. However, there may be a certain amount of security through obscurity that makes this ok. If all Java browsers enforce the policy of only allowing connections to the home host of the applet, then you won't be getting connections from other, parasitic applets. The remaining danger is rogue Java browsers, and non-Java applications that talk to the server, pretending to be Java applets. Some form of authentication could be used to reduce the impact of these attacks. I do see this kind of architecture used to supply services at, say, an organizational level. For example, the "scheduling" scenario could be implemented quite handily, including authentication of access to the schedules, and even distributed scheduling if the different servers are talking to each other. Another scenario which works is email, even including transparent encryption. This one is interesting to me, so I'll go into a little more detail. In this scenario, the server acts as a file server for keyrings (both public and secret) and mail spools. Here's a typical sequence of events for me getting my mail and replying to one message: 1. I call up the JavaMail web page, which is just a wrapper for the JavaMail applet. 2. The JavaMail applet starts with a forms-style login screen. I type my username. 3. The applet asks the server for my mail spool (given the username and perhaps also a password for authentication). 4. The applet displays my mail spool on the screen and lets me fiddle with it, scrolling through it, reading messages, etc. 5. Let's say one of those messages is encrypted with my public key. The applet, recognizing that fact, queries the server for my secret key, encrypted of course (with a symmetric cypher). 6. I type my password to the applet, which lets it decrypt the secret key. 7. Now, that it has my secret key, the applet can RSA-decrypt the encrypted mail and show it to me. 8. I want to reply to the message, so I hit 'r'. The applet gives me a window for typing my reply. When I'm done, I click "send". The applet queries the server for the recipient's public key. 9. When the applet gets the public key, it RSA-encrypts the message and sends it to the server for delivery. 10. When the mail has been delivered, the server notifies the applet of the fact. To me, this is an exciting scenario. Note that, as long as you trust the browser, this lets you read your mail from anywhere. I have no idea whether this scheme is practical. One temporary drawback is the speed of RSA operations. However, this will get fixed when there is native code generation or a bignum library, whichever comes first. Even before then, performance can still be good, using two techniques. First, implement a cache of decrypted session keys (also stored on the server in symmetrically encrypted form). Second, don't display a new email message until it's been decrypted. That way, the RSA operation affects only the latency of mail delivery, not the bandwidth of reading through messages. Of course, these techniques will also dramatically improve performance even for native code crypto. I can see people setting up servers like this for themselves. However, here's an idea on how to set these servers up "for profit." In return for providing file system and mail communications services, the server would expect clients to search keyspaces during idle cycles. When Java goes native code, the computing power thus tapped could be quite substantial. I'm interested to hear what people think about these proposals. Is this something that cypherpunks should be doing full steam ahead? Raph

2 2

PGPfone and (?) boxes
by Alan Patterson 17 Dec '03

17 Dec '03

A couple of months ago, the release of PGPfone got the list started on hardware alternatives to PTN encryption... An associate of mine recently returned from the Consumer Electronics show in Hong Kong and broght me a lot of stuff including a flyer for a telephone scrambler. >From the flyer: Secure your telephone conversations through high-tech scrambling. Never again be concerned with eavesdroppers! Description: With our state of the art Telephone Scrambler you can now discuss confidential business and/or personal matters over the public telephone network without worrying about eavesdroppers. This compact and easy to install unit renders taps and monitors useless by way of rolling code encryption. Eavesdroppers will hear nothing but gibberish, ensuring complete privacy for all your telephone conversations. The Telephone Scrambler allows you to set your own unique code ensuring that only you and the party that you are speaking with can decode the conversation. Two units are required -- one for each end of the conversation. Features: o One-touch scrambling o Thousands of key combinations o "Rollig code" scrambling o Works with Tone or Pulse o Easy connection o LED display o FCC registered o Compact and Portable Specifications: Power: 12 VDC Dimensions: 5 1/2" X 3" X 1" Weight: 6 oz PTN Connection: USOC TJ-11C Keys: 2^12 Company is: P3 Personal Protection Products 405 Park Avenue New York, NY 10022 (212) 421-4757 (212) 421-5024 Fax Well, in itself it isn't very impressive. However, I plan on giving them a call tomorrow and check prices. If they aren't that bad I'll get one and pull it apart. Perhaps it can be at least reprogrammed for more keys and another encryption algo. Hell, at 2^12 keys, all it takes is a few seconds to find which one the conversation is using. Alan Patterson (lep(a)wsnet.com) Fngpt: 41D0F61B496FECC09FABECF686AB2A1C WSNetwork Communications Services, Inc. PGP Encrypted Email Preferred Montgomery, Alabama (334) 263-5505 (800) INET-750 Public Key @ MIT keyserver

1 0

Re: The NSA Visits Compendium
by daw＠quito.CS.Berkeley.EDU 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- In article <Pine.SOL.3.91.951017102059.25411F-100000(a)eagle.nexor.co.uk>, Andy Brown <asb(a)nexor.co.uk> wrote: > On Mon, 16 Oct 1995, Peter Wayner wrote: > > > [...] > > The most interesting thing that he mentioned was thatthe company had to > > guarantee that the data would never be encrypted sequentially by two > > _different_ algorithms. Apparently double encryption by 40-bit RC-4 was > > okay, but using different algorithms was verboten. > > Very interesting indeed. With RC4 the bulk of the time is in key setup, > so if they could do two setups in parallel then the total time to search > a double-encrypted 40 bit keyspace would not be that great. > Hold on -- was the NSA rep talking about double encryption *with two different independent keys*, or talking about double encryption with the same key? Somehow I doubt the latter: for starters, double encryption with the same key with a stream cipher is generally a Bad Idea. (Remember Robert Morris's suggestion to ``always look for plaintext?'') <grin> In any event, double encryption with the same key is never gonna be much more secure than single encryption, because it doesn't increase the key space. But if the NSA ref was allowing RC4 double encryption *with two different independent secret keys*, then this *is* interesting! There are well-known meet-in-the-middle attacks on double encryption (with independent keys); but the standard one requires lots of storage (2^40 storage -- this can't be precomputed if you use 88 extra non-secret salt bits in the key like SSL); a less well-known more recent attack doesn't need the storage, but takes a bit longer (probably a few hundred times longer) than brute force search of single encryption. van Oorschot & Wiener have a paper on this subject. So did you use a SSL-like construction with lots of non-secret salt bits in the key? If not, then the 2^40 bytes of storage could be precomputed, and I'd guess that this NSA position might mean that the NSA has some Exabytes full of precomputed RC4 output for all possible 40 bit keys. :-) Curious, Dave Wagner - --- [This message has been signed by an auto-signing service. A valid signature means only that it has been received at the address corresponding to the signature and forwarded.] -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Gratis auto-signing service iQBEAwUBMIbr9SoZzwIn1bdtAQGWOAF0DdBaTogLiH0QDSxjAI8iGeiXFLnPg8pT 2H0cv6rcSSo+23lqB3zZw3UP4uHGeZk= =3KwF -----END PGP SIGNATURE-----

1 0

Re: airport security
by Dan Veeneman 17 Dec '03

17 Dec '03

"Bob Bruen, MIT Lab for Nuclear Science" <BRUEN(a)mitlns.mit.edu> writes: > Without actually agreeing with the FAA, the reason you can't have a name > other than your own on your ticket, as well as why you are required to > be in your assigned seat on take-off and landing is because if there is > a plane crash, they need to be able to identify an otherwise difficult > to identify body. This is *not* how crash victim identification is done. The FAR requirement is only that passengers be _seated_ during takeoff and landing, not that they be seated "where they're supposed to be." In fact, many airlines do not assign seats at all. First come first serve for airlines like Southwest, ValuJet, Western Pacific, etc. Actual victim identification varies from mundane (do they have a wallet on their person, etc.) to rather more gristly methods. > Sorry about this, Don't be sorry. > Bob Dan -- system(a)decode.com (Dan Veeneman) Cryptography, Security, Privacy BBS +1 410 730 6734 Data/FAX

1 0