- cypherpunks-legacy - lists.cpunks.org

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

Re: 5th AMENDMENT & DECRYPTION
by tony＠morgan.demon.co.uk 26 Jan '93

26 Jan '93

In message <9301260801.AA18233(a)netcom3.netcom.com> you write: > > > 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) .................. > > 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. ........ > bagged" the house, perhaps a simple pass phrase was used in lieu of > memorizing 300 digits, and so on. But what is encrypted with the 'simple phrase' is quite short and does not provide much material for cryptanalysis. Tony +-----------------+-------------------------------+--------------------------+ | Tony Kidson |`morgan' is an 8MB 486/33 Cat-| Voice +44 81 466 5127 | | Morgan Towers, |Warmer with a 670 MB Hard Disk.| E-Mail | | Morgan Road, |It resides at Morgan Towers in| tony(a)morgan.demon.co.uk | | Bromley, |Beautiful Down Town Bromley. | tny(a)cix.compulink.co.uk | | England BR1 3QE |Honda ST1100 ==*== DoD# 0801 | 100024.301(a)compuserve.com| +=================+===============================+==========================+

1 0

Re: 5th AMENDMENT & DECRYPTION
by tony＠morgan.demon.co.uk 26 Jan '93

26 Jan '93

1 0

Re: 5th AMENDMENT & DECRYPTION
by karn＠qualcomm.com 26 Jan '93

26 Jan '93

Mike Godwin (formerly, I understand) of EFF and I had a lively discussion on precisely this topic back at the Hackers' Conference. Mike insists that there is no firm legal theory or case law on which to base an assertion that the 5th amendment would shield you from being compelled to divulge an encryption key that could then be used to decrypt information to be used as evidence against you. He says that the closest the Supreme Court came to this issue was an offhand remark in a 5th amendment case to the effect that "of course, we couldn't compel the defendant to, say, reveal the combination on a lock". I forget the precise legal term that Mike used to refer to this comment, but he said it didn't establish a binding legal precedent because it didn't relate directly to an issue in the case at hand. 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. Don't give up working on those steganographic schemes just yet. And wherever practical (e.g., for communications as opposed to storage), use a key management scheme that doesn't leave anything around that can be seized or subpeonaed after the fact (e.g., Diffie's "perfect forward secrecy" scheme.) Phil

1 0

Re: This list...
by Phiber Optik 26 Jan '93

26 Jan '93

> > The whole point of this list is to develop techniques to ensure privacy -- > > most of us understand that there isn't much right now. > > but but but ... sendmail already offers an easy way to hide the membership > of a mailing list. why not use it? > > peter > Thank you. Welcome to the world of common sense. It's a given that certain things you just can't be secure against. But when you don't take every precaution, no matter how small, it's called laziness. Not fixing it with the excuse that people have to understand or accept the overall insecurity of things in general sounds pretty idiotic to me. It isn't such a big deal.

1 0