December 2003 - cypherpunks-legacy

Re: PROTOCOL: Encrypted Open Books
by tcmay＠got.net 17 Dec '03

17 Dec '03

At 12:45 AM 5/23/96, David Wagner wrote: >Apologies for replying to a reposted article; I wasn't subscribed when >the (very interesting!) open books protocol was originall proposed. ... >Did I miss an important part of the protocol, or does some extra >mechanism need to be added to counter this threat? I only forwarded the original article, not any of the discussion which followed. Inasmuch as the archives at hks don't appear to be coming back anytime soon (the March 18th message said "a few days"), I'll forward to the list the followup articles by Hal Finney and Eric Hughes. --Tim May Boycott "Big Brother Inside" software! We got computers, we're tapping phone lines, we know that that ain't allowed. ---------:---------:---------:---------:---------:---------:---------:---- Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)got.net 408-728-0152 | anonymous networks, digital pseudonyms, zero W.A.S.T.E.: Corralitos, CA | knowledge, reputations, information markets, Licensed Ontologist | black markets, collapse of governments. "National borders aren't even speed bumps on the information superhighway."

1 0

Re: An alternative to remailer shutdowns
by minow＠apple.com 17 Dec '03

17 Dec '03

Black Unicorn <unicorn(a)schloss.li> comments on the responsiblity of prudent persons (in, I presume, the context of threating e-mail sent through an anonymous remailier). I'm still perplexed: what can a "prudent" remailer operator do if a threatening e-mail was sent through a remailer under one or more of the following conditions: -- The remailer operator is legally enjoined from reading messages transversing his system. (For example, the remailer is subject to data privacy laws.) -- The message was encrypted using the intended recipient's public key. (This means that, without access to the private key, the operator has no mechanism to examine the e-mail.) Confused in Cupertino. Martin Minow minow(a)apple.com

2 1

Re: FTC online workshop on privacy
by shabbir＠vtw.org 17 Dec '03

17 Dec '03

There's actually an interesting parallel here. If you look at the Dworkin "ban pornography because speech is action" crowd, they often end up on the same side of things as the Christian Coalition "ban porn because it drives you to ungodly acts" crowd. They both happily support legislation that would ban such images. The left and the right move so far off the edges of the scales that they come around and meet each other on the same side of the issue. -Shabbir J. Safdar * Online Representative * Voters Telecomm. Watch (VTW) http://www.vtw.org/ * Defending Your Rights In Cyberspace "E. ALLEN SMITH" writes: > It's unsurprising that some of the same groups backing the CDA are >backing this, since they used danger to children as an excuse for it. (A >rather transparent one, given the actions vs Compuserve). I am disappointed in >EPIC for cooperating with them. > >From: IN%"declan+(a)CMU.EDU" "Declan B. McCullagh" 22-MAY-1996 17:46:10.71 > >>Excerpts from internet.cypherpunks: 22-May-96 Re: FTC online workshop on >>.. by Declan McCullagh(a)CMU.EDU >>> The legislation being introduced at 10:30 am will restrict selling >>> mailing lists with childrens' names and other identifying info on them, >>> including email lists. Another attempt to regulate the net, or a good >>> thing? > >>Whoops. I should have said the press conference happened at 10:30 am. >>The bill will be introduced in both houses later this week. > >>Interesting press conference. Enough is Enough! took quite a bit of time >>to rant about the dangers of the Internet. Pedophiles, chat rooms, >>illegal pornography. > >>You get the idea. > > Quite. > -Allen

3 2

INFO: Transcript of Sen. Leahy's RealAudio chat now available! (5/22/96)
by Voters Telecommunications Watch 17 Dec '03

17 Dec '03

