January 1993 - cypherpunks-legacy

manifesto
by P30TMR8%NIU.bitnet＠UICVM.UIC.EDU 26 Jan '93

26 Jan '93

how would I get a copy of the manifesto? Thanks, Micheal Roberts

1 0

Re: Rational PC mail , was Re: PGP on BBS
by pfarrell＠cs.gmu.edu 26 Jan '93

26 Jan '93

Jim, While serial ports do lose characters, especially if you don't have a 16550afn serial chip, I don't see this as a major hassle. In a pure DOS space, you really arn't likely to lose the characters, and this is the initial space of NUpop. With Windows, you have to learn to play with the priorities to make it work well, or get one of the intellegent serial driver DLLs that make it transparent. It is possible that the authors of the NUpop document don't worry too much about single character dropouts. There is plenty of redundancy in english. PGP will complain, but I can see retransmitting a message half a dozen times to get it thru cleanly will lose. I never allow my private key anywhere near a serial port. The public keys are checksummed, so it is easy to see that a character is wrong. I'd love to be able to use CSLIP. We (a bunch of folks on this campus) have just convinced the admin to allow POP services. It will take a while before we can convince them to allow SLIP, CSLIP, and PPP. In the meantime, I'll happily live with NUpop's serial support. Pat

1 0

Re: 5th AMENDMENT & DECRYPTION
by pmetzger＠shearson.com 26 Jan '93

26 Jan '93

> From: karn(a)qualcomm.com (Phil Karn) > > On the other hand, several other lawyers I've asked have responded "of > course!" when I ask them whether the 5th amendment would protect a > defendant from being compelled to divulge an encryption key without > immunity for the evidence it might decrypt. > > My own opinion, given that I seem unable to get a complete consensus > from the lawyers, (has this *ever* been possible?) is that the issue > is as yet untested in court and could go either way depending on the > actual case. But Mike seems much more pessimistic, and he *is* a > lawyer. I'm not. One might, of course, validly ask what the potential penalty would be for failing to divulge the key. Presumably, you would be held to be in contempt of court and sent off to jail until you divulged the key -- but at best you are likely to be locked up for a few months before the judge gives up. Given that, one can make a decision on whether the data you had encrypted is worth the loss of a few months of your life. (Remember, by the way, that merely having been in contempt is not nearly the same as having, say, a felony conviction on your record.) So even if they might have an argument for why they should be able to order you to give them a key, that doesn't mean that they have any real way to get it -- you can still fail to hand it over if you are willing to pay the price. Perry

1 0

Re: Computerized OTP (was 5th AMENDMENT & DECRYPTION)
by jim＠tadpole.com 26 Jan '93

26 Jan '93

> From: thug(a)phantom.com (Murdering Thug) > Since none of us have ever been inside the NSA, we cannot underestimate > their power and resources. For all we know they may have 500 Intel Delta > supercomputers linked together, each having 65,536 i860-XP/50mhz chips. > We really don't know what kind of iron they possess. Thus we can't assume > that they can't factor extremely large numbers easily. Um, I've been inside the NSA, (and I don't have a clearence.) They have a very nice visitors center, where they display some of their more arcane technology, along with little placards explaining what the hardware does. For instance, they display a very nice looking u-wave radio-based computer (complete with wax lenses), and a light-based floating-point engine that develops God-only-knows how many hundres Gflops, and yes, it can be custom programmed. They display a RISC core (of their own design) than also has a custom crypto unit on-chip, said unit can be field re-programmed. Also displayed are various arcane (antique) crypto devices. Jim P.S. Admittedly, I didn't get very far inside..

1 0

Re: Computerized OTP (was 5th AMENDMENT & DECRYPTION)
by jthomas＠kolanut.mitre.org 26 Jan '93

26 Jan '93

From: thug(a)phantom.com (Murdering Thug) tcmay(a)netcom.com writes: > > from: john.nieder(a)f33.n125.z1.fidonet.org > > (commenting on the strategy of "taking the 5th" on the matter of > decrypting one's files) > > > . Recently this question came up in another forum on encryption & an > > "authority" on communications law claimed the probable scenario would be > > that the arresting agency would have the encrypted material decrypted by > > a competent government or academic agency & the costs of said decryption > > would eventually be recovered from the defendant through civil suits, > > presuming the defendant had sufficient assets. It is my memory of the > > thread that he claimed this had been done in previous cases. > > With strong crypto, e.g., with 300 decimal digit moduli, the "costs" > of decryption by brute force could easily exceed the GNP/GDP of the > U.S. Since none of us have ever been inside the NSA, we cannot underestimate their power and resources. For all we know they may have 500 Intel Delta supercomputers linked together, each having 65,536 i860-XP/50mhz chips. We really don't know what kind of iron they possess. Thus we can't assume that they can't factor extremely large numbers easily. The only way to thwart the NSA is to use an encryption scheme which has been _proven_ uncrackable. The only one I know of is the One Time Pad. True, but impractical. I can't conceive of any rational one-time-pad key distribution over the net. Key distribution has to be over a guaranteed secure channel. For RSA, the channel only has to be authenticated. And if NSA can crack RSA, it would be worth having one cypherpunk lose one court case to find that out (yup, even if it's me...). Joe

1 0

Re: Rational PC mail , was Re: PGP on BBS
by jim＠tadpole.com 26 Jan '93

26 Jan '93

> From: pfarrell(a)cs.gmu.edu (Pat Farrell) > > With NUpop and Eudora, SLIP is optional. The NUpop docs say > that SLIP slows down the transfer, and recommends simple ASCII > async connection using a reliable modem (MNP or V42/V.42bis) I don't understand how the authors of this document can do so. Modern compressed-header SLIP implementations will compress the TCP/IP/SLIP headers down to 5 or 6 'bytes' (octets), on the average. In theory, I suppose its true, but in practice, it makes little difference. Even without header compression, and assuming minimal-sized datagrams, you end up with an overhead of 41/576. 93% of your bandwidth is still yours. A simple ASCII async connection using MNP or V.42 still violates the end-to-end argument. Serial ports can, and do loose characters. Leaving your encrypted message, or even your key, to the whims of a cheap modem, (you'll never know what the other guy has), or back serial drivers seems a bad idea to me. Jim

