December 2003 - cypherpunks-legacy

Hiding remailers behind nymservers...?
by Steve Reid 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- This 'middle-man' remailer... What does it really accomplish? Sure, the operator is hidden, but that's only because of his/her nym at c2.org... AFAICS, the 'middle-man' has just taken the liability off himself and put it on the unhidden remailers. Why not just use the existing unhidden remailers??? I think this is similar to the idea that came up about having some (but not all) remailers only deliver to other remailers, for use as any link in a chain except the last link. The operator doesn't have his email address attached to spam, and there's very little liability because Co$ and other pressure groups will always(?) go after the last remailer in the chain, since that's the only one they can know was involved. I think the pseudonymously hidden remailer is an interesting idea, but I don't think it offers anything over the unhidden remailers, since it's still depending on the unhidden ones.. If you want to aviod liability, what's wrong with running a remailer that only delivers to other remailers, as I mentioned above? Am I missing something here? ===================================================================== | Steve Reid - SysAdmin & Pres, EDM Web (http://www.edmweb.com/) | | Email: steve(a)edmweb.com Home Page: http://www.edmweb.com/steve/ | | PGP (2048/9F317269) Fingerprint: 11C89D1CD67287E68C09EC52443F8830 | | -- Disclaimer: JMHO, YMMV, TANSTAAFL, IANAL. -- | ===================================================================:) -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: noconv iQEVAwUBMaEhlNtVWdufMXJpAQEUbwf9F1081yRIazOUcr/z+ifihD5PLTr70V9X zvp13QXvPVao5Jg1N83Tfrar7zQYnvHU2RYPVBLecxZAY0hhbRRhOF/GVhkfcm2g ehNuQdTxilVTRbCez49zLpXxQEKvnullLYOZY3qv1xe9MaqjuS5C73c3H5oNhQTz B79cdvLynsIrhXD5oLyZyUxX/fggsFIfQsAh6a1KAdC0OclF1/dm1WeJKADSMFq4 bBt5BZcd410tfwpy+VTD5TUt7tb2wAOv56tVKVcPIXPZ04hr4Nlww6pQ+dtR4/B0 j1lzfrdDxos6h33abB9TpKrfo8uBsGxlkGyefqre+qvfexZwv/Wpmg== =sJVW -----END PGP SIGNATURE-----

1 0

Re: An alternative to remailer shutdowns
by William Ono 17 Dec '03

17 Dec '03

On Mon, 20 May 1996, Don may have written: > Re: "permitted" list > > Addresses must be hashed. That makes sense. I don't think the processing time is very significant here. Even using somewhere where collisions can be created is not much of a problem, as email addresses tend to be picky for syntax. > Possibly auto-added to the list when mail comes > from that address. How would mail spoofing be prevented? Sending mail with a given From: address is laughably trivial, even making Recieved: look feasable is easy. Having people PGP-sign their 'add' requests might work, but then anybody can create any keys with any email address attached to it. Asking the remailer operator to verify each key would be unimaginable. Sending back acknowlegements suffers from storage problems, processing power problems, and also makes it significantly easier for traffic analysis. (One mail in, one mail out, one mail in, lots of mails out. Pairs of mails roughly corresponding.) On the whole, I think the idea of 'permit lists' is good, but not one that is very workable under the current "structure". IANACoNE (cryptologist or network expert) -- ** NOTE NEW KEY ** As of 08/28/95! Old key 0x2902B621 COMPROMISED! William Ono <wmono(a)direct.ca> PGP Key: F3F716BD fingerprint = A8 0D B9 0F 40 A7 D6 64 B3 00 04 74 FD A7 12 C9 = fingerprint PGP-encrypted mail welcome! "640k ought to be enough for everybody."

1 0

Re: The Crisis with Remailers
by tcmay＠got.net 17 Dec '03

17 Dec '03

At 5:25 AM 5/21/96, Lance Cottrell wrote: >An interesting problem with anonymous postage is that it is likely to kill >cover traffic generators. > I doubt it. It's easy enough for remailers to, for example, pass out free tokens to other remailer operators. (Jukebox and other coin-op concessions often pass out tokens (slugs, or marked coins) to storeowners and bartenders to use to stimulate the market.) --Tim 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

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

17 Dec '03

