- cypherpunks-legacy - lists.cpunks.org

Re: Traveller's Checks...
by Peter Wayner 19 Aug '93

19 Aug '93

Many banks make money on float. Could digital cash pay interest? I guess the bank could append a date to the cash and mark up the value when it is "spent", but that might compromise some of the anonymity. I'm sure the bank would volunteer to guard our anonymity in the strictest sense by not paying the interest. -Peter

1 0

new tran
by cme＠ellisun.sw.stratus.com 19 Aug '93

19 Aug '93

I've just modified tran to operate off the histogram of inputs and have posted the code to sci.crypt. It's also available from me by e-mail. - Carl

1 0

Cypherpunk DES distributed DES last post
by nobody＠alumni.cco.caltech.edu 19 Aug '93

19 Aug '93

Since the list keeper has requested, let us let the DES parallel breaking die, for the time being at least. I mentioned a possible Cypherpunk project to set up a network of parallel DES de-cryptors linked by cryptographically secure anonymous remailers to avoid obvious detection (although one could argue all those flops in the night might speak for themselves). A quick test shows the Sparcstation IIPX doing about 100 decryptions per second in a typical unloaded system from a user account (these are relatively small decryptions...we assume here we are decrypting a text which only a small portion needs to be decrypted to reveal its appropriate entropy measure). Or over eight unused hours at night, in the neighborhood of 3 million decryptions. Let's even assume we can marshall 5000 similar machines through our combined talents, that's 15*10^9 decryptions. Keeping in mind the total 56-bit keyspace is 72*10^15, we're still talking around 5 million nights to solve the problem (~13,000 years). If we want to solve one system per month, it looks like we can only handle about 38 bits worth of keyspace. Not very impressive. So, until the next technological leap, we can probably forget about this.

1 0

Traveller's Checks...
by Peter Wayner 19 Aug '93

19 Aug '93

I think that American Express wouldn't be interested in anonymous cash because the most important "feature" of a traveller's check is the lack of transferability. Once they're bought, only one person can spend them. Still, there might be people interested in anonymous approaches. -Peter

1 0

Re: Physical to digital cash, and back again
by nobody＠shell.portal.com 19 Aug '93

19 Aug '93

