December 2003 - cypherpunks-legacy

Re: CYPHERPUNKS TO THE RESCUE
by sidney＠taurus.apple.com 17 Dec '03

17 Dec '03

Sandy Sandfort <sandfort(a)crl.com> wrote: >Am I missing something here? Why would you need a clock? I recently used a smart card system for secure remote access to a network. It looked like both the card and the remote system had clocks that were in synch and both ran the same PRNG to produce a new number every minute. Part of the login procedure was to enter the number currently being displayed on the card. A garage door opener built on this principle would not need the ability for the base to transmit any codes, for the remote to receive any, nor to encrypt or decrypt anything. Just a continuously running, clocked PRNG, the ability for the base to receive signals sent by the remote and compare the numbers, and some provision for synching up the clock and state of the PRNG with that of the remote, probably using a physical connection. The remote would transmit a code to the opener. The code would be available to someone listening in, but it would only be valid for the current clock period. The length of the clock period would be a trade off: Too long, and someone could listen in and enter the garage after you have left but before the current code has expired. Too short, and you will have to synch up the remote and the receiver too often to be convenient. (I.e., if the clocks drift by four seconds per year, you can go quite a while with one number per minute, but less than a month at one number per second, before the system becomes unuseable without resynching.) There also has to be some provision for a retry if you happen to signal close to the transition time, within the period where they are out of synch. -- sidney <sidney(a)apple.com>

2 1

Re: New Threat on the Horizon: Software Key Escrow
by Matt Blaze 17 Dec '03

17 Dec '03

Tim May writes: >Diffie described in some detail a software-based scheme developed by >NIST (and Dorothy Denning, if I recall correctly) that, as I recall >the details, avoids public key methods. Perhaps this was also If it's the same scheme that I'm thinking of (that Dorothy Denning presented at the Karlshrue workshop), it was developed by Stephen Walker and David Balenson of Trusted Information Systems, in cooperation with NIST. It's a cute scheme - it doesn't involve secret hardware or algorithms, but does involve public key cryptography, roughly in place of the clipper unit and family keys. You can thwart the system with cooperation at both ends, but you can't interoperate with legal users; in this sense it's more robust against abuse than the Clipper hardware-based system The basic idea is that each user gets a unique public key from the government, which is used to encrypt the session key. You encrypt the session key with this key and send both it and the certified public key to the reciever, who verifies the signature to confirm that it really was issued by the government. Now the receiver also encrypts the session key and compares the result with what you sent, refusing to operate if they don't match. Of course, two parties can cheat by patching their verification routines. But it's very hard to interoperate with non-rogues. -matt

1 0

Encryption Algorithm for Pagers
by jgrasty＠pts.mot.com 17 Dec '03

17 Dec '03

Hello, all: I am looking for a simple encryption algorithm suitable for use in pagers. Ideally, the algorithm would need to have the following characteristics in order to be useful in pagers: 1. key size no larger than 64 to 128 bits; 2. decryption firmware 4k to 8k bytes in size for typical 8-bit microcontrollers (e.g. 68HC05); 3. decryption firmware able to run in near real-time with bit rates to 2400 bps with microcontrollers running no faster than 2 MHz; 4. encryption algorithm should run in real-time on 68000 class processors with capacity to support 8 2400 bps channels; 5. EXPORTABLE <-- yeah, I know First, a bit of basic information on how pagers and paging systems work. This is a gross oversimplification, but it'll do for this discussion. All protocols commonly used are all sent in the clear. A paging terminal collects the page, converts the PIN number into a pager capcode (address), encodes the message into the protocol used by the pager and sends the page over a phone line to one or more transmitters that transmits the page at the appropriate time (this depends on whether the protocol is synchronous or asynchronous). The paging protocol consists of a sync word (fixed string of bits), a capcode (address), and a message. In an encrypted paging system, all but the sync word would be encrypted. Each pager would have a single key for itself and a group key for group pages (pages that are sent to a group of pagers -- each group has a group capcode). The pager would decrypt each capcode and check to see if it matched that of the pager. If so, the message would be decrypted and displayed. The purpose of this request is to see if any existing encryption algorithms would fit this requirement, and if so, the amount of effort required to put this system into place. It is very important that the system be exportable. Let me know your ideas; post to cypherpunks or e-mail as you wish. If the information above is not adequate to suggest an algorithm, let me know and I can supply more information. Regards, Joey Grasty (jgrasty(a)pts.mot.com) Staff Engineer Asia Pacific Pager Development Motorola Paging and Wireless Data Group ------------------------------------------------------------------------------- I don't speak for the Circle-M | In memory of the 55.9 million victims of gun Ranch. | control this century. E-mail for details. -------------------------------------------------------------------------------