Wei Dai wrote: "There is indeed a short section in the Cyphernomicon about encrypted open books. Unfortunately it doesn't describe it in detail, and since the hks.net archive is down, I can't look up Eric Hughes' original e-mail on the topic. If anyone has a copy of it in his personal archive, please repost it. I'm sure other people would be interested as well." Your wish is my command! >Date: Mon, 16 Aug 93 13:57:51 -0700 >From: Eric Hughes <hughes(a)soda.berkeley.edu> >To: cypherpunks(a)toad.com >Subject: PROTOCOL: Encrypted Open Books >Status: OR > >Kent Hastings wondered how an offshore bank could provide assurances >to depositors. I wondered the same thing a few months ago, and >started working on what Perry calls the anonymous auditing problem. I >have what I consider to be the core of a solution. > >All the following protocols and ideas are in the public domain. > >The following is long. > >My notation here will also be much less formal than I am capable of; I >don't want to make the uninitiated read TeX. > >The basic idea is that summation can be performed encrypted by using >exponentiation in a finite field. That is, if I represent an amount x >by g^x and an amount y by g^y, then I can compute the sum of x and y >by multiplying g^x and g^y, getting g^(x+y). Very basic. > >So let us take a very simple version of this protocol, which leaves >out many desiderata. If a shared funds account, say, has a bunch of >transactions made on it, then we can publish each of those amounts x_i >(for the non-TeX'd, underscore means subscript) encrypted as g^(x_i). >I know what my transaction number, i, is, and what the amount was, so >I can verify that my transaction appeared in the public list. We also >publish the beginning and ending balances, givings use a total >difference X. Now anyone can verify that g^X equals g^(Sum_i x_i). >That is, everyone can verify that the aggregate effect of the >transactions is what is claimed without revealing the amounts of any >of them. > >What does this protocol reveal? It reveals the number of transactions >on each account and thus the total number of transactions. It is also >subject to known plaintext attack. If I get an account on this system >and make one transaction in each amount, I can decrypt by table lookup >the whole transaction flow. The total number of transaction accounts >is also revealed, or, for a bank, the number of customers. > >We can easily solve the known plaintext attack by blinding each >transaction. Instead of publishing pairs <i, g^(x_i)>, we have for >each transaction a blinding factor r_i and publish triples > > <i, g^(x_i + r_i), h^(r_i)> > >The notation has grown. g is a generator of a finite field G, and h >is a generator of a different finite field H. > >We also publish R = Sum_i r_i in addition to X = Sum_i x_i. > >What is the public verification procedure? Basically the same as the >first case, but in addition taking into account the blinding factors. > >Step 1. Calculate Product_i h^(r_i) and make sure that it equals h^R. >This validates the blinding factors. > >Step 2. Calculate Product_i g^(x_i + r_i) and make sure that it >equals g^(X+R). This, given the validity of the blinding factors, >validates the actual transactions. > >How does this resist known plaintext attack? Since the blinding >factors r_i are flatly distributed over their range (caveat! you pick >the order of G smaller than of H to assure this), the x_i + r_i sum >acts exactly as a one-time pad to encrypt the amount. In summary, >what is going on here is that both the messages (amounts) and the keys >(the blinding factors) are being sent out as images of one-way >functions (exponentiations) that preserve exactly the relationships >that we want. > >There's more. For a real business, we want to keep double entry books >and not just single entry accounts as above. By extending the number >of terms in the transaction, we can do that too. In double entry >bookkeeping, the total amounts for each transaction must sum to zero >over the various accounts being transacted upon; I say this knowing >that when you print out the information for an accountant you'll have >to do some sign twiddling for the asset and liability/equity halves of >the books. Also, a single transaction may involve more than two >accounts, even if in practice most involve only two. > >The basic idea here is that each transaction is a set of the above >transactions whose sum must be zero. So for a transaction i, we publish >a set of triples, indexed by j, > > < T_i,j, g^( m_i,j + r_i,j ), h^( r_i,j ) > > >where the subscripts are doubly indexed and where T_i,j represents the >account that amount m_i,j is changing. Now we can perform, on each >transaction, the following very similar verification procedure for >each fixed i. > >Step 1. Verify that Product_j h^( r_i,j ) = 1. This verifies that >the blinding factors sum to zero. > >Step 2. Verify that Product_j g^( m_i,j + r_i,j ) = 1. Since the >blinding factors sum to zero, this ensures that the transaction >amounts sum to zero. > >Not that both of these sums are done over j, not i. In other words, >we validate each transaction individually. > >Now we also publish aggregate changes in the public accounts just as >before. The holders of private accounts know what how their accounts >have changed. Then we can use the the single account verification >method as above to verify that the totals match. Everyone can verify >that the public accounts match, and the holders of private accounts >can verify that they match. > >To summarize: The transactions are doubly indexed. If you group by >transaction, then you verify that each transaction sums to zero. If >you group by account, then you verify that the change in that account >is as expected, be it public or private. > >In the scenario that Kent originally proposed, one of the public >accounts would be a gold account, which through independent public >auditing would be verified to be accurate. I personally would not use >gold but rather denominate certain accounts in shares of mutual funds, >which are resistant to the currency inflations of mining and stockpile >sales. > >What information is still being disclosed? The most worrisome to me >is that the total number of transactions per account is revealed, that >is, aggregate activity, but not total money flux. I have an insight >that may allow the _account_ to be blinded as well as the amounts, and >be revealed in aggregate just as the amounts are, but I have not >worked out the details because I am not fully up to speed on the >relevant math. > >BEGIN BIG MATH >I only expect a few people to follow the next paragraphs, so if you >don't understand it, skip it. > >Here's the idea. The modular exponentiation is performed in a finite >ring. We choose a ring that has lots of distinct prime ideals of >sufficiently large order. To each account we assign one ideal. We >represent dollar amounts as elements of this ideal; since the ideal is >prime, this is straightforward. The property of the ideal we use is >that the sum of any two elements of the ideal is also in the ideal. >Hence by partitioning the ring, we also partition the computation of >the accounts. We are blinding the transcations by account because we >rely on the fact that blinding is not an intra-ideal operation, and >thus does not preserve that invariant, which would otherwise be >public. > >We must be careful not to allow operations that would result in an >element which was in the intersection of two ideals. This requires >upper bounds both on the transaction amount and on the number of >transactions per cycle. There might be rings of order p^n+1 which >would be suitable for this operations, but I am not sure of the >security of the discrete log in such cases, except for p=2, in which >case it is bad. > >END OF BIG MATH > >The protocol as specified, though, is useful as it stands. I have not >specified all the details. For example the blinding factors should >likely be created in a cooperative protocol at the point of >transaction; blinding factors for intra-bank transactions should not >contain subliminal channels. Certificates of deposit and withdrawal >should be tied to the published transaction information. Etc. >Remember, this is the core of an idea. > >One criticism I do wish to address now. I don't think it matters if >the bank manufactures fake transactions. The customer can reveal the >sum of all the blinding factors for transactions on that account, in >public, and can thus prove what should have been there. Since the >blinding factors were committed to in public, there is a strong >assurance that these blinding factors are what they are claimed to be. >This in itself can be made into an actual proof of liability. Note >that even this revelantion does not compromise individual >transactions. It only reveals the aggregate value change, which is >exactly what is at issue with the bank. > >On the other hand, all of the bank assets that are held external to >that organization can be externally audited in the same way. The >other institutions that hold money might be persuaded to undertake a >legal obligation to honor what the encrypted open books say they >should have; this may not be difficult because they can verify that >their record of the transactions matches what has been published. > >If we use the contents of the encrypted books at the organizational >boundary points to create suitable legal opbligations, we can mostly >ignore what goes on inside of the mess of random numbers. That is, >even if double books were being kept, the legal obligations created >should suffice to ensure that everything can be unwound if needed. >This doesn't prevent networks of corrupt businesses from going down >all at once, but it does allow networks of honest businesses to >operate with more assurance of honesty. > >Eric

