- cypherpunks-legacy - lists.cpunks.org

Re: Paranoia and Cypherpunks
by bwebster＠pages.com 30 Nov '92

30 Nov '92

> (Surely John Gilmore's lawsuit to get some critical crypto papers > declassified has already "angered" the folks at NSA. Are we to > censure John for stirring up trouble? Buy him a really nice dinner would be a more appropriate response. :-) 'Way to go, John! ..bruce.. --------------------------------------------------------------------- Bruce F. Webster | We hackers linger by our leading edge Chief Technical Officer | Forgetting what is pending in the cache Pages Software Inc | Till practice hurtles past us, bwebster(a)pages.com | and we crash. -- Jeff Duntemann ---------------------------------------------------------------------

1 0

Re: Secure Key exchange
by pfarrell＠cs.gmu.edu 30 Nov '92

30 Nov '92

tytso(a)ATHENA.MIT.EDU (Theodore Ts'o) wrote: quoting: pfarrell(a)cs.gmu.edu (Pat Farrell) I sign keys only when I am certian that the key belongs to the human who claims to have the name on the key. There are not a lot of keys signed by me floating arround, maybe six total..... tt> tt> Ah, but how do we know that it's really you making this statement, and tt> not some evil NSA spoofer? What people need to do is to make their tt> key-signinging policies available _signed_ with their private key; that tt> way at least we would know that the entity signing the keys and the tt> entity claiming that this is its policy are the same. Exellent point. I'll put a signed statement of my policy in my .plan. It won't add many characters, and anyone can find it by fingering me. (and I've never claimed I don't work for NSA/CIA/...) tt> This helps, but tt> we would then still need to trust that the entity is telling the truth tt> insofar as its key-signing policy is concerned. I can't solve this one so easily. I have two ideas that can help: 1. change PGP in future versions (starting with 2.1?) so it doesn't ask for confirmation every time a key is added to the ring. Make the user do an active action, rather than a half-asleep y<cr> to sign a key. 2. store a comment in my secret ring that is captured each time I sign a key. Thus I could store the "reason/justification" for the signature to jog my memory. I know whose key's I've signed now, but as the number gets bigger, then I'll need a memory aid. I suggest the secret ring, as I share my public ring, and don't think that why I chose to sign a key should be generally available. If this were supported, you could then send me a msg asking "why did you sign John Doe's key?" You would have to compare my answer to my published policy and make your own judgement as to whether I follow it. I could keep track of this manually, and should. But PGP already requires me to have a lot of files arround. Pat Pat Farrell, Grad Student pfarrell(a)cs.gmu.edu Department of Computer Science, George Mason University, Fairfax, VA PGP key available via finger or request #include standard.disclaimer Write PKP. Offer money for a personal use license for RSA.

1 0

Re: Secure key exchange
by karn＠qualcomm.com 30 Nov '92

30 Nov '92

How byzantine! PGP 2.1 will have a much more convenient facility for verifying public keys that you receive over the network. If you say "pgp -kvc karn", for example, it will display the MD-5 hash of karn's public key as 16 hex bytes. If you know the sound of my voice, you can call me on the phone and have me read off the hash code that I compute here on my key so you can compare it to the value you computed. If they match, you can sign my key with reasonable confidence. About the only way to defeat this system is for the bad guy who feeds you the bogus key in my name to come to my house and hold a gun to my head as I receive your phone call. I would much rather trust a simple verification procedure based on redundancy and close personal relationships than a single, complex, impersonal process involving people I don't know. This is not to impugn your integrity, of course -- I'm simply speaking on principle. People need to be very selective about the signatures they sign, otherwise they will become meaningless. I've already had people sign my public key without any verification that it is legit. This is a no-no. I am bothered by the message that PGP currently generates when it reads in some new public keys asking if you'd like to certify each new key. Even though the default is "no", it makes it too easy to sign a key without really verifying its authenticity. Phil

3 2

Re: The Cypherpunks Mail Project
by John W Noerenberg 30 Nov '92

30 Nov '92

At 8:07 PM 11/25/92 +0000, Tony Kidson wrote: > >I'd like to chip in here, in my _very_ newbie way, that not >everybody is running a unix system with the ability to pipe >things between processes in so facile a manner. Good point. My vision for the Mac is to have a PGP service with an AppleEvent suite defined so that any other AE-aware program can use the services. This isn't trivial, but it is the right thing to do, imho :-). john noerenberg jwn2(a)qualcomm.com noerenberg.j (Applelink) =========================================================== Do not uselessly lament your luck that is giving way, your work that has failed, your life's plans that have all ended in despair. Like a man long prepared, like a man of courage, bid her farewell, the Alexandria that leaves you. -- "The God Abandons Anthony", Constantine Peter Cavafy [1911] ===========================================================

1 0

Electronic Banking
by ghsvax!hal＠uunet.UU.NET 30 Nov '92

30 Nov '92

Some time back Tim May suggested that we should do some experiments with electronic cash. He offered to do some Xeroxing if people would "pay" him. There are lots of proposals for electronic cash in the literature, mostly very complex. I think one of Chaum's simpler proposals would be adequate for email "banking". This proposal, from the beginning of his paper "Untraceable Electronic Cash" in Crypto 88(?), goes like this: 1. Alice chooses a random x and r, and supplies the bank with B=r^3*f(x) mod n, where f is a one-way function (like MD5), and n is the modulus for the bank's public key. 2. The bank takes the third root of B (e.g. via an RSA decryption) and sends it back to Alice: D = r * f(x)^(1/3), and withdraws one dollar from her account. 3. Alice extracts C = f(x)^(1/3) by dividing D by r. (Note that division can be done mod n without knowing the factors of n, but it's rather complicated.) 4. To pay Bob one dollar, Alice gives him (x, C). 5. Bob can verify that C = f(x)^(1/3), but he still has to send (x, C) to the bank in order to make sure that x hasn't been used before. Otherwise Alice could spend (x, C) twice. The bank increases Bob's account by one dollar. This scheme is pretty simple and provides untraceability - the bank saw B and D but not C, so although it can verify that (x, C) is legit, it can't correlate that with Alice's withdrawal. The main disadvantage of this approach is that Bob has to send (x, C) to the bank right away (or at least before sending Alice anything in return for her cash) to verify that the cash hasn't been used before. But in email, where turnarounds of a day or more aren't unusual, this should be tolerable. Alice and Bob could be pseudonyms, using anonymous addresses to communicate with each other and with the bank. Different denominations of cash could correspond to different exponents than "3" in the example above. (That is, $1 would use C=f(x)^(1/3), $2 would use C=f(x)^(1/5), $4 would use C=f(x)^(1/7), and so on.) Technically, this would be quite easy to implement, using the code in PGP for the arithmetic, and MD5 for the one-way function. We'd need to define a few message formats. The RFC1113 ascii encoding from PGP could be used as well. The "social" problems are more challenging, it seems to me. What is the backing for this electronic money? Why do people care what their bank balances are? Is this stuff really worth anything? One possibility is to base digital cash on real money. People would open a pseudonymous account via email, then postal-mail dollars to the bank, enclosing their account number so the bank would know whom to credit with the deposit. Later, if someone wanted to withdraw "real money" from their account they would have to give a real postal address where it could be mailed. Now the electronic money is worth real dollars. Even if people didn't deposit or withdraw very often, it still has value because of the backing. Unfortunately, this approach would currently be illegal (at least, unless you actually were a real bank!). If there were some way the bank itself could be anonymous, it might survive, but I don't see how to mail it money while keeping the anonymity. Still, we could consider experimenting with this on a small scale with accounts of no more than a few dollars. As long as it was clearly an experiment I doubt that any prosecutions would result even if it attracted government attention, because the expense involved in court costs would be so disproportionate to the few dollars involved in this technically illegal act. Another approach would be not to try backing the digital cash at all, or rather backing it implicitly by the determination of various people to accept it and perform services or supply goods in return for it. Tim's offer to Xerox papers in return for digital cash would be one example. Perhaps others could provide some other services. It would be great if some shareware author would accept digital cash as a symbol of support for crypto anonymity. One problem that I see with this approach is how you determine the size of the money supply. Or, in other words, how does new digital cash get started circulating? How do people get new accounts, and how much money is in them? If these problems can be solved, a big advantage of this approach is that the banker can be anonymous. He would be known only by his anonymous address and his public key(s). This would provide some safety in the event that even a small-scale experiment like this was targetted for a crackdown. Another issue is the prospect of multiple "banks", each issuing their own (incompatible) cash. How would they compete? Perhaps in terms of rapid turnaround? Some might choose to be anonymous, others would go public. The latter would have the advantage that people might trust them more, but OTOH there is more chance of your bank account disappearing after a crackdown for a public bank than an anonymous one. Lots to think about here! Hal 74076.1041(a)compuserve.com

5 4

RE: PGP on local machine (was Re: MacPGP)
by lasterm＠ohm.ee.utulsa.edu 30 Nov '92

30 Nov '92

folders a

1 0

Re: Secure key exchange
by George A. Gleason 30 Nov '92

30 Nov '92

Edgar- Two possible points of critique in an otherwise good idea. 1) HOME Address?! As I've said before, that's arguably your most secure datum since it's where you keep your soft, squishy body, and where the baddies and black-baggers and so on would just looove to know where to find you. Let's not make it any easier for them. 2) "I certify that I'm not a cop or spy." That doesn't and hasn't ever held up in any court in the land. Plenty of precedent in drug case law. "I want to buy some pot." "Okay, first tell me under oath that you're not a nark." Result: nark laughs all the way to the police station, with fresh catch in handcuffs. We can't keep them out, and at some future time might want to open up a dialog with the LE community on various issues. No point looking like a conspiracy if we aren't one. -gg

