December 2003 - cypherpunks-legacy

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

Re: More FUD from First Virtual
by Duncan Frissell 17 Dec '03

17 Dec '03

At 02:52 PM 12/8/95 -0500, Jon Cooper wrote: > The US government can stop it. It is irrelevant what *should* stop >it, but it's extremely useful to note that the US government's political >climate of paranoia and FUD in general will certainly not allow truly >anonymous cash systems inside of our country in the forseeable future. But who's going to ask? If an anonymous payment system springs up outside the US, we can use it as a store of value if nothing else or for shopping overseas. Domestically, we can convert non-anonymous payment systems into semi-anonymous ones. What counts is difficulty of transaction and market demand not legal structure. Thus, about five minutes after the "temporary VISA card" travelers check substitutes are issued, I can start selling them for (discounted) cash to all comers. Likewise Ecash laundry servers letting anonymous people use non-anonymous Ecash. It remains to be seen how much customers value anonymity. There should be a niche market in any case. DCF "Every man his own ISP."

1 0

Re: PRIVACY: Private traces in public places
by tbyfield＠panix.com 17 Dec '03

17 Dec '03

At 10:26 PM 1/9/96, Alexander 'Sasha' Chislenko wrote: >- Landfills: They are probably the richest source of detailed historical >information > that is not obtainable from any other source and can be used to reconstruct > the detailed history of society, economy, technology and any single >person with > incredible detail. I ain't holding my breath until someone develops a search engine for Fresh Kills. Ted

1 0

Re: A couple of ideas for PGP-based programs
by Bill Stewart 17 Dec '03

17 Dec '03

At 02:32 AM 1/6/96 -0800, Alan Olsen <alano(a)teleport.com> wrote: >1) Something I would like to see on the keyservers for PGP is a way of >retreving all of the key revokations since x date without having to get all of >the keys since that date. The web interface to the MIT keyserver lets you search for keys, and probably some of the other interfaces do too. So do a retrieve on REVOKE, snarf the output, and feed it to perl or grep or something. PGP keyserver >2) I would like to see a program like private Idaho have the ability to send >mail to the key server and grab all of the "unknown signator" keys. This would >have the interesting effect of building a more complete keyring, while using >the "web of trust" to weed out alot of the bogus keys that tend to crop up on >the key servers. I found that a very convenient way to add things to my keyring was to use the keyserver web page and Private Idaho simultaneously. Grab the keys you want on the keyserver, cut+paste into Private Idaho, decrypt (PGP won't find a message, but will find keys), and click on anything you don't recognize. Parsing email isn't too tough, but it takes some work, and it's easier for PC tools to interact through Netscape or finger when they can instead. > After n number of iterations you would have more of the >"important keys" n=4 is an interesting depth, given PGP's default settings..... #-- # Thanks; Bill # Bill Stewart, stewarts(a)ix.netcom.com, Pager/Voicemail 1-408-787-1281 # # "The price of liberty is eternal vigilance" used to mean us watching # the government, not the other way around....

1 0

Re: Revocation, Trust, Policy Models, etc.
by Bill Stewart 17 Dec '03

17 Dec '03

>>The question is: is there a "majority vote" mode on the keyservers that >>causes them to remove a key if enough people claim it is no longer valid? No - it's too easy to attack. (It's also outside the scope of what the keyservers do - they're convenient ways to collect the data for the Web of Trust, but they're not trusted themselves.) Even if you wanted "A majority vote of people who've signed a given key" to revoke the key, that's easy to attack - you and your tentacles can all sign the victim's key, send the signatures to the keyservers, and now that you're the majority, you can all send in notes saying "please revoke victim(a)antinuke.org's key - he's an FBI plant". I'm not really satisfied with Matt's description of revocation that requires it to be done by a key's signers, not owner, though there are workarounds for most of the problems, though I agree that PGP's framework is deficient (not inadequate - it's still Pretty Good - but way underpowered.) One problem is that usually _you_ are the one who knows your key needs revoking (either you forgot the passphrase, or you know the computer it was on has been compromised, or whatever.) Under PolicyMaker, I guess the best way to implement this is to always sign your own key (since signers are the ones who revoke keys), and establish policies requiring unrevoked self-signatures. It may be difficult to implement Certificate Revocation Lists in a way that works well for your own keys, though, depending on why you want to revoke them. #-- # Thanks; Bill # Bill Stewart, stewarts(a)ix.netcom.com, Pager/Voicemail 1-408-787-1281 # # "The price of liberty is eternal vigilance" used to mean us watching # the government, not the other way around....

1 0