December 2003 - cypherpunks-legacy

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

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

ANNOUNCE: NOISE.SYS random sampling device for DOS v0.2Beta
by wlkngowl＠unix.asb.com 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Re: NOISE.SYS Random Sampling Device Driver for DOS (v0.2-Beta): I've finally gotten a usable version of NOISE.SYS written. The beta is ready for semi-public release and review. If you're interested in testing it or examing the code, email me at <wlkngowl(a)unix.asb.com> It's only a prototype version. I do not know any strong methods of testing random data. If anyone is willing to help on that part or point me in the right direction, it would be appreciated... What this driver does: When loaded, it hooks onto the keyboard interrupt (0x09) and collected fast timings between keystrokes. It can also be easily configured at compilation to sample other interrupts, as well as collect "seedling" keystrokes upon initialization. It sets up a character device called RANDOM, that when polled takes the earliest collected bytes from the random pool (size can be adjusted), combines them with a count-word based on the number of samples collected plus the number of times the driver has fetched data from the pool, transforms it using the Secure Hash algorithm, and outputs the bits from the hash. It's only a prototype: this version doesn't check to see if the pool is "empty" at the moment. Features: written in 386 assembler, takes under 2k of memory and can be loaded from the command line using a utility like DEVLOD. Also under GPL, so you've got the source-code to play with. Comments and criticism from crypto-gurus would be greatly appreciated. Reply if you'd like me to send a copy. (Important Q: is this software covered under ITAR?!?) - --Rob <wlkngowl(a)unix.asb.com> -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMOL8gNscUKerH0gxAQHNlAP/eZChSaAEg3go/vxfm9Z0Af5Dfa4WBDhh SfbbpsYfymSkxFbU7bHUfRMFHk+Uy57AeGMUxXkgml7KO8cxyOPS6yVDcNWf6Z9W OeXtXRAFBWRn3CblT1sQzl5YCEG93YBZS9ZkbTsN4rgTcpo15QY8vG5BJCEgfP9f 9XHn5VGSkVo= =jaNN -----END PGP SIGNATURE-----

1 0