December 2003 - cypherpunks-legacy

Re:Internet Stocks
by tcmay＠got.net 17 Dec '03

17 Dec '03

At 4:45 PM 12/8/95, Ashfaq Rasheed wrote: >Can this be made a regular feature on the list? It will be helpful to >discuss on the Internet companies are doing in the stock market. > >Also it would be interesting to see if any startups have a strong product to >survive in the market It won't be a regular feature by me, that's for sure! What others write is of course up to them. As I said in my message, I'd gotten some queries in e-mail, enough to indicate justification for one public message summarizing a bunch of points. Especially seeing as how these stocks have been very much in the news this week, and have been discussed on the list. But this is not "StockPunks," so I don't plan to comment unless something important comes up. Investors (and speculators) are well-served by various news sources, including the "Wall Street Journal," which also carries at least one great article per day, and sometimes even two. A bonus URL for you folks: http://www.ai.mit.edu/stocks.html --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

Re: More FUD from First Virtual
by jim bell 17 Dec '03

17 Dec '03

At 06:51 AM 12/8/95 -0500, you wrote: >Excerpts from mail.limbo: 7-Dec-95 More FUD from First Virtual Douglas >Barnes@communiti (1157*) > >I *am* skeptical about the extent to which anonymous cash *can* succeed, What can stop it? What should stop it? >but in point of fact I'd like to help. I think society will be better >off if one of the payment options is truly anonymous. I think that >level of privacy will inevitably carry a high surcharge, however, for >reasons that I keep pointing out and you keep ignoring. Well, maybe I haven't been following those reasons, but I see little or no reason privacy should "inevitably carry a high surcharge." If the relevant encryptions had to be carried out with a pencil and a piece of paper, that claim would make sense, but remember, we've got MICROPROCESSORS on our side! I agree, I suppose, that there are definitely entities (read: governments) which would WANT to prevent the use of anonymous cash, but I view them more of an obstacle to be removed than a permanent bar.

3 2

GAK and Self-Incrimination?
by tcmay＠got.net 17 Dec '03

17 Dec '03

Duncan Frissell wrote: >At 09:17 AM 12/8/95 -0500, Adam Shostack wrote: > >> "Your honor, we argue that in escrowing his keys with the US >>government, the defendant should have known his communications could >>be listened to, and thus has no expectation of privacy." > >If Clipper were mandated you might be able to resist a prosecution for >"failure to file" keys or for double encrypting your transmissions if you >could prove that you were transmitting illegal messages or evidence of a >crime. Just as those who possess illegal weapons are not required to >register them (self incrimination). You have to be sure your traffic is >illegal though otherwise no protection. Though I'm usually not too interested in smart-ass, overly cute, interpretations of legal loopholes--having been burned by the tax protestor arguments that the tax system is invalid because of definitions of money or that Ohio never entered the Union legally, or somesuch--this whole escrow thing has got me thinking. Given that GAK means one never knows if the government is listening, could a person claim protection against self-incrimination as a reason to not use GAK, and get away with it? (This is different from the phone system, which may also be tapped. The analogy would be the same if the government forced one to pick a telephone it could tap over one it could not, which so far has not been the case, but which soon may be if switching systems which are not compliant with Digital Telephony Act provisions are shut down.) Consider this hypo: I send an encrypted message to a partner in crime containing plans for future crimes and descriptions of past crimes. I don't GAK the message. The government prosecutes me under the Anti-Terrorism and Child Protection Act of 1997. My defense? That GAKKing the message would be tantamount to incriminating myself, which the Fifth Amendment protects me against. (The government might claim that this "tantamount" conclusion is specious, that only with a valid court order could they open my traffic. I would claim that this is suspect, citing the secret court (FISA) provisions, the possible back doors in GAK (64 bits known to be breakable, according to Clint Brooks of the government), and the general confusion about whether opening one message exposes past traffic to reading. I think my lawyers could make a convincing case that GAK will mean my words may be read by the government, via multiple options.) Comments? --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

