- cypherpunks-legacy - lists.cpunks.org

RE: (cpx) Digicash tagged with payee?
by ljo＠ausys.se 17 Dec '03

17 Dec '03

Hal Finney <hfinney(a)shell.portal.com> writes: >I have heard it claimed that when you make a payment with Digicash ecash, >the identity of the payee is encoded or embedded into the cash somehow. >This is an anti-theft measure (among other things, perhaps). The bank >checks that the embedded identity in deposited cash matches the account >name which is doing the deposit. Where have you heard that? Everything I've heard from DigiCash seems to indicate that no such "payee encoding" is performed. >My question is, how could this be done? How can the payor, at payment >time, without communicating with the bank, embed a payee name >irreversibly into the cash so that a thief cannot strip it out and >replace it with his own name? It is possible though with other (teoretical) protocols, such as Chaum, Fiat and Naor's off-line cash scheme (briefly described in Schneirer's book 'Applied Cryptography') and especially the (off-line) cash system, developed by Stefan Brands. In these systems, when Alice spends a coin at Bob's shop she has to respond to a random challenge, sent to her by Bob. This random challenge could possibly be a hash of Bob's identity and some other values. My impression though is that this is not a feature of the current implementation of ecash. >Off-list there has been some discussion about the role of certificates in >ecash, and in cash systems in general. It would be interesting to know >if this anti-theft provision of Digicash is actually provided by means of >a certificate. It is conceivable to think of the above mentioned methods in that way, yes /Lars Johansson ljo(a)ausys.se

1 0

Re: [NOISE] Re: FW: websurfer 4.6
by Ed Carp 17 Dec '03

17 Dec '03

> Date: Thu, 7 Dec 1995 15:49:09 -0600 (CST) > From: Aleph One <aleph1(a)dfw.net> > To: Rich Graves <llurch(a)networking.stanford.edu> > Cc: cypherpunks(a)toad.com > Subject: Re: [NOISE] Re: FW: websurfer 4.6 > On Thu, 7 Dec 1995, Rich Graves wrote: > > [snip] > > Microsoft's strategy is to support VB. > [snip] > > -rich > > > > Its interesting to note that all the people that were raving mad about Java > seem to be quiet now that MS is proposing to use VB. At least Java was > designed from the ground up with security in mind. But VB? Actual binary Well, at least it's easy and fun to program in (if you can call drag-'n-drop "coding"). Of course, until 4.0, their setup utility didn't check what version of DLL you were installing, so it's easy to get your DLLs out of sync on your system and blow your applications all to hell, and 4.0 throws all thos OLE crap in, even if you don't need/want/use OLE in your code and makes a 300K application into a 3M one, and they won't tell you what really goes on underneath the hood (I guess they're paranoid about getting ripped off), and never mind that it's almost trivial to write a VB decompiler (the .EXE is just a big jump table into offsets into VBRUN300.DLL), etc., etc., etc... And all this from a software company that took over 10 years to make their "operating system" do preemptive *anything*. But I guess I shouldn't complain. After all, VB has made me a pretty decent living for the past year or so...

1 0

Is there a lawyer in the house?
by cme＠acm.org 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- >Date: Sat, 2 Dec 1995 03:39:00 -0500 (EST) >From: Black Unicorn <unicorn(a)polaris.mindport.net> >Subject: Re: Netscape gives in to key escrow >An individual has no legitimate expectation of privacy in the encryption >numbers in his GAK browser, we reasoned, because he voluntarily conveyed >those numbers to the government when he purchased the software. It could be even worse. I was on a panel last year with Scott Charney (sp?) (I believe from DoJ) during which he commented that if you give your secret key to anyone -- e.g., your own company -- then you have given up the presumption of privacy. That leaves the police open to get that secret without a warrant. This claim should be checked by a real lawyer. +--------------------------------------------------------------------------+ |Carl M. Ellison cme(a)acm.org http://www.clark.net/pub/cme | |PGP: E0414C79B5AF36750217BC1A57386478 & 61E2DE7FCB9D7984E9C8048BA63221A2 | | ``Officer, officer, arrest that man! He's whistling a dirty song.'' | +---------------------------------------------- Jean Ellison (aka Mother) -+ -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMMdbP1QXJENzYr45AQF64QP/dXHnfLuh6FFwCY2GxKNYC5lHlj/hcFmy KqwWLYVqyr5vf/ZFEA6wlnVRMAARnenfCDmu7XQ9v9YzRjVrpjQMQAFrl9qlBivB 5wFGYSLME9sVtKIIPR0YSV8Xbw613bLmEnKiGrXxPNQ/bkaO30WOxG3N9Oen9DX4 sFfVbA+Ek0c= =CEEO -----END PGP SIGNATURE-----

3 2

Secrets (was:Is there a lawyer in the house?)
by Adam philipp 17 Dec '03

17 Dec '03

There seems to be some confusion about what the law of the land considers a "secret." Secrets according to our laws are knowledge one doesn not share without a BINDING legal obligation to keep the secret. Remember R4.C? That was a secret until it was shared, and hence lost its privileged position as a "Trade secret." Your secret key is just as safe, so long as it is always kept out of anyone else's hands. However if you are going to provide it to someone else it should be only through some form of contract. Even this might not be sufficient in some circumstances. The only truly safe possibility would be giving it to your lawyer in the course of your lawyers representation of you. NOTE: NOT YOUR COMPANY'S LAWYER. In house council have their obligation to the company, not to you. As such if they felt your key was unrelated to company business interests and possibly adverse to the company's interest...kiss that secret good bye. Sure, the police still need a warrant to go into your house and get the key, but they do NOT need a warrant to ask anyone else for your key, if you revealed your secret to someone who does not have an obligation of confidentiality to you, then they can reveal it with impunity. The danger of revealing it to a nonlawyer who has a contract with you is that they can be forced to reveal it, and still be liable to you for breech of contract... I am sure you see the dangers...just say no to key escrow...much safer. -Adam [NOTE: I am not an attorney, this is not legal advice, you get what you pay for] --=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-\ |PGP key available on my home page|Unauthorized interception violates | | http://XXXXXXXXXXXXXXXXX/adam |federal law (18 USC Section 2700 et| |-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-|seq.). In any case, PGP encrypted | |SUB ROSA... |communications are preferred for | | (see home page for definition) |sensitive materials. | \-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-/

1 0

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

17 Dec '03

It is important to remember that Nat Borenstein is a principal in a company that very much does not want to see anonymous e-cash succeed. Their extremely backwards technology cannot compete in the long term with cryptography-based methods, and therefore they are compelled to run around the country and on the Internet, bad- mouthing cryptography and anonymity at every turn, while pointing to some charity work for Phil Z. as a fig leaf to cover their actions in this regard (sort of like Exxon building an artificial reef and claiming to be friends of the environment.) I have, on several occasions, refuted his "infinite liability" rant, but it keeps on resurfacing. A few months ago, I wrote a short tech note on why this claim doesn't hold water. I thought I might stretch it into something longer, but other things have more urgently grabbed my attention. It's available at: http://www.communities.com/foo/noninf.txt Also, I haven't had time to confirm it, but based on conversations with and hints from Digicash people online, I'm pretty sure they are doing something similar to this (possibly better) that they are hoping to patent. --doug

2 1

Java musings
by fc＠all.net 17 Dec '03

17 Dec '03

Excellent musings. I just wanted to add something here. There is a fundamental issue with Java, and that is control: People in charge of organizations are responsible for what goes on within them. Without proper controls, it's impossible to carry out that responsibility. The people who want us to use Java are asking us to give up control over the programs run by our computers. They tell us to trust them because they say they have come up with a nearly fool-proof system for doing this safely. - They don't claim it's really secure, they only say it is harder to abuse than a C++ program. But nobody in their right mind would make it organizational policy to allow users to load and run C++ programs from over the Internet at the push of a button, and the removal of the particular things removed by Java are not adequate to justify this increased trust. - They won't back up their claims of security by assuming liability for resulting damages. Their liability disclaimers tell us they think their security is worth exactly nothing. They are asking us to bet control of our IT on a product that they take no responsibility for. - They don't even provide us with the ability to control their product in the way we control other purchased software we place into our environments. The inability to restrict which programs from which sources are run on our machines is a fundamental element of control. - Their product has been proven to be insecure in the past. Several examples of its insecurities have been demonstrated, and many more have been pointed out. There is essentially no counter point made by the Java supporters against these known defects. It seems to me that the loss of control resulting from the widespread introduction of Java would make it unacceptable to business. The use of Java as it exists today violates the policies of many businesses, and if their policies are ignored or changed to permit this to happen, it weakens the overall control structure of the organization. -> See: Info-Sec Heaven at URL http://all.net/ Management Analytics - 216-686-0090 - PO Box 1480, Hudson, OH 44236

2 1

Python Cryptography Toolkit v1.0.0
by Andrew Kuchling 17 Dec '03

17 Dec '03

I've just uploaded version 1.0.0 of the Python Cryptography Toolkit, a collection of cryptographic routines for the Python programming language. It's at ftp://ftp.cwi.nl/pub/pct/pycrypt100.tgz. All my code is public domain; some of the algorithm implementations are GPLed. The Toolkit now contains various cryptographic algorithms such as DES, IDEA, MD5, etc. I will fix bugs in the software, and may add or remove the odd module if some startling new research result comes out, but things should be pretty stable from now on. The algorithms available are: Hash functions: Haval, MD2, MD4, MD5, SHA. Private-key encryption: Blowfish, DES, DES3 (Triple DES), Diamond, IDEA, Alleged RC4, 32-bit RC5, REDOC III. Public-key: Digital Signature Standard, ElGamal, RSA. (There's a non-functional ESIGN module included, too; I'll finish it for a subsequent release.) Python is an interpreted scripting language; see http://www.python.org for more information, the source code, and binaries. It includes arbitrary-sized integers, so the public-key algorithms are implemented in pure Python; this entails a speed penalty, but makes the code more valuable for educational purposes. A sample usage of a hash algorithm (MD5) is: >>> import md5 >>> hash=md5.new() >>> hash.update(message) >>> hash.digest() '\235\361\034\357\217MX\2246\226\367\366Ebx\326' A sample use of an encryption algorithm (IDEA, in this case) is: >>> import idea >>> obj=idea.new('This is a key456', idea.ECB) >>> message="The answer is no" >>> ciphertext=obj.encrypt(message) >>> ciphertext '\2325$\343=)d\341^\025<\344\013\204 T' >>> obj.decrypt(ciphertext) 'The answer is no' Questions, comments, or suggestions are welcomed at the address below. Andrew Kuchling andrewk(a)cst.ca

2 2

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

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: 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