1 0

Re: New Threat on the Horizon: Software Key Escrow
by Jef Poskanzer 17 Dec '03

17 Dec '03

>The basic idea is that each user gets a unique public key from the >government, which is used to encrypt the session key. You encrypt the >session key with this key and send both it and the certified public key >to the reciever, who verifies the signature to confirm that it really was >issued by the government. Now the receiver also encrypts the session key >and compares the result with what you sent, refusing to operate if they >don't match. > >Of course, two parties can cheat by patching their verification routines. >But it's very hard to interoperate with non-rogues. I don't see any defense in this description against using someone else's public key. The feds could still decrypt such messages, but wouldn't know who was talking. At least not from the envelope. This could defeat casual mass traffic analysis by agencies who have the private keys, because they'd have to look inside the messages for identity cues. It could also defeat *all* traffic analysis by parties who don't have the private keys. That would make it preferable to Clipper. Or does the proposed system also have some authentication component? --- Jef

2 1

Re: LITTLE BROTHER INSIDE
by gtoal＠an-teallach.com 17 Dec '03

17 Dec '03

So, does anyone know what the record stay on comtempt charges is? i think it was 2 years. It was that famous case of the woman who wouldn't disclose her daughter's wherebouts. She kept getting slammed back until a higher court declared it unconstitutional to do indefinitely. However two years is two years too long in my opinion to spend in a state pen. G

2 1

Re: CYPHERPUNKS TO THE RESCUE
by jim＠bilbo.suite.com 17 Dec '03

17 Dec '03

Matt Blaze describes a couple of possible attacks against the simple one-way authenticating garage door opener. The attacks are basically the ones that are often suggested against one-way login authentication protocols. However, I think the garage door opener scenario is just different enough that the attacks he describes can be ignored or eliminated without overly complicating the devices. (The following idea is a combination of ideas stolen from earlier posts. plus a couple of new ones. Anyone following this thread should recognize the earlier ideas and hopefully mentally credit the original posters.) The transmission is one-way, from hand unit to base. There is no encryption involved, no hash functions, no counter values to transmit, no loosely synchronized clocks. The hand unit consists a transmitter, a memory chip, a simple cpu chip, and some kind of jack or plug used to initialize the unit. Initialize the hand unit and base with identical sets of large random numbers using a wall mounted panel. The random numbers will be arranged in groups of, say, ten. I'll call each group a "family". Since memory is cheap, load hundreds of families of random numbers. Both the hand unit and the base will maintain an internal counter of the "current family number". As numbers from a family are used, the "current family number" is incremented. If the two "current family numbers" get off, then the hand unit and base will have to be re-initialized. To open the door, push the button on the hand unit (duh) to send the first random number from the "current family". The base unit opens the door if the received number is in the "current family" of random numbers. If the door opens, the "current family number" counter in the base unit is incremented and the remaining numbers in the previous "current family" become invalid for opening. The "current family number" in the hand unit automatically increments after about a minute from the time of the button push. If the first button push/transmission didn't get received, a second button push (within a minute) will send another number from the same family, activating the door. If the first transmission is successful, but the driver continues to push the button, the subsequent transmissions are useless to an interceptor/man-in-middle because the numbers transmitted are from a family that has just become invalid for opening. To close the door (within a minute of opening): pushing the button sends another random number from the original family (i.e. the same family used to open the door, now invalid for opening). Since the door is in the open position, the base unit interprets the transmission as a request to close the door. NOTE: the base unit ignores all button pushes while the door is in the process of opening. WRINKLE: If you wait more than a minute before trying to close the door, the hand unit increments to the next family number. Therefore, when the door is in the open position, the base unit will actually check the received random number against both the previous "current family" and the current "current family". The major flaw I see in this scheme is that the "current family number" in the hand unit may become off frequently due to accidental button pushes. ... Now that I've gotten to the end of the description, I'm not so sure this scheme is practical. I get the feeling that the delayed auto-increment of the hand unit will create situations that violate the principle of "Least Surprise". In other words, the hand unit may not always do what you expect it to do. Oh well, I'll post my description anyways in case it induces some better ideas in others. Jim_Miller(a)suite.com

