December 2003 - cypherpunks-legacy

Magic Money simplification
by Hal 17 Dec '03

17 Dec '03

In my posting about remailer abuse, I mentioned a point in passing re Magic Money that perhaps deserves a more explicit mention. Presently, Magic Money has each user create a special public key just for use by that program. When MM sends a message to the bank, it includes a copy of the user's public key. Then, when the bank sends the return message, it encrypts it with that key. (Messages to the bank are also encrypted with the bank's public key.) Last night it occured to me that this encryption may not be necessary. Messages to the bank are of the form f(x)*r^e, where f is a one-way function, x is the coin's serial number, r is a random blinding factor, and e is the bank's public exponent for this denomination. The bank signs this by taking it to the d power, were d is the RSA-inverse of e, and sends back f(x)^d * r. It looks to me like these two messages are secure even without being encrypted with the user's or bank's public key. r, and r^e, both act as one-time-pads, blinding the underlying f(x) or f(x)^d value perfectly. This blinding, of course, is what prevents the bank from linking up withdrawn cash from spent cash. But it should serve just as well to prevent an eavesdropper from stealing the cash. If someone manages to get f(x)^d * r, this is of no value to them if they don't know r. Since only the original sender knows r, this message can be sent in the clear. Similar logic applies to the message from the user to the bank. If this argument holds up, the usage of Magic Money can be simplified considerably. The user should no longer have to create a special public key. Nor should he need to know the bank's public key. All he needs to get started is the email address of the bank, to which he can send the standard initialization query message which causes the bank to send back information about the exponents and denominations used, as well as the name of the money. Of course, when users send actual un-blinded coins amongst themselves as payment, those transmissions need to be encrypted or done via some secure channel. But MM never concerned itself with those. It was only involved with messages to and from the bank, and for these it seems to me that encryption is not necessary. Hal

1 0

INTERNET CONNECTIONS IN JAPAN
by Sandy Sandfort 17 Dec '03

17 Dec '03

C'punks, A quick question to help an international friend: Does anyone on the list know anything about getting a (cheap, if possible) Interenet connection in Japan? Please let me know by private e-mail if you have any information. Thanks, S a n d y

1 0

Re: Very funny, Polyanna :-( [namespace pollution]
by gtoal＠an-teallach.com 17 Dec '03

17 Dec '03

:Isn't this really just a special case of the more general problem of :deciding which keys on a public key ring you're willing to trust? :Perhaps your mailer script should automatically encrypt only when a :keyid is found with a signature trail that you trust. No, that's a totally separate problem. What I'm worried about is some comedian publishing a public key for addresses like "alt.security.pgp(a)cs.utexas.edu" or any of the common mailing gateways, and suddenly people using auto-encrypting mail programs find that no-one can read their posts. It kind of throws a spanner in the works for completely transparent pgp shells. :I do see a signature for that key from Miron Cuperman. Perhaps :you'd want to modify your trust parameters for him... That's not the point; someday soon people will be using mailers that auto-pgp without them even realising it. I don't want to have to hassle those people with interactive questions about whether they trust someone, or force them to maintain personal lists of bad addresses. Whatever solution we can find will have to involve active support from the keyservers I suspect. thoth@netcom - I hope you're listening to this! There's a definite problem of a denial-of-service attack here that the current scheme makes hard to avoid. Hence why I called it 'namespace pollution' in the subject line. G

2 1

URGENT: NII Summit announcement - don't miss out!
by Stanton McCandlish 17 Dec '03

17 Dec '03

Tomorrow, March 29, the NII Summit begins in DC. This is an announcement that should be of relevance to anyone interested but unable to attend, as you can still participate "virtually". Get your word in NOW. EFF will probably be providing links to the Summit gopher and web server via gopher.eff.org 1/Alerts, and via http://www.eff.org/ Forwarded message:

1 0

Chaumian digicash papers
by Sameer 17 Dec '03

17 Dec '03

Pardon the faq, but where can I find by ftp Chaum's papers/articles/etc on digicash? Pointers to wother works on the subject would be appreciated as well. Thanks.

1 0

Re: cfp '94 transcript
by jim＠bilbo.suite.com 17 Dec '03

17 Dec '03

----------- [...] (Unknown) My name is Barbolin (?) from GRC (?). I have a question concerning the algorithm that is used in the Clipper Chip, Skipjack..[]..There is a certain amount of conjecture that in fact the algorithm contains a deliberately encoded weakness that will allow the NSA, without access to the escrow keys, to be able to intercept communication in their mission to monitor on- shore and off-shore communications..[].. BAKER I'll answer it yes or no if you'll tell me exactly the question. UNKNOWN Does it or does it not contain a weakness that allows you to intercept the communications without access to the escrow keys. BAKER No. ----------- ObNit: As has been said before by others, there's more to Clipper/EES than just the Skipjack algorithm. I think simply asking if "the [Skipjack] algorithm contains a deliberately encoded weakness" leaves too much room for a "truthful" No answer. People have posted descriptions of mechanisms that could be used to leak key information which do not rely on a deliberately weakened encryption algorithm. (depends on how broadly you define "algorithm"). A better question to ask would be... Are there any software or hardware mechanisms, or combinations of software and hardware mechanisms, present in the Clipper/EES system that supports or enables decryption of intercepted Clipper/EES communications without access to escrowed unit keys? Does that cover it well enough? Jim_Miller(a)suite.com

4 3

Shirt project
by Eric Johnson 17 Dec '03

17 Dec '03

Crypto Political Action Sportware... Is anyone interested in a T-shirt with the swoosh Big Brother Inside front, and maybe a !Key Escrow (RSA button style; red circle and slash over the words Key Escrow)? Would be a real conversation piece with non-crypto friends, I would think. I recently heard another great idea for a shirt: 1 9 8 4 "We're behind schedule." National Security Agency I think I'll do at least a few for myself and friends, if no one else is interested. Also, reply directly to me (and *please* don't cc: the list), so I can get an idea of how many to order, if I do this. If it's already been done, I would like to know about that also. "Shirt orders" sent to the list will be ignored... --Eric --- Eric Johnson ejohnson(a)names.maricopa.edu Maricopa Community Colleges, Tempe AZ 602-731-8919