As usual, Hal Finney writes an excellent post on digital cash. However, some assumptions need to be addressed. > [triangle model divides the world into banks, shops, and customers] > Customers would thus primarily turn real cash > into digital cash which they send to vendors; the vendors then turn the > digital cash back into real cash. In its first few years of operation (at least), a digicash currency will be of highly uncertain value and reputation: Currency will: * Be of questionable legality in some jurisdictions. Once they catch on, governments will actively suppress it. * Lack a track record. * Be able to purchase only a limited number of specialized information services -- the customer won't be able to use it to buy groceries, make house or car payments, etc. Thus, as a customer, the *first* thing I will be concerned about is the ability to convert my digital cash into currency that can be used to purchase physical goods & services in my local jurisdiction. Specific application #1 -- an information worker or contractor being payed in digital cash will want to convert that digital cash into local currency, early and often. Specific application #2: customer deposits money into an account to pay for online services. In most cases the customer will be concerned about refunds and return of unspent funds. Specific application #3: on-line casino, with digital cash chips. Casino customers' first priority will be the ability to "cash out" with as little hassle as possible. Now we could stretch things and call the person who wants to cash out the "shop" (especially for case #1), but then the necessity of a user-freindly system would apply just as much to shops as it would to customers. Better to have a symmetric relationship between agents rather than dividing the world into customers and shops. Any of these agents may wish to make payments in either direction. In many cases the amount of payments will be quite assymetric, but in most cases the ability to make secure payments both ways should exist. This gives us the following model: (using FRNs as the local legal cash currency): ------- | | v | FRN bearer acct <--> d-cash acct <-> agents | ^ ^ | | | | v ------- physical cash > [customer] sends another check > to the bank and gets another batch of digicash. Not a good idea, checks are not private! Try cash or money order.

1 0

Digital money prototypes
by hkhenson＠cup.portal.com 19 Aug '93

19 Aug '93

I wonder if the various precidents set by traveler's checks might be useful in developing digital money. If American Express (or some similar) got into the game, it would be rather interesting. Keith

1 0

Re: Cypherpunk Chip
by cme＠ellisun.sw.stratus.com 19 Aug '93

19 Aug '93

On Aug 19, 12:18pm, peter honeyman wrote: > Subject: Re: Cypherpunk Chip > how important is the prng aspect of tran? presumably des-cbc does > a good job of bit diffusion. why is it better to tran than to > "dd conv=swab" or rot13? (or even to do nothing at all, simply > des-cbc|des-cbc|des-cbc?) > > peter >-- End of excerpt from peter honeyman I did a version of tran which did 4 rounds of an FFT-style butterfly. This achieves maximal mixing. However, it's predictable -- therefore easier to cryptanalyze (not that I'd care to try it :-). DES does a fine job of bit diffusion, within its block. (for CBC, that includes the rest of the stream -- if you hide the ciphertext from the cryptanalyst, so he can't XOR it out again) tran moves bytes of DES output around so that they can expect to have new neighbors for the next round of encryption. This produces diffusion. The actual diffusion of tran is less than that of the FFT-butterfly. However, for the cryptanalyst, there are more possibilities. Any byte can go anywhere within the 8KB block. With the FFT, each byte goes to a known location and gets diffused with 7 neighbors by the next round of DES. - Carl

1 0

Re: Cypherpunk Chip
by peter honeyman 19 Aug '93

19 Aug '93

how important is the prng aspect of tran? presumably des-cbc does a good job of bit diffusion. why is it better to tran than to "dd conv=swab" or rot13? (or even to do nothing at all, simply des-cbc|des-cbc|des-cbc?) peter

1 0

Cypherpunk Chip
by MIKEINGLE＠delphi.com 19 Aug '93

19 Aug '93

I'd like to propose a Cypherpunk chip to take the place of the Clipper chip. This could go a long way toward bringing the Cypherpunk vision to life, and it could also make someone a fortune. But first, I'm going to flame a bit. Even without key escrow and secret algorithms, Clipper is no good. The Clipper chip uses a conventional single-key algorithm, so if you want to use it with public-key, you have to do the RSA operations in software. This makes it vulnerable to tampering and key stealing. Clipper is essentially a beefed-up DES with a built- in spy hole and a classified "trust us" algorithm. The NSA seems to believe that only their classified algorithms are unbreakable. This is not true. We don't need to trust the NSA to give us an unbreakable single-key cipher. What we need are two good, respected ciphers and a simple reorganization operation. Choose, for instance, IDEA and triple-DES. Both are good algorithms. They have keys which are long enough to rule out any possibility of a brute-force attack. They are resistant to known methods of cryptanalysis, including differential cryptanalysis. They have good dispersion and produce pseudo-random ciphertext. Whether the NSA could break either of these, using a classified method, is pure speculation. IDEA and triple-DES are very different algorithms. DES is based on bit manipulation and permutation tables, whereas IDEA uses 16-bit arithmetic operations. This is good, because it means that if either algorithm has a flaw, the other one is not likely to have the same flaw. Take a 64-byte section of plaintext. Encrypt it using triple-DES. Now, reorganize the ciphertext: take the first byte of each 8-byte DES block (bytes 0,8,16, and so on) and make the first 8 bytes of the reorganized section. Repeat with the second, third, etc. until the entire 64 bytes are reorganized. So: 0 0 0 0 0 0 0 0 ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789!@ becomes: AIQYgow4BJRZhpx5...and so on. Then, re-encrypt the section with IDEA, producing double-encrypted ciphertext. Suppose you now change one bit in the ciphertext and decrypt it. When you decrypt IDEA, you get one 8-byte block of garbage (which is indistinguishable from the rest of the still-encrypted data). When you undo the reorganization, you get one bad byte in each DES block. So when you DES decrypt, you get 64 bytes of garbage. This compound cipher is effectively a 64-byte block cipher, in that every bit in the 64 bytes depends on every other bit. This means that you would have to attack a 64-byte section i.e. you would need 64 bytes of plaintext to attempt a plaintext attack. And even if you had the 64 bytes, you probably couldn't do anything with it. If you found a weakness in either cipher that allowed you to attack it, the same weakness would not exist in the other cipher (since they are based on different methods). So you could not attack the compound cipher. For this reason, a combination of two ciphers, especially with the reorganization, should be much more secure than one cipher. If I had to choose a cryptosystem to bet my life on, I'd choose this above Skipjack any day. Of course, it would be slower than a single cipher, but there are ways to make it usable. For example, the reorganization would be performed by straight-line assembly language, with no loops. And the encryption program would use a large disk buffer. Or, better yet, use hardware. See below. The Cypherpunk Chip Why couldn't we make a chip of our own, with some venture capital? This would be a public-key encryption chip, with all the necessary hardware self-contained, which would make secure phones, faxes, computers, and everything very easy. RSA Data Security could make a fortune if they received only a small royalty on each one sold. The design of the chip would be extremely public and readily available. Any company could produce them if it was willing to pay for the use of the RSA algorithm. The chip would contain a hardware true-random-number generator; facilities for executing RSA; MD5 or another message digest; and an extremely secure conventional cipher such as the compound cipher mentioned above. It would also contain nonvolatile (flash ROM) registers to store its public key and secret key. Hardware random numbers can be generated by several methods. One is to measure the jitter in an unstable oscillator. Another is to reverse bias a diode, right on the edge of zener breakdown, causing it to produce white noise. These methods can be proven by quantum mechanics to be inherently random. The chip would be sold blank - no serial number or anything. The user would instruct it to initialize itself by generating a key pair. It would do this internally, producing and remembering a public key and secret key. This might take a while, but you only have to do it once. When this is finished, you can easily extract the public key, but there would be no way to extract the secret key from the chip. The chip would be designed to make it very difficult and expensive to extract the secret key by physical surgery, thus making key stealing hard. The secret key would be stored internally in encrypted form, using a pass phrase much like PGP does, and the chip would decrypt it before each operation. In addition to the initialization, there would be five basic operations. The chip could output its public key, encrypt, generate signatures, decrypt, and check signatures. To encrypt, you would send the chip one or more public keys for people you want to send to. It would generate a random session key, and output the session key RSA-encrypted with each of the provided public keys. It would never reveal the actual session key. Then the chip would accept plaintext, 64 bytes at a time, and output ciphertext. When the encryption of a particular message was finished, the chip would forget the session key. To sign, you would send the text to the chip, along with the pass phrase, and it would run the MD5 algorithm on it. When finished, it would output the signature, the MD5 encrypted with its secret key. To check a signature, you would send the text, signature, and public key, and the chip would output good or bad. To decrypt, you would send the ciphertext and pass phrase, and the chip would output the plaintext. This chip would do basically what PGP does, except that it would be self-contained, very difficult to steal keys from, and easy to use in any device. The chip would not need to be hard-wired into a device. It could be built into a card or other plug-in module, perhaps PCMCIA compatible. You could use this as an electronic identity, while retaining the option to remain anonymous by getting a second card and generating a new identity. The card might also contain a memory for other people's public keys. You could, for example, insert the card into a pay phone and dial your pass phrase. This would secure the call, allow you and the recipient of the call to verify each others' identities, and pay for the call with digital cash. If this chip existed, "crypto-anarchy" would be easy. Everyone would have a motive to use it. There would be no more credit card fraud, no more phone-code fraud, no more bad checks, no more hacking, no more surveillance, etc. The chip could make it happen. We cipherpunks could actually win. The chip would be introduced in a low-key way. We would let the market see its advantages and jump on it, before the bad guys recognized the threat. For example, it could be introduced as an option for computers - plug it into a PCMCIA card slot and use it to secure E-mail, your hard drive, etc. Don't advertise what it could become; just let it happen. When we get it started, it will happen by itself. < mikeingle(a)delphi.com >

2 1

World record in password checking
by gtoal＠an-teallach.com 19 Aug '93

19 Aug '93

> You can do even better if you happen to have 2000 sparcstations which > are idle for 16 hours a day. Myself, I wonder how many machines we > would need for a net parallel DES crack. > > Perry Hmmm.... shouldn't be hard to organise either - everyone adds a crackd daemon to their inetd.conf... hey - even better - we make it an extension to 'sendmail' and put it in the default distribution bwahahaha ;-) G === Personal mail to gtoal(a)gtoal.com (I read it in the evenings) Business mail to gtoal(a)an-teallach.com (Be careful with the spelling!) Faxes to An Teallach Limited: +44 31 662 4678 Voice: +44 31 668 1550 x212

1 0