Re: Still more on the Digicash protocol
by Mark Twain Ecash Support 17 Dec '03

17 Dec '03

At 07:17 PM 12/7/95 -0500, you wrote: >Assume the attacker is not doing any traffic analysis. The problem is >that even then, the shop's identity (and product info, and payment amount, >and bank ID, etc.) are still sent *in the clear* in the Digicash payment >protocol. Thus all those items can be correlated to the payee's identity: >a complete loss of privacy for the shop. > >There's no need to send that payment info in the clear -- why not encrypt? DigiCash agrees that it is desirable to encrypt the payment request. The problem is how? You can't use the payor's public key, since the payor is anonymous to the payee. There are other, high overhead, protocols that might be used, but after taking MIM into account, securing the payment request from within Ecash while retaining acceptable latency is much harder to acomplish than one might think. The best solution at this time seems to be to use the already existing https connection to transmit the payment request. The next version of Ecash will offer this feature as an option to the user. --Mark Twain Bank Ecash Support Ecash. The secure Internet payment system that protects your privacy. <http://www.marktwain.com/ecash.html>

1 0

Anyone know of a white paper on security?
by John Fricker 17 Dec '03

17 Dec '03

The question I'm seeking to answer is : What criteria should be used to determine whether a scripting language such as Java, LiveScript, etc. is secure? There are obvious issues such as access to the file system but has anyone thought this all the way through and codified a white paper? john.

2 1

The Elevator Problem
by Jerry Whiting 17 Dec '03

17 Dec '03

A group of us have been wrestling with a problem and I'd like to ask for some outside help. We've come to call it the Elevator Problem. Alice and Bob want to establish a secret in from of Eve. In other words, they want to agree on a secret key in an elevator full of Eve's. We don't want the protocol to step on any existing patents (DH, HM, etc.). If the protocol takes numerous steps, that's OK because ultimately we'd like Alice's machine to contact Bob's, who could respond, and back and forth as often as needed. We have also talked about a less than perfect solution IF we can establish mathmatically what the confidence level and risk factor are. Alice and Bob might agree that the value of the secret is such that they can live with a 1 in n probability that Eve too has the secret. Shamir's 3 step seems close but I'm afraid we've been doing the blackboard talks so long that we're missing the solution. IF THERE EVEN IS ONE. thanks in advance, Jerry Whiting jwhiting(a)azalea.com

1 0

Re: DigiCash releases protocol specs!
by Andrew Loewenstern 17 Dec '03

17 Dec '03

> By popular request, DigiCash is releasing the protocol specs. Three cheers to DigiCash, Mark Twain, and Lucky! andrew

2 1

Re: More FUD from First Virtual
by cman＠communities.com 17 Dec '03

17 Dec '03