1 0

Re: This list...
by pmetzger＠shearson.com 26 Jan '93

26 Jan '93

> From: Peter Honeyman <honey(a)citi.umich.edu> > To: pmetzger(a)shearson.com > > eavesdropping on the list would not reveal lurkers. > > peter But eavesdropping on the mail coming out of toad.com would. In any case I think I've made my point -- its fine to patch holes, so long as one is aware that one hasn't given people a sense of false security in so doing. Perry

1 0

Hash Cash and Ripped Checks
by fnerd＠smds.com 26 Jan '93

26 Jan '93

Here's a form of digital cash and checks that takes off from Tim May's and Hal's ideas, and might have advantages, but uses crypto. I find it easier to understand than Chaum's method (but maybe the complexity vs. benefits make it the worst of all possible worlds...lemme know). Consider: This message can be exchanged for $x at Fred's Bank by the first person to present it along with a message whose MD5 hash is: h (Serial number: n) Digitally Signed, Fred's Bank Think of this as the right half of a $x bill that's been ripped in half. The hash is the shape of the rip. The bill is valid if you're the first one with both matching halves. The left half is blank (a random message that hashes to h). TO VERIFY: take a new piece of paper, rip it in half (generate a random number, take its hash). Send both halves of the old bill, plus the right half of the piece of paper (the new hash), to the bank. The bank either says the old bill was spent*, or sends back the right half with the same amount and their signature. Now only you have the whole new bill. CHECKS: ask the payee to give you a blank right half. Pay the bank to fill it in. The payee can verify that it's good without taking it to the bank. STAMPS/TOKENS/GIFT CERTIFICATES: The payee gives you a pack of right halves. You turn them to checks later. They might include a serial number with each one and ask you to give it back with the check so they can look up (or regenerate!) the left halves easily. They might even insist that you use the hash/serial # pairs in sequence! (Or is crypto- strong hashing of serial numbers too much to ask?) There are even more compromises of anonymity here than with Tim and Hal's ideas--I assume some compensation with remailers, as Hal suggested. I was thinking you could launder money by buying checks from Bank B with checks to Bank B that are drawn on Bank A, etc. A similar form would be something that said: This message can be exchanged for $x at Fred's Bank by the first person to present it signed with the private key that matches this public key: k (Serial number: n) (pad) Digitally Signed, Fred's Bank This would let you buy checks to random strangers without having to transact anything with them first, but it's sure obvious who the check is to. *Maybe you'd send the right half, then the bank would either prove that it already had the left half, or you'd proceed as above. -fnerd quote me fnerd(a)smds.com (FutureNerd Steve Witham)

1 0

digital bank
by Karl Barrus 26 Jan '93

26 Jan '93

-----BEGIN PGP SIGNED MESSAGE----- Fellow cypherpunks: I have been working on a digital bank, implementing Hal Finney's simple bank protocol (random account number and random digicash - not Chaum's more sophisticated system based on RSA encryption, decryption, blinded messages, etc.) The enhancement posted by ?? - I can't remember right now - (having to do with wallets) is not implemented. I beleive it is ready to enter the next test phase: everyone on the list may apply for an account. Send a message of this form to the anonymous remailer I run (elee7h5(a)rosebud.ee.uh.edu) : :: command: help user@host Be sure to include your real mail address in the user@host line, because that's where the bank will send back the information. /-----------------------------------\ | Karl L. Barrus | | elee9sf(a)menudo.uh.edu | <- preferred address | barrus(a)tree.egr.uh.edu (NeXTMail) | \-----------------------------------/ -----BEGIN PGP SIGNATURE----- Version: 2.1 iQCVAgUBK2VsWoOA7OpLWtYzAQGCTQQAlM3qhbcO2DvAAIGunmoVMYdHhTISS+7w YOq7oUoWU9Ys8kSaQMIHEmoaNITnaK5VZBIEbOdbI8oWzyUBkuKmPk+n8+SBr8PD KCs2ULSm6fqQ9nOe0sqOa8U0F6Q8Pij7YLjbdApeSjKA32XcnT4PcVq/iCP0HhBn svCTwLiXXIA= =9mlF -----END PGP SIGNATURE-----

1 0

No Subject
by veritas!u.washington.edu!news＠markv.com 26 Jan '93

26 Jan '93

1 0