1 0

Some hacked scripts for the remailers
by Bill O'Hanlon 30 Nov '92

30 Nov '92

Here's a couple of real rough Bourne shell scripts to get some mail to go to both Hal's and my remailers. Not too helpful if you don't have a unix machine around--sorry. Nothing fancy, but it'll keep the mental confusion down when trying to put a message together. First is twohop... ------ Cut here ------ #!/bin/sh # Two hop anonymous remailer hal's first, then rebma ... if [ $# != 2 ] then echo Usage: twohop message-file-name destination-address exit 1 fi message=$1 dest=$2 t1=twohop.1 t2=twohop.2 # if the "remailing" and "remailer" names look odd--well, that's what hal's # and my respective keys for the remailers are named... encap $message $dest remailer $t1 encap $t1 remailer(a)rebma.mn.org remailing $t2 elm hal(a)alumni.caltech.edu < $t2 rm -f $t1 $t2 ----- Cut here ----- twohop calls encap twice. Encap is a more general and useful script. ------ Cut here ------ #!/bin/sh # # usage: encap message-file destination remailer resultfile # if [ $# != 4 ] then echo Usage: encap message-file-name destination remailer-key-name outputfile exit 1 fi mfile=$1 dest=$2 remailer=$3 result=$4 t1=encap.1 t2=encap.2 echo :: > $t1 echo Request-Remailing-To: $dest >> $t1 echo "" >> $t1 cat $mfile >> $t1 pgp -ea $t1 $remailer echo :: > $t2 echo Encrypted: PGP >> $t2 echo "" >> $t2 cat $t1.asc >> $t2 mv $t2 $result rm -f $t1 ---- Cut here ----- These seem to work for me... At least, a couple messages now have gotten back to me from them. They helped me get a couple problems out of the remailer. -Bill -- Bill O'Hanlon wmo(a)rebma.mn.org

1 0

UNSUBSCRIBE
by cmr!cmrp!berry_k＠mailer.cc.fsu.edu 29 Nov '92

29 Nov '92

unsubscribe berry_k(a)cmr.fsu.edu

1 0

unsubscribe messages
by Marc Horowitz 29 Nov '92

29 Nov '92

If you don't want to be on this list, that's fine. BUT PLEASE STOP CLUTTERING MY INBOX WITH THE UNSUBSCRIBE REQUESTS!!! I AND MOST OF THE OTHER RECIPIENTS OF THIS LIST CANNOT DO ANYTHING ABOUT IT!! There is a convention on the Internet that if there is a list called foo(a)bar.domain, the maintainers of this list will be on a much smaller list called foo-request(a)bar.domain. Send requests there to get added or removed, not to the whole list. If you get a bounce, then, and ONLY THEN, should you send to the whole list. So, if you want to get off the list, send mail to cypherpunks-request(a)toad.com. It's not hard. And it will keep large numbers of people from wanting to kill you. Flame off. Marc

1 0