[Remainder of Nat's largely inaccurate rant deleted] > But basically, what your argument comes down to is that in >the event of a catastrophe, users can be told they have to sacrifice >their anonymity if they want to keep their cash. As I have said all >along, the basic tradeoff is between anonymity and risk limitation in >the event of disaster recovery. NB's errors and distortions are numerous, but for the sake of brevity and topicality I've chosen this particular misconstruction of what I've written as an exemplar. In my proposed approach, users don't sacrifice one iota of privacy when redeeming expired cash. When the user reveals blinding factors on unspent cash, the bank gives the user new (blinded) cash in exchange. No payer-payee relationship is revealed. This is the same wrong argument you've made before. Try reading the (very short) note; this point is made explicitly. I have no clue what Digicash is actually doing in this regard, but one of their engineers alluded to something along these lines at Crypto. It is this systematic distortion of truth by at least two representatives of First Virtual that has lead to this (highly intermittent) "vendetta". I try not to feed the energy creatures, but this particular creature and his minions are literally running around the country, spewing their lies whenever they get the chance. When they slam cryptography in the banking community, you can be assured they don't mention their charity work for Phil, or how they really want to see anonymous systems some day.

1 0

Re: Still more on the Digicash protocol
by frantz＠netcom.com 17 Dec '03

17 Dec '03

At 12:26 12/8/95 -0600, Mark Twain Ecash Support wrote: >DigiCash agrees that it is desirable to encrypt the payment request. The >problem is how? You can't use the payor's public key, since the payor is >anonymous to the payee. There are other, high overhead, protocols that might >be used, but after taking MIM into account, securing the payment request >from within Ecash while retaining acceptable latency is much harder to >acomplish than one might think. Wouldn't a Diffie-Hellman key exchange work here? Or is that too much overhead? ----------------------------------------------------------------- Bill Frantz Periwinkle -- Computer Consulting (408)356-8506 16345 Englewood Ave. frantz(a)netcom.com Los Gatos, CA 95032, USA

1 0

"Information Technology for Control of Money Laundering"
by Michael Pierson 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- I've just finished perusing the Office of Technology Assessment's "Information Technology for Control of Money Laundering" <ftp://otabbs.ota.gov/pub/pdf/money.laundering/*.pdf>. It's an informative and fascinating document for anyone interested in the issues of money laundering and its implications for the future of digital currency, as well as its increasing role as an important rationale in promoting government surveillance agendas. Broken into seven chapters, this document provides a valuable overview of the subject from the government's perspective. 1. "Electronic Money Laundering" covers the ABCs of money laundering and its connection to drug trafficking, terrorism and the global underground economy. It traces the relevant statutory history from the Bank Secrecy Act of 1970 onward. 2. "Mechanisms of Wire Transfer" examines the basics of wire transfers and the details of the FEDWIRE, CHIPS and SWIFT systems. 3. "Money Laundering and Law Enforcement" examines the laws and regulations involved and the various Federal and State Agency roles and responsibilities. 4. "Technologies for Detecting Money Laundering" is particularly interesting. It discusses the FinCEN Artificial Intelligence System (FAIS), and AI approaches including Expert Systems, Link Analysis, Neural Network techniques, Machine Learning and various statistical modeling methods. 5. "Privacy and Confidentiality" covers different investigative prerogatives, the legal history and case law of privacy jurisprudence, aspects of individual and corporate confidentiality, etc... 6. "International Issues" explores off-shore banking, international law enforcement efforts like the Financial Action Task Force (FATF) and the subject of bilateral and multilateral cooperative agreements and conventions. 7. "Conclusions and Policy Options" discusses money laundering and the world economy, and various policy directions for the future as well as the type of monitoring regimes that might be established. It pays particular attention to the subject of the future impact of digital money, observing: "As alternative modes of electronic payment, e.g., "digital cash", develop, whatever precedents are set for access to wire transfers might also be applied to these alternatives. If not, digital cash, or "the electronic purse" may provide another channel for dirty money, so that monitoring of wire transfers will no longer be effective." I noticed that major network news reports on the "growing threat" of money laundering were particularly evident in close temporal conjunction to the wide public coverage of the latest FBI CALEA revelations. Just coincidence, I guess... Bonus: While your there you might want to (if you haven't yet) pick up another OTA document entitled "Electronic Surveillance in a Digital Age" which provides some useful additional government position tracking data on the legal and technical aspects of CALEA. It's available in both text <ftp://otabbs.ota.gov/pub/elec.surveil/*.txt> and PDF <ftp://otabbs.ota.gov/pub/pdf/elec.surveil/*.pdf> formats. - -Michael -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMMidCtGJlWF+GPx9AQGROQP+KtumqozBLlFgupOCcoKRIk6udFz0jRt4 Vt1y1noiV0tJCE2XQdEGiU7KhRHDC8QX+Zi1wxVqnlhxNI8hF5g4nDGf+DHyw54r KsXce7fJvPVZ3dn69dYIQ70gpa6BfAvsFXGAP9gnL3RxnxxYGfBknp2xdz0SiBQv t0bnWwIab68= =bWRK -----END PGP SIGNATURE-----

1 0