January 1993 - cypherpunks-legacy

Re: more on security/obscurity/reality
by Daniel Ray 20 Jan '93

20 Jan '93

> >While what you say is certainly true, it won't survive any kind >of detailed attack. I'm all for the sentiment, but while there >are so many mundane things going on round about, the best way to >remain undetected is to remain undecipherable and to make sure >that there is enough traffic about of the same sort. Press for >encipherment of e-mail, that way, if everybody is doing it, who's >to know what the underworld is doing? This is especially useful >if you are not actually interested in violent revolution. You can >then convince the powers that be that you are not worth >monitoring. > >regards > >Tony this is dead on true. the whole problem of all this is our "transition period" until encryption is matter-of-course. and the possibility that serious opposition will actually arise to delay that day even further. once everyone does it, most of (but not all of) the special contingencies are unnecessary. what I am trying to address is how things are now, and how they may change one way, or another. and to find the best multi-solution for most of these possibilities....until that happy day you speak of. dan

1 0

Re: need for more anon remailer sites
by Daniel Ray 20 Jan '93

20 Jan '93

> >I suggest using a dictionary to come up with "names" of anonymous users: > >aback >abacus >abalone >abandon >abase >abash >abate >abater >abbas >... > >You could pick them in random order, or sequentially. > > ... > John Gilmore > certainly dictionary words are good, randomly, not in sequential order. But also usernames such as cs135 and anything else. The point is not to form any pattern distinguishable from the actual distribution of usernames in the real world. So some would even look like univ. course accounts, even with a couple "anon"-looking usernames thrown in! an analysis of actual usernames should be in order for this, and the actual types and probabilities.... in other words, take this situation full throttle! and of course, we need not give up our legal rights to use email. but we must, IN ADVANCE, be prepared and be already fully set for anything! dan

1 0

Re: random remailers
by Daniel Ray 20 Jan '93

20 Jan '93

>... >A difficult question to be sure. That's why I advocate giving the >choice to the user. > >-eric messick > DEFINATELY! Have a good, redundant system in place. Then let the chips--the users--and the usage--fall where it may... This makes things far more complex than any singularly organized method. dan

1 0

no to DES
by Daniel Ray 20 Jan '93

20 Jan '93

Maybe the general swing of some of you is to go with the "safer" RIPEM since it is less legally contested... But I won't trust it til it uses IDEA or triple DES or something much sounder than a 56 bit cipher. It is just too likely that this is readable by our big brother Nat Samuel Adams. dan

1 0

Q: What's happening in cryptography?
by Eric Fogleman 19 Jan '93

19 Jan '93

I'm interested in finding out what is currently happening in cryptography. My (basement-level) knowledge of it has come from heavy mathematics-oriented texts; these books and articles make it seem as though all of the work in cryptography is done by Ph.Ds at universities. I suspect that's not the whole story... Questions: - What companies, universities are doing work in cryptography? Are there people who get paid to "do cryptography" that don't work for the NSA? If so, where do they work? - Does cryptography fall under mathematics or computer science at most universities? - Are the real developments in cryptographic algorithms coming from the universities, from companies or from cypherpunks? - Any suggestions on what to read, who to talk to, what to experiment with to move up from basement-level knowledge of cryptography? Thanks... Eric Fogleman

2 1

Re: possible solution to the anonymous harrassment problem
by pmetzger＠shearson.com 19 Jan '93

19 Jan '93

> From: Rusty_H._Hodge(a)horizon.amgen.com > > >for example, i can send postal mail with high confidence > >of anonymity, and can make anonymous phone calls (with care, > >e.g., by using phone booths and moving around). > > What about that little old ladie that watches the PO Box and Phone Booth > from her window? What about the postman who sees you place the letter in > the mailbox? Any postman who can distinguish your plain white envelope at a distance from the five thousand other plain white envelopes going into the mailbox likely has sufficient psychic powers that he doesn't need to watch at all. As for the compulsive payphone watchers, well, wear a disguise. Perry

1 0

This Honesty Thing Again
by DrZaphod 19 Jan '93

19 Jan '93

In Message Thu, 14 Jan 1993 12:38:43 PST, horizon.amgen.com!Rusty_H._Hodge(a)netcomsv.netcom.com writes: > If people were totally honest, we wouldn't need such good encryption... I think we've gone over this b4. DrZaphod [AC/DC] / [DnA][HP] [drzaphod(a)ncselxsi.uucp] Technicolorized

1 0

Poor Man's Cash -> Poor Man's Wallet
by Jay Prime Positive 19 Jan '93

19 Jan '93