============================================================================= ____ _ _ _ / ___|_ __ _ _ _ __ | |_ ___ | \ | | _____ _____ | | | '__| | | | '_ \| __/ _ \ _____| \| |/ _ \ \ /\ / / __| | |___| | | |_| | |_) | || (_) |_____| |\ | __/\ V V /\__ \ \____|_| \__, | .__/ \__\___/ |_| \_|\___| \_/\_/ |___/ |___/|_| REALAUDIO TRANSCRIPTS OF LEAHY'S WIREDSIDE CHAT AVAILABLE CLIPPER III RESOURCES AVAILABLE REP. RICK WHITE (R-WA) SCHEDULED FOR HOTWIRED CHAT 6/5/96 9-10PM EST Date: May 22, 1996 URL:http://www.crypto.com/ crypto-news(a)panix.com If you redistribute this, please do so in its entirety, with the banner intact. ----------------------------------------------------------------------------- Table of Contents News How to receive crypto-news ----------------------------------------------------------------------------- NEWS Rave reviews of Senator Leahy's appearance on HotWired's WiredSide chat are coming already. With this appearance, the gentleman from Vermont proves once again that he knows net.politics on a personal level, and can understands the subtleties that we assume many in Congress are just learning. If you missed Sen. Leahy's appearance, arranged by HotWired, the Center for Democracy and Technology (CDT), and the Voters Telecommunications Watch (VTW), you can still hear the Realaudio transcript from the front page at http://www.crypto.com/ A new Clipper III section has been added to www.crypto.com, with pointers to the online version of the White House proposal and the initial analyses from EPIC, CDT, and John Gilmore of the EFF. DON'T FORGET! Representative Rick White (R-WA) will be on HotWired Wednesday June 5th at 9pm EST at http://www.hotwired.com/wiredside/ You can tune in and listen to the chat with the RealAudio software (http://www.realaudio.com) You can ask questions of the Representative through a moderator and get real, immediate responses. Rep. White is part of the new breed of legislators leading Congress to make better net policy through his leadership in the Internet Caucus, a vanguard group of legislators who have vowed to provide sound leadership and advice to other members of Congress in the area of net.policy. ----------------------------------------------------------------------------- HOW TO RECEIVE CRYPTO-NEWS To subscribe to crypto-news, sign up from our WWW page (http://www.crypto.com) or send mail to majordomo(a)panix.com with "subscribe crypto-news" in the body of the message. ----------------------------------------------------------------------------- End crypto-news =============================================================================

1 0

PROTOCOL: Encrypted open books
by tcmay＠got.net 17 Dec '03

17 Dec '03

>Date: Thu, 26 Aug 93 11:28:14 -0700 >From: Eric Hughes <hughes(a)soda.berkeley.edu> >To: cypherpunks(a)toad.com >Subject: PROTOCOL: Encrypted open books >Status: OR > >Note: I started this reply last week; I've decided to post what I >know, since I don't have a solution and I've run out of simple ideas >for now. > >Hal' criticism that (real) money could leak out of the system is >correct. The problem is that while the books would still balance, >i.e. sum to zero, some fake depositor would have a negative balance, >the net result of taking out more money than you put in. Negative >numbers just aren't allowed in double-entry bookkeeping, but they were >allowed in the first protocol set. > >The first part of the solution is to allow no private accounts on the >left hand (asset) side of the ledger, in other words, no anonymous >loans. A protocol for doing anonymous loans could be invented, but >since the first problem is merely to run a money exchange and not more >complicated financial services, this is acceptable. Most of the money >that left the S&L's was by corrupt loan practices, so I don't consider >this omission a particularly glaring one right now. > >Therefore all the private accounts must be on the right hand side, >that is, they are all liabilities. In layman's terms, the bank owes >you; should you ask for your money, they have to give it to you. If >we can verify that each of these accounts never goes negative, then we >can be certain that if the books balance, that the amounts of money in >each account are accurate. > >Consider this. If money was transferred from your account to another >one, that transaction shows up in the public encrypted transaction >record. If you have due diligence over this record, you can assertain >that no transaction was performed against your will. This case >corresponds to a debit and credit against two customer accounts, >decreasing one and increasing the other. > >Another way that money might end up in a fake account if it were >credited with assets. A debit to an asset increase its value and the >credit to the account increases that value. This is the case of a >deposit; the bank gets cash (+asset) and credits someone's account >(+account). Now if they want to give someone money this way, they >have to do so by increasing the assets somehow; in other words, they >money has to come from somewhere. It didn't come from any of the >customers because they've already verified that. It didn't magically >appear from one of the other asset accounts because these are all >publically audited. > >In summary, we need to ensure that all accounts have positive balance. >Public accounts can be revealed and seen to be positive. Private >accounts need a cryptographic assurance. > >A private account starts off at zero. This can be publically >revealed. Then to the encrypted transaction log and the public cyclic >balances we add publication of the private balances in encrypted form >that allows us to verify to the blinded balance is positive. This >balance is verifiably linked to previous cyclic balances via the >transaction log. It is therefore linked all the way back to the >beginning balance which was zero. > >Consider all the transaction triples for which the first element is >equal to the private account in question, since the account was >opened. Take a product of all of the second elements and a product of >all the third elements. It is clear that these products can be >calculated inductively from the previous cyclic products and the >activity in this cycle. > >The products on second and third elements are equal to > > g^( Sum x_i,j,t + Sum r_i,j,t ), h^( Sum r_i,j,t ) > >where I've added a time index by cycle which was implicit before. The >notation for the inductive calculation is different, of course, and >also obscures the underlying invariant. > >What we want is a certificate that Sum x_i,j,t is positive. Here it >gets a bit hairy. There are likely other solutions to this technical >requirement; here is the one I thought up yesterday and today. > >I thought I had an idea with promise on how to create such >certificates using quadratic residuosity, but it doesn't work. I'm >still thinking about it; this certificate doesn't seem impossible to >create, but the standard ideas that I know about in algebraic protocol >design don't seem to work. > >If anybody wants to work on this technical point off-line with me, >send me mail. The math involved is advanced enough that I'd prefer to >post summaries of work rather than all the detailed discussion. > >Another non-technical attack on the problem is to require periodic >bank holidays, where all private balances will be revealed to be zero >(preferably), or whatever is actually in the account. This doesn't >prevent owner fraud, but does put an upper bound on the time in which >to perpetrate it. > >Eric