2 1

Re: Long-Lived Remailers
by tcmay＠got.net 17 Dec '03

17 Dec '03

At 4:56 PM 5/20/96, Rev. Mark Grant, ULC wrote: >With regard to the problems of remailers being shut down when we want >long-lived addresses, wouldn't seperating the input and output be one >possibility? That is (like Hal's Alumni remailer) you'd send mail to >'remailer(a)anon.ai' and it would be forwarded via a disposable account >elsewhere. All messages would appear to come from 'disposable(a)foo.com' and >if that account was shut down a new one could be opened to replace it >while incoming mail simply backed up at the main remailer account. This is a very good idea. It keeps the advantages of having persistent accounts (which other users, chaining programs, etc. can use) while making it appear that the mail is coming from another account. "Security through obscurity," I hear you snort. Well, not really. The _legal_ account is the one that an unhappy recipient sees on the "From:" line. The Church of Scientology sees "disposable(a)foo.com" and fires off a letter to foo.com requesting that foo.com cause this account to disappear. So it does, but "transient(a)bar.com" picks up the slack. An idea worth trying, of formally/legally separating the functions. Of course, in some sense this is a special case of having disposable accounts for "instant remailers" (see recent thread on this). >The only potential problem I could see would be that the disposable ISP >might have logs which could track the outgoing messages back to the other >account. You'd also obviously need to open the disposable account >anonymously or using an ISP who'd protect your identity. Traffic analysis will be quite easy to do, of course, as all mail sent to the persistent address comes out of the "disposable(a)foo.com" address. Q.E.D. (Hal, to use him as the example, could start using his own choice of remailer hops to accomplish much the same result. We've talked about this for a long time, too. If I ran a remailer, I think I'd route *all* traffic leaving my site through at least one other remailer...kind of a "hot potato" effect. Of course, if _everyone_ did this, an infinite loop would result. Lots of interesting twists, though, as messages could be set to "leak out" of the loops.) But this scheme, here, and Mark's scheme, are variants on the idea of trying to make the remailers less clearly-identifiable targets. --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: Senator, your public key please?
by tcmay＠got.net 17 Dec '03