1 0

Government-Controlled Trust Hierarchies
by John Young 17 Dec '03

17 Dec '03

TC May wrote Wed, 27 Jul 1994 11:44: <I suggest we look very closely for connections between TIS and <Microsoft, Apple, Novell, Sun, and any other major OS providers. Scott McNealy, Sun Microsystems, writes in today's Wall Street Journal on what he calls Microsoft's "monopoly" of operating systems. He writes, in part: Quote: It's highly unlikely that the government will break up Microsoft. [. . .] But there are several important steps that would help: * If the "system calls" for Windows, Windows NT, Chicago and other future operating systems were in the public domain, Microsoft programmers would have no unfair advantage over competitors in writing applications. * A multi-organizational group, including representatives of government, consumer groups, academia and business, could establish policy guidelines on publishing the specifications to interfaces, ensuring that they are free for all to use and changed with timely notice, and that the changes conform to established industry standards. * As the single largest purchaser of desktop computer systems, the government could then decree that it will never buy another computer system with principal interfaces that do not conform to these standards. This would send an unmistakable message that open standards are the key to a free market. This point is especially critical to guaranteeing that the information superhighway allows competition, innovation and choice. End quote.

1 0

Continum of numbers and Turing Machines
by Jim choate 17 Dec '03

17 Dec '03

Hi all, Just a thought, Seems to me that a Turing Machine can't simulate a continous section of R for a simple reason, computers can only work on rational numbers and a continous section would have irrationals in it. Take care.

5 5

Re: CYPHERPUNKS TO THE RESCUE
by sidney＠taurus.apple.com 17 Dec '03

17 Dec '03

Jim_Miller(a)suite.com wrote: >The major flaw I see in this scheme is that the "current family number" in >the hand unit may become off frequently due to accidental button pushes. I think that a practical scheme has to be able to work when the button on the remote can be activated away from the garage door: What about kids using the remote as a phaser while playing a game of Star Trek, showing off your new cryptographic garage door remote to a friend, dropping a book on top of the remote in the car, being a little too hasty and pressing the button while still a few feet out of range of the garage door, a fidgety passenger picking up the remote and playing with it while in the car, etc.? -- sidney <sidney(a)apple.com>

1 0

XSPLIT now own ftp.wimsey.bc.ca
by rarachel＠prism.poly.edu 17 Dec '03

17 Dec '03

I just uploaded a short program I wrote called XSPLIT to ftp.wimsey.bc.ca. this is a simple crypto tool that splits a file into many files for secure distribution. A simple way of escrowing your data to the parties >YOU< only trust and who don't know each other. Whenever Gibson's idea of swiss like databanks will occur, you could encrypt your file, split it with XSPLIT and upload it to several such databanks. XSPLIT takes a file, generates n-1 random numbers, writes those random numbers out to each of the n-1 files, and for the nth file it takes the XOR of all N random numbers, and XORs it with the plaintext. This way, you get to split your file in such a way as to require all pieces of it in order to rebuild it. This is certainly not earth shattering, and is similar to what clipper uses, only its something you have available to you and something I wrote on a whim. Enjoy. (Source is included as usual and should be unix portable.)

4 6