1 0

re: "Very Famous Reporter"
by Deranged Mutant 17 Dec '03

17 Dec '03

On 21 May 96 at 10:06, Robert Hettinga wrote: > In the meantime, it appears that I have egg on my face, as no story has > emerged... > > By the way, did I say it was a rumor? ;-). Likely the Very Famous Reporter (tm) misheard something about MD5, confused it with DSS (and possibly even something to do with PGP), though (s)he had a hot story, spoke to some folx, and it fizzled. Nah. Just a rumor. Rob. --- No-frills sig. Key-ID: 5D3F2E99 1996/04/22 wlkngowl(a)unix.asb.com (root@magneto) AB1F4831 1993/05/10 Deranged Mutant <wlkngowl(a)unix.asb.com> Send a message with the subject "send pgp-key" for a copy of my key.

1 0

No Subject
by unknown＠example.com 17 Dec '03

17 Dec '03

The answer to information is more information.

2 1

Re: PROTOCOL: Encrypted Open Books
by jamesd＠echeque.com 17 Dec '03

17 Dec '03

At 05:45 PM 5/22/96 -0700, David Wagner wrote: > a fake account, without a real >customer, and fakes a transfer into that account, pocketing the >money that should have gone into that account? Then the total indebtedness of the bank will go up, but its total assets will not. If the bank does this, then there is no point. If an employee does this, then the loss will show up on the books. --------------------------------------------------------------------- | We have the right to defend ourselves | http://www.jim.com/jamesd/ and our property, because of the kind | of animals that we are. True law | James A. Donald derives from this right, not from the | arbitrary power of the state. | jamesd(a)echeque.com

1 0

Re: Long-Lived Remailers
by David E. Smith 17 Dec '03

17 Dec '03

At 20:40 22 May 96 NSA operative Loren James Rittle <rittle(a)comm.mot.com> wrote... (This was originally me. Wow.) > >:: > >Remailers-To-Chain: 7 > >Remailers-To-Avoid: remailer(a)nsa.gov > >Final-Destination: tcmay(a)got.net > > This will not work. The original sender must pick the path himself, > if maximum encryption to hide the final destination is to be used. > The properly used cypherpunks-style remailer network provides that as > long as even one remailer in the chain is trustworthy, your secret is > safe. Under your scheme, if the first remailer is untrustworthy, > everything is blown. This is because unless the original sender > pick's the path (or at least the last hop explicitly), the final > destination and message must be available to each hop. Well, I freely admit that it was just a notion that sort of came to me whilst at the terminal, with a beer on the desk. The sort of thing that often impairs my already-limited judgment :) Although... is this a possible way to lessen remailer-operator liability? If it is known that every remailer along the way chooses another remailer at random, it might become less likely to hold any given last-hop remailer liable for the CO$ documents spewed forth from it. It would become necessary to keep track of the final destination and to decrypt at every stage, unless there's a set Last-Hop: header; but that would defeat the whole purpose. Having traffic going all over the place randomly might be useful to defeat traffic analysis, though. I think I've just argued myself out of the whole idea. Never mind :) dave ObCPList: Have I been killfiled yet? If you don't see this message, send me a note :) ---- David Smith Box 324 Cape Girardeau MO USA 63702 http://www.prairienet.org/~dsmith dsmith(a)prairienet.org Reality is only for those lacking in true imagination... Send mail w/'send pgp-key' in subject for PGP public key

1 0

Re: FTC online workshop on privacy
by E. ALLEN SMITH 17 Dec '03

17 Dec '03

From: IN%"declan+(a)CMU.EDU" "Declan B. McCullagh" 22-MAY-1996 19:58:03.69 >Excerpts from cypherpunks: 22-May-96 Re: FTC online workshop on .. by "E. ALLEN SMITH"@ocelot. >> It's unsurprising that some of the same groups backing the CDA are >> backing this, since they used danger to children as an excuse for it. (A >> rather transparent one, given the actions vs Compuserve). I am >> disappointed in EPIC for cooperating with them. >You shouldn't be, and I should have been more clear. There is a broad >coalition of groups supporting this legislation, including (from memory) >the Kids off Lists! project, Center for Media Education, and Consumer >Federation of America. This appears to be another liberal (e.g., EPIC) vs libertarian difference. Liberals say we've got to have laws to protect the children, such as via keeping them from _email_ lists. Libertarians say it's the job of the parents (and the police, for non-anarchists) to protect the children. Yes, such lists can be misused (although I see no more reason to say the email ones can be truly misused than to say the CDA was justified). So can, say, cryptography. -Allen

1 0