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

Garage Door opener, etc...
by Jim choate 17 Dec '03

17 Dec '03

Hi all, Seems to me the way to do this is to 'dock' the receiver and xmitter prior to leaving (could rationalize it by also doing battery charging at this time) and each time they share a unique one-time pad. Plug-N-Play so to speak... Take care.

2 2

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

Re: CYPHERPUNKS TO THE RESCUE
by Matt Blaze 17 Dec '03

17 Dec '03

norm(a)netcom.com (Norman Hardy) writes: >At 09:51 1994/07/26 -0400, Russell Nelson wrote: >>Why not generate a random number, checksum it, and sign it using a >>public key? Or is that overkill? >... >Seems good. But to thwart replay of the signed message the garage unit must >never accept the same signed number twice. How about the car unit signing >successive numbers. The garage unit would remember the last number that it >accepted and only accept signed numbers larger than that. Garbled >transmissions would then cause no problems. They would be fixed by yet new >transmissions, just as with current units. > As Eric Hughes points out (a couple of messages after these), you don't need public-key signatures for this; any secret key cipher or hash function will do, since the base and remote trust each other unconditionally (at least for garage doors; nuclear weapons may be a different story). Both base and remote need to store a shared key and a counter; the remote needs a transmitter and the base needs a receiver. To authenticate itself, the remote sends {counter, hash(key,counter)} and then increments its counter. The base calculates the hash for the received counter value, verifies that it matches the received hash value, verifies that the counter increases the stored counter value, stores the new value, and opens the door. A practical system system also probably include some mechanism for rekeying and for zeroizing the counters. There is no need for public key cryptography, two way communication (except for key setup), synchronized clocks, or extensive storage at either side. This protocol as described is very simple, almost trivial; given the right constraints it follows almost directly from the problem. I mention it because very small variations and poorly chosen parameters render it vulnerable to several classic protocol failures. First, observe that this system has a work factor to break of no more than the SMALLER of the secret hash key and the size of the hash output. Clearly, a single {counter, hash(key,counter)} message contains enough information to permit an conventional exhaustive search for key. If the hash space is too small (say, 16 bits or so), the adversary can select an unused counter value and probe the receiver with random hash values until the door opens. Worse, if the bad guy selects a counter value that is much larger than the remote's counter value, it has the added bonus of denial-of-service to the real user. Also, note that the order of operation on the receiver's part is critical. If the received counter value is stored BEFORE the hash is received, we are also vulnerable to denial-of-service (but at least not false authentication). Finally, there is the "man in the middle" attack, in which the bad guy intercepts a message intended for but never received by the base, records it, and plays it back later (but before the real owner returns to increment the counter again). A likely scenario involves pushing the button twice on return home, but where only the first message is received by the base. One way to deal with this is to encourage frequent resyncs between the base and remote; for example, the remote, when in the garage, could send periodic "null" commands that increment the counters without actually opening the door. (Of course, you'd need to make sure that these messages themselves cannot be used to construct spoofed open-door messages.) Basing the counter in part on a real-time clock would also help here, but again, this complicates the protocol greatly and increases the opportunities for both denial-of-service (if the clocks get too far out of sync) and false authentication (if the clocks get reset - say at daylight savings time...) My point is not that this is a particularly hard problem, only that even simple cryptographic protocols can have serious bugs. -matt

2 1

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

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: XSPLIT now own ftp.wimsey.bc.ca
by markh＠wimsey.bc.ca 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Subject: Re: XSPLIT now own ftp.wimsey.bc.ca > 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. I've placed it in /pub/crypto/software/dist/US_or_Canada_only_XXXXXXXX/Misc Thanks for the upload, Mark -----BEGIN PGP SIGNATURE----- Version: 2.7 iQBVAgUBLjW77mrJdmD9QWqxAQHSPAH/RX3f06P/SazTILG1ylSBxpN5yEkO0ALo e93PFbenwVLeOaC1+R+lXvvgC52Rg1cvqDswkuAc29NQTRXkCDVtzA== =E1mS -----END PGP SIGNATURE----- -- Mark Henderson markh(a)wimsey.bc.ca - RIPEM MD5: F1F5F0C3984CBEAF3889ADAFA2437433 ViaCrypt PGP key fingerprint: 21 F6 AF 2B 6A 8A 0B E1 A1 2A 2A 06 4A D5 92 46 low security key fingerprint: EC E7 C3 A9 2C 30 25 C6 F9 E1 25 F3 F5 AF 92 E3 cryptography archive maintainer -- anon ftp to ftp.wimsey.bc.ca:/pub/crypto

1 0

(None)
by Jeff Gostin 17 Dec '03

17 Dec '03

gtoal(a)an-teallach.com (Graham Toal) writes: > All sounds reasonble *except*... this is the internet, man! We can afford > to do this once every 15 minutes, can't we? Unless the messages are given a delivery latency of <insert random time>, Traffic Analysis will allow for the tracking of messages. If, OTOH, messages _are_ given a latency, but are garaunteed to be out of the remailer in, say, 12 hours, it makes the task of tracking messages anywhere from one degree more difficult to exponentially more difficult, depending on how many messages flow in 12 hours. If you allow for dummy messages to pad traffic, TA could be avoided almost entirely except by the most anal of attackers. --jeff -- ====== ====== +----------------jgostin(a)eternal.pha.pa.us----------------+ == == | The new, improved, environmentally safe, bigger, better,| == == -= | faster, hypo-allergenic, AND politically correct .sig. | ==== ====== | Now with a new fresh lemon scent! | PGP Key Available +---------------------------------------------------------+

2 1

No Subject
by merriman＠metronet.com 17 Dec '03

17 Dec '03

It has been brought up on the Cypherpunks mailing list that Microsoft is proposing to include public-key escrow as a *built-in* "function" of future products - Chicago and Daytona have been specifically mentioned. Is this, in fact, correct? If so, what constraints or limitations are there on it? Is it an optional capability, and if so, what means are there for disabling (or better still, completely removing) it? What organization(s) does Microsoft propose to use as the escrow agent(s) if such public-key escrow is implemented? What would be the system used (RIPEM, RSA, etc)? If not an existing algorithm, would the algorithm(s) be made public? What would be the key size of any such algorithm? I would appreciate any and all information you could provide regarding this _very_ serious matter. Please note that this message has also been sent to the Cypherpunks mailing list; I am quite sure that the subscribers there would be most interested in your answers (or failure to answer). I will also take the liberty of forwarding an unedited copy of your response to this message to the Cypherpunks mailing list. David K. Merriman merriman(a)metronet.com Finger merriman(a)metronet.com for PGP2.6ui/RIPEM public keys/fingerprints.

1 0

RE: New Threat on the Horizon: Software Key Escrow
by Blanc Weber 17 Dec '03

17 Dec '03

From: Timothy C. May Putting Microsoft's feet to the fire, getting them to commit to *not* including any form of software-based key escrow in any future releases of Windows (Chicago or Daytona) could be a concrete step in the right direction. Ditto for Apple. ................................................ I'm afraid you can't do that, Tim. You're just going to have to take Sandy & Duncan's Seminar on Hard-core Privacy. :>) Blanc (I'm checking on getting permission to post an official word from MS)

1 0