17 Dec '03

At 8:45 PM 5/20/96, Andrew Loewenstern wrote: ... >Your local KCA (KKK Certification Authority) could as easily issue a "This >key is owned by a Nigger." certificate for a public key as TRW could issue a >"This key is owned by a Deadbeat." certificate. Presumably, future versions >of PGP and other public-key crypto systems will support free-form certificate >generation and not the quasi-fixed-definition signatures currently found in >PGP. Indeed, this is one of the things I was referring to. To wit, that one can possibly (emphasis on "possibly," modulo legal actions, a la my point) use "Metzger's Web of Trust" to effectively discriminate. (ObCaveat: I personally think a free society cannot/should not outlaw discrimination in any form, save that by government.) >You can be sure that there will be rallying cries for laws to be passed to >ensure the accuracy of statements made in key certificates, that characters >are not defamed, that libel is not committed, etc... Lots of the same issues >involving any other type of speech and the international and sometimes >untraceable nature of the Net. What do you do about a signature on your key, >posted anonymously to the net, which names you as one of the Four >Horsemen(*tm)? By the way, this issue has some echoes of another technogical issue: the use of neural nets for loan approval software. Turns out that when a bunch of things are entered into a NN loan package, including the all-important default rate, the applicant's age, income, race, sex, education, employment history, credit history, etc., that NN loan packages "end up" rejecting many black applicants, more so than white or Asian applicants. (The NN "concluded" that blacks were higher risks for default than whites/Asians.) Even if no human being ever entered his or her biases and prejudices, the NN spit out this result. I recall there being talk about requiring "equality of outcomes," and that such NNs might have to have deliberately-biased inputs fed in, but I don't know what ever happened to this issue. In any case, I think this sort of issue, and the semi-related issue of "discrimination via key signatures," to be likely important issues in the courts in the coming years. --Tim 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 tcmay＠got.net 17 Dec '03

17 Dec '03

At 5:47 AM 5/21/96, Rich Graves wrote: >On Tue, 21 May 1996, Declan B. McCullagh wrote: ^^^^^^^^^^^^^^^^^^^ > >> An alternative I am considering would reduce the utility of the remailer >> while still allowing these "consensual" uses to continue. Presently the >> remailers deal with abuse via "block lists", sets of addresses that mail >> can't be sent to. Generally these are created when someone complains >> about some mail they have received. By setting up blocking, at least >> they will not get harrassing anonymous mail once they have complained. >> But in some cases, as in the case that is causing me headaches now, even >> one message is too much. >> >> My thought is to turn the block list concept on its head, and make it a >> "permit list". Simply, the remailer will only send mail to people who >> have voluntarily indicated their willingness to receive it. You reply-quote process must have been hit with an alpha particle, because all of this was written by Hal Finney, not Declan. --Tim 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: Rumor: DSS Broken?
by Deranged Mutant 17 Dec '03

17 Dec '03

On 19 May 96 at 21:48, Tim Dierks wrote: [..] > PPS - Any chance the original rumor surrounded RCA/Hughes' DSS satellite TV > system, and not the Digital Signature Standard, and we've all been barking > up the wrong tree? Hm. Check the cable/satellite tv newsgroups. 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

Re: CAPITALISTS' SUCK
by Deranged Mutant 17 Dec '03

17 Dec '03

On 20 May 96 at 4:07, Dave Harman wrote: [..] > ! >Dave Harman writes: > ! > > ! > CAPITALISTS' SUCK > ! > ! What witty social commentary. > > Information wants to be free. Information doesn't want to be free (or anything else) anymore than the stapler on my desk wants to be free. The day that abstract qualities like "information" or "color" have desires would be an interesting day indeed. And that has little to do with who or what the capitalist down the street is sucking. --Mutant Rob

2 1

Hiding remailers behind nymservers...? (fwd)
by Jim Choate 17 Dec '03

17 Dec '03

Forwarded message: > Date: Mon, 20 May 1996 18:53:15 -0700 (PDT) > From: Steve Reid <root(a)edmweb.com> > Subject: Hiding remailers behind nymservers...? > > This 'middle-man' remailer... What does it really accomplish? Sure, the > operator is hidden, but that's only because of his/her nym at c2.org... > AFAICS, the 'middle-man' has just taken the liability off himself and put > it on the unhidden remailers. Why not just use the existing unhidden > remailers??? > The first thing it accomplishes in my mind is establishing pre-meditation to conspire to the commission of a felony. Jim

1 0