From: jpp@hermix To: CYPHERPUNKS(a)TOAD.COM In-reply-to: Hal's message of 17 Jan 93 13:47:45 EST <930117184744_74076.1041_DHJ40-1(a)CompuServe.COM> Subject: Poor Man's Cash -> Poor Man's Wallet Here is a minor change which can be used with the Poor Man's Cash protocol to increase the burden on banks which wish to trace transactions. I will call it Poor Man's Wallet protocol. Rather than maintain accounts, have the bank maintain only a map from bills to values. The bank will support three kinds of transactions: Combine, Split, Validate. To check that a bill is good, I ask the bank to VALIDATE b1. It responds with v and b2. V is the value of b1, and b2 is a new bill that has the value of b1 (- bank fee). (Naturaly the new value of b1 will be 0.) Worthless bills b1 could result in either a b2 with a value of 0 (thus issueing a new 0 worth bill) or with no bill at all. To add money to my wallet, I ask the bank to COMBINE a bill b1 from somewhere else, to a bill b2 from my wallet. Both b1's and b2's value get zeroed, and a new bill b3 with value = to v(b1) + v(b2) (- bank fee) is returned to me. To break a bill down to more convinient sizes (perhaps when I wish to pay some one), I ask the bank to SPLIT a bill b1 into b2 and b3, where v(b3) = v(b1) - v(b2) (- bank fee). It may be better (as far as anonymity goes) to require the bank fees be paid with a seperate bill. It will be better to have many banks, and to have the banks each validate bills of other banks. Since in this case your anonymity is the maximum of the anonymities of the chain of banks involved. j'

1 0

Re: possible solution to the anonymous harrassment problem
by Rusty_H._Hodge＠horizon.amgen.com 19 Jan '93

19 Jan '93

>for example, i can send postal mail with high confidence >of anonymity, and can make anonymous phone calls (with care, >e.g., by using phone booths and moving around). What about that little old ladie that watches the PO Box and Phone Booth from her window? What about the postman who sees you place the letter in the mailbox? >privacy and honesty are orthogonal. I've often accidentially overheard things I wasn't suppost to. If people were totally honest, we wouldn't need such good encryption...

2 1

Return envelopes.
by Hal 18 Jan '93

18 Jan '93

I looked at Eric Messick's improved ideas for remailing with digital postage, and they look pretty good. I think it's especially good that Eric has been able to show that anonymous addresses can be used by more than one person without being incriminating. But there is still an attack which they are vulnerable to, which Eric mentions. The "Pneed" field of the anonymous address has information about the postage amounts which will be needed by each remailer in the chain. (But it doesn't reveal which specific remailers to use, of course.) It also has public keys to encrypt these amounts with, which are matched by secret keys hidden in the encrypted address. But the remailers themselves each see their corresponding postage secret keys as they process the message. This means that they know which envelope was used to send each message. That means that each remailer can find out if it is part of a given anonymous address, and it can find out what remailers are before and after it in the chain. It is especially unnerving that the last remailer in the chain can learn this information, as it will see your true address. The one consolation is that it won't _know_ that it is the last remailer in the chain, so it won't realize that it has actually broken the code and is seeing the true correspondance between the anonymous address and the real address. But if most anonymous addresses only go through no more than a handful of remailers, say 10, then that remailer must figure that it has at least a 10% chance of having "broken" your address. This degree of information is more than I would like to have revealed about my anonymous address. Based on this, I would be inclined to use non-postage-charging remailers. But even the non-postage remailers have the same flaw using Eric's protocol. Each remailer sees the "clear text" of the message M being passed along. If a remailer sent the message in the first place, it created M, so if it then sees message M come through later, it again knows the correspondance between an anonymous address and its own forwarding activities. Chaum's scheme avoided this problem by having M get encrypted at each point. Using Eric's notation, an anonymous address might be: Addr: &Z, z, z(&R, r, A, r(junk)) The new addition is A, a random conventional key. Z gets sent: To: &Z Addr: z(z(&R, r, A, r(junk)), pad) Message: z(M, pad) This is just like Eric's example. What Z sends is: To: &R Addr: r(r(junk), pad) Message: r(A(M), pad) The new feature is that Z encrypted M with A as it passed through. In this case we only had a one-step anonymous address, but if there were more than one step, each would use a different conventional key A, B, C, .... This way even a remailer which created M wouldn't recognize it when it passed through after at least one step. Using this idea along with Eric's idea of random padding and double encryption at each step, we have multiple-use return addresses for which no information can be learned at any point about the correspondence between anonymous and real addresses, as long as the return addresses use at least two hops. Hal

1 0