3 2

Re: cfp '94 transcript
by jim＠bilbo.suite.com 17 Dec '03

17 Dec '03

SINCLAIR DOUGLAS writes: > I'm not sure what the NSA policy is on this. However, at > that same conference Jim Settle from the FBI told us > plainly that he is allowed to lie, and that the courts have > confirmed this right. I doubt Baker would have confessed > to a back door even if one existed and the question was > complete. > Ah, of course. What was I thinking? After all, this is a national security issue we're dealing with. I guess my idealism is showing again. Jim_Miller(a)suite.com

1 0

Re: Ames/clipper compromised?
by smb＠research.att.com 17 Dec '03

17 Dec '03

If the algorithm becomes known at this stage in the game, they can probably "easily" generate a modified SKIPJACK algorithm (changing the S-boxes or equivalent), a new family key, and a subtle variation on key generation. They might not even need to re-spin the chip design if, as they claimed, the critical parts of the algorithm are programmed into the chip after fabrication. Of course, we now know that changing the DES S-boxes isn't necessarily easy. Without knowing the details of Skipjack, we can't even start to evaluate it. BTW, my guess at the most likely back door is that the unit keys will be generated as a cryptographic function of the serial number and a *small* random number generated for each chip and unknown to the agency. They would have to search a mere 2**16..2**32 keys once they get the serial number out of the LEEF. The existance of such a backdoor would be difficult to prove, since there would be no visible evidence for it in the individual chips. It is also difficult to disprove such a theory because the clipper key generation algorithms are classified. The review committee will be looking at the key generation mechanism, according to Steve Kent. Not as good as publishing it, of course, and -- if they're honest -- there would seem to be a lot less reason to keep it secret than there is for Skipjack. (I don't like Skipjack being secret, but at least the ostensible reason is quite sensible, given their motivations.) A useful exercise for this group might be to compile a list of questions that they *should* answer if they're playing it straight. These could be forwarded to the review committee, too. If we come up with a good list, I'm willing to submit it to them. For that matter, I'll submit it to one of the gentleman from NSA who gave the Clipper presentation at Bell Labs. (But I won't bother sending in ``when did you stop beating your spousal equivalent unit'' questions; there's no point to doing that in this venue.) Question 1: What is the unit key generation algorithm? If it is classified, justify the decision with reasoning at least as persuasive as the reason Skipjack is classified. Question 2: Ditto for the device serial number. Any more?

1 0

words, words, words: debate at Stanford on March 30
by Marianne.Mueller＠Eng.Sun.COM 17 Dec '03

17 Dec '03

I guess Oxford style debates are all the rage. with apologies if this already showed up on the list, mrm ----- Begin Included Message ----- From: ceh(a)leland.Stanford.EDU (Carey Heckman) Newsgroups: su.school.gsb.events Subject: Encryption, Digital Communications Debate, 3/30 5:30 pm Date: 23 Mar 1994 11:20:05 GMT Organization: Stanford University, CA 94305, USA Sender: ceh(a)leland.stanford.edu NNTP-Posting-Host: cardinal.stanford.edu ENCRYPTION AND DIGITAL COMMUNICATIONS: LAW ENFORCEMENT OR PRIVACY? An Oxford-Style Debate J. Kent Walker, Jr. (Stanford Law '87) Assistant U.S. Attorney and Coordinator, High-Tech Task Force Marc Rotenberg (Stanford Law '87) Washington Director, Computer Professionals for Social Responsibility Wednesday, March 30, 1994, 5:30 PM Stanford Law School, Room 290 Light Refreshments Served This debate brings together two nationally prominent experts in this area. You won't want to miss the verbal fireworks and the opportunity to learn more about this important question. Background ========== The Clinton Administration is promoting use of the Clipper Chip technology that provides encryption, but in a form that law enforcement can unscramble. It also backs legislation requiring design of digital communications networks so ongoing surveillance will be feasible. Law enforcement officials argue that these proposals are necessary to protect society from criminals and preserve important investigative tools. Privacy advocates contend that these proposals grant broad new powers to law enforcement agencies and diminish protection for future users of the National Information Infrastructure. Sponsored by the Stanford Law and Technology Policy Center and the Stanford Law and Technology Association. Additional Information ====================== Contact the Stanford Law and Technology Policy Center by email (Law.Tech.Policy@forsythe) or telephone (5-7788).

1 0