December 2003 - cypherpunks-legacy

Re: My anonymous remaile
by gtoal＠an-teallach.com 17 Dec '03

17 Dec '03

: At the end of the day, at a certain hour agreed upon by the remailer operators, : the remailer will split up its cached messages and split them among several All sounds reasonble *except*... this is the internet, man! We can afford to do this once every 15 minutes, can't we? G

2 1

Re: crime and snitches
by pjm＠gasco.com 17 Dec '03

17 Dec '03

Berzerk writes: >>> ABSOLUTELY! The fact is if you can't get someone to snitch, IT IS NOT A >>> CRIME (morally)! I dare anyone to come up with a counterexample. >> If you were limiting your assertion to crime over the net, I >> suggest that the long, interesting history of confidence men is a >> refutation. Done correctly, in many cases the victim doesn't even >> know he has been conned. > Then have they? Can you give an example? I recently moved to Portland, OR (any cypherpunks up here?), and haven't yet unpacked all my books, but from memory one variation used in the movie "Grifters" is: - Convince the mark that you have an undetectable method to make money from the stock market that, while technically illegal, "won't hurt anyone". - Get seed money from the mark to run the scam. - Stage a bust by the police and allow the mark to escape. - The mark feels lucky to have gotten away, the front man and faux police split the money. It shouldn't be too hard to come up with ways of doing this on the net, given ecash and the rest of the infrastructure. Regards, Patrick May pjm(a)gasco.com

1 0

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

17 Dec '03

You don't even need encryption. 1) Initialize the garage unit and hand unit with a secret initialization vector for a crypto-hash function. 2) Push hand unit button to send "open" signal in clear. 3) Garage unit send a large random number in the clear. While waiting for reply, garage unit calculates hash of the random number it just sent. 4) Hand unit hashes random number and sends result to garage unit. 5) Garage unit opens door if the received hash matches the local hash. 6) And best of all...YOU CAN EXPORT IT! Jim_Miller(a)suite.com

1 0

Re: CYPHERPUNKS TO THE RESCUE
by Pierre Uszynski 17 Dec '03

17 Dec '03

Let's not go overboard!!! I hear things like "public/private key", "battery backup", "the door unit transmits", "a keypad on both sides" Hey! This is a garage door opener! You think you can add $20 of stuff and still have a profit margin? How about no keypad, no battery backup on the remote, just a (random) secret key, no door unit transmitter, normal batteries in the remote and door unit: 1 - Plug the remote into the door unit. The door unit writes a roughly random number (electronic noise), into the remote, and remembers the same. Units synchronize time, while they are at it. 2 - Take the remote for a drive. When you come back press the "open" button. 3 - The remote send the current time (as per its 1 min (im)precise real time clock), encrypted with the secret key. See later real message because of replay attacks. 4 - The door unit decrypts and checks against time, time +1, or time - 1. If valid, it opens the door, and synchronizes its time to the time stamp. POWER LOSS. This is a garage door opener. What do you do when your garage door remote fails, you try again, then you use your key and replace the **** battery (start again at step 1). In my area, power outages are so rare that I wouldn't even need a battery on the door unit (your milage may vary). REPLAY ATTACK. To foil an attacker who would record the time stamp and replay it within a minute: After a time stamp opens the door, a bare time stamp will only work again after something like 2 minutes. Instead, when you push the remote "open" several times within the same protected period, you issue "timestamp, tag1", then "timestamp, tag2", etc... say you are allowed 6 "opens" in the same protection period. The door unit has to check against time - 1, time, time +1, and the corresponding 6 tags. When a tagged stamp worked, all the previous ones are disabled for the protection period, whether the door unit received them or not (to avoid the reuse of messages that failed to open the door.) If you push the remote "open" and it fails to open the door, and you simply give up on the idea of opening the door, you are susceptible to replay attack for something like 2 minutes... that's life. "CLOSE" ACTION. Just close the door, no crypto. Any problem with this SIMPLE solution? Considering there is no point in spending zillions on the garage door opener if your windows do not have alarms. The reason some current units may not be secure is probably the usual: the manufacturers are not interested in what the customers don't want and the customers don't want what the manufacturers have never told them could (or should) be done. And politicians are more interested in legislative action than in suggesting their constituents do not buy junk. Pierre. pierre(a)shell.portal.com ObQuotesFromPreviousMessages: Sandy Sandfort <sandfort(a)crl.com> said something like: > On Tue, 26 Jul 1994, Arsen Ray Arachelian wrote: > > > You'd need a clock on the garage controller....The garage opener > > would receive a signal from the remote, issue a challenge code based on a > > hash of the time/date + some random numbers. The remote would encrypt this > > hash with the owner's IDEA key and send back the response. > > Am I missing something here? Why would you need a clock? What I had in > mind was something like: > > 1--The owner presses the "open" button on the remote. > 2--The remote sends an "ask me" signal to the door unit. > 3--The door unit transmits a random number in the clear. > 4--The remote encrypts and signs the random number using > its unique private key. > 5--The door unit decrypts and compares the numbers, using > the remotes public key. > 6--If the numbers match, the door opens. QED. > > Adjusting my flame retardant underwear, > > > S a n d y > > P.S. For most car and garage doors, relatively short (32 bit?) keys > should be more than sufficient, I would think. > > > > > >

1 0

Re: LITTLE BROTHER INSIDE
by Justin Lister 17 Dec '03

17 Dec '03

> C'punks, > On Tue, 26 Jul 1994, Jim choate wrote: > > . . . > > This would of course assume that the police were silly enough to > > use the disk and such from your machine in your machine. From my > > experience w/ Mentor and Erik Blookaxe during Operation Sun Devil this > > is not very realistic....Also it would only work > > once. Thereafter they would either examine the equipment in a Farady Cage > > or else start doing pager rental scans prior to seizure. Why not just use an encrypted partition. I guess then it is a problem of not being persuaded to reveal the key. What laws/rights does the user have as to revealing the key ? And if the user says "I forget" what would be likely response ? How many users would hold tight, from cases I have heard they usually give in when the stakes are raised. > I'm not so sure. Operation Sun Devil was a more sophisticated operation > than the average cops run. Cops, for the most part, are incredibly lazy > and stupid. I think you could count on lots of them not doing it right. A while back a local BBS system was investigated, it was amazing to find that the police had little knowledge of the software (MSDOS and OS/2 - Remote Acess RA and Front Door) and hardware being used. Apparently the sysop had the system setup so that he could quickly delete the drives FAT and do random zeroing of the drives. Although it wasn't performed as they weren't even familar with hidden (attrib) directories or using non-printable dir names. Essentially they relied on information from the sysop to carry out the investigation. -- +---------------------+--------------------------------------------------+ | ____ ___ | Justin Lister ruf(a)cs.uow.edu.au | | | \\ /\ __\ | Center for Computer Security Research | | | |) / \_/ / |_ | Dept. Computer Science voice: 61-42-835-114 | | | _ \\ /| _/ | University of Wollongong fax: 61-42-214-329 | | |_/ \/ \_/ |_| (tm) | Computer Security a utopian dream... | | | LiNuX - the only justification for using iNTeL | +---------------------+--------------------------------------------------+

5 8

Re: CYPHERPUNKS TO THE RESCUE
by Pierre Uszynski 17 Dec '03

17 Dec '03

Sorry for following up on my own post, but when I said: > The reason some current units may not be secure is probably the > usual: the manufacturers are not interested in what the customers > don't want and the customers don't want what the manufacturers have > never told them could (or should) be done. And politicians are more > interested in legislative action than in suggesting their constituents > do not buy junk. On the other hand, our leaders may be interested in promoting technology and the American Way. To this end, NIST (in close collaboration with NSA and the FBI) could be mandated to assign a committee to prepare a report detailing the need for further study on the Information Highway Garage Door Opener Voluntary Standard (IHGDOVS, sorry). Clearly National Security would mandate the use of an escrow system, and of secret algorithms, but as phone coverage of the country (and soon cellular coverage) if pretty good, key escrow would not impose that much of a burden on the taxpayer. The door unit would be a tamper proof, reverse engineering proof unit back-end programmed in Fort Meade to hold the escrow serial number. Its full alphanumeric keyboard (anything less would be un-american) could not be used to enter a new pass-phrase unless a phone connection exists back to headquarters. Because of the escrow system, there would then be no objection to the use of a really secure system (with full length 500 bit keys). And because "compute cycles are cheap" voice recognition could be added on the remote to foil crude attacks in the line of stealing the silly thing. All this resulting in a definite strategic and economic advantage for the US and US companies. Pierre. pierre(a)shell.portal.com

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

New Threat on the Horizon: Software Key Escrow
by tcmay＠netcom.com 17 Dec '03

17 Dec '03

At the June Cypherpunks meeting, Whit Diffie (co-inventor of public-key crypto, as you should all know) filled us in on a workshop on "key escrow" held in Karlsruhe, Germany. All the usual suspects were there, and I gather that part of the purpose was to bring the Europeans "into the tent" on key escrow, to deal with their objections to Clipper, and so on. 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 described here on the list. I know Bill Stewart has recently discussed it in sci.crypt or talk.politics.crypto. What has me worried about it now is evidence from more than one source that this program is actually much further along than being merely a "trial balloon" being floated. In fact, it now looks as though the hardware-based key escrow systems will be deemphasized, as Al Gore's letter seems to say, in favor of software-based schemes. While I've been skeptical that software-based schemes are secure (the bits are hardly secure against tampering), the addition of negotiation with another site (a lot like online clearing of digital cash, it seems) can make it nearly impossible for tampering to occur. That is, I'm now more persuaded that the NIST/NSA(?) proposal would allow software-based key escrow. Here's the rub: * Suppose the various software vendors are "incentivized" to include this in upcoming releases. For example, in 30 million copies of Microsoft's "Chicago" (Windows 4.0) that will hit the streets early in '95 (betas are being used today by many). * This solves the "infrastructure" or "fax effect" problem--key escrow gets widely deployed, in a way that Clipper was apparently never going to be (did any of you know _anybody_ planning to buy a "Surety" phone?). (Granted, this is key escrow for computers, not for voice communication. More on this later.) * Once widely deployed, with not talk of the government holding the keys, then eventual "mandatory key escrow" can be proposed, passed into law by Executive Order (Emergency Order, Presidential Directive, whatever your paranoia supports), an act of Congress, etc. I don't claim this scenario is a sure thing, or that it can't be stopped. But if in fact a "software key escrow" system is in the works, and is more than just a "trial balloon," then we as Cypherpunks should begin to "do our thing," the thing we've actually done pretty well in the past. To wit: examine the implications, talk to the lobbyist groups about what it means, plan sabotage efforts (sabotage of public opinion, not planting bugs in the Chicago code!), and develop ways to make sure that a voluntary key escrow system could never be made mandatory. (Why would _anyone_ ever use a voluntary key escrow system? Lots of reasons, which is why I don't condemn key escrow automatically. Partners in a business may want access under the right circumstances to files. Corporations may want corporate encryption accessible under emergencyy circumstances (e.g., Accounting and Legal are escrow agencies). And individuals who forget their keys--which happens all the time--may want the emergency option of asking their friends who agreed to hold the key escrow stuff to help them. Lots of other reasons. And lots of chances for abuse, independent of mandatory key escrow.) But there are extreme dangers in having the infrastructure of a software key escrow system widely deployed. I can't see how a widely-deployed (e.g., all copies of Chicago, etc.) "voluntary key escrow" system would remain voluntary for long. It looks to me that the strategy is to get the infrastructure widely deployed with no mention of a government role, and then to bring the government in as a key holder. (The shift of focus away from telephone communications to data is an important one. I can see several reasons. First, this allows wide deployment by integration into next-gen operating systems. A few vendors can be "incentivized." Second, voice systems are increasingly turning into data systems, with all the stuff surrounding ISDN, cable/telco alliances, "set-top" boxes, voice encryption on home computers, etc. Third, an infrastructure for software key escrow would make the backward extension to voice key escrow more palatable. And finally, there is a likely awareness that the "terrorist rings" and "pedophile circles" they claim to want to infiltrate are more than likely already using computers and encryption, not simple voice lines. This will be even more so in the future. So, the shift of focus to data is understandable. That it's a much easier system in which to get 40-60 million installed systems _almost overnight_ is also not lost on NIST and NSA, I'm sure.) In other words, a different approach than with Clipper, where essentially nobody was planning to buy the "Surety" phones (except maybe a few thousand) but the government role was very prominent--and attackable, as we all saw. Here, the scenario might be to get 40-60 million units out there (Chicago, next iteration of Macintosh OS, maybe Sun, etc.) and then, after some series of events (bombings, pedophile rings, etc.) roll in the mandatory aspects. Enforcement is always an issue, and I agree that many bypasses exist. But as Diffie notes, the "War on Drugs" enlistment of corporations was done with various threats that corporations would lose assets/contracts unless they cooperated. I could see the same thing for a software-based key escrow. A potentially dangerous situation. I was the one who posted the Dorothy Denning "trial balloon" stuff to sci.crypt, in October of 1992, six months before it all became real with the announcement of Clipper. This generated more than a thousand postings, not all of them useful (:-}), and helped prepare us for the shock of the Clipper proposal the following April. I see this software-based key escrow the same way. Time to start thinking about how to stop it now, before it's gone much further. 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 sure we can think of other steps to help derail widespread deployment of this infrastructure. --Tim May -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)netcom.com | anonymous networks, digital pseudonyms, zero 408-688-5409 | knowledge, reputations, information markets, W.A.S.T.E.: Aptos, CA | black markets, collapse of governments. Higher Power: 2^859433 | Public Key: PGP and MailSafe available. "National borders are just speed bumps on the information superhighway." -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)netcom.com | anonymous networks, digital pseudonyms, zero 408-688-5409 | knowledge, reputations, information markets, W.A.S.T.E.: Aptos, CA | black markets, collapse of governments. Higher Power: 2^859433 | Public Key: PGP and MailSafe available. "National borders are just speed bumps on the information superhighway."

5 5

No, each tape position cannot... (was Re: GUT and P=NP)
by collins＠newton.apple.com 17 Dec '03

17 Dec '03

>Could I not let each position on the tape represent a real value in >[0...1]? You could try! But you would always omit values. You can demonstrate this with the `diagonal rule' or similar proofs. Here's a simple one: Take any two adjacent `positions' on the tape; Write out the decimal (or binary) notation for the real values they represent (note, the representations may be infinite). Given two such strings that are not identical, you can always find a string numerically `between' them (even if both are infinite) as long as they are not identical. E.g., "0.12345" --->"0.123455"<---- "0.12346" Such a string is a real value you omitted. Your tape, even if it is infinite, is not the right order of infinity to model the Real numbers. Scott Collins | "Invention, my dear friends, is 93% perspiration, | 6% electricity, 4% evaporation, and 2% butter- collins(a)acm.org | scotch ripple." -- Willy Wonka ..................|.................................................. Apple Computer, Inc. 5 Infinite Loop, MS 305-2D Cupertino, CA 95014 408.862.0540 fax:974.6094 R254(IL5-2N) collins(a)newton.apple.com ..................................................................... 408.257.1746 1024:669687 catalyst(a)netcom.com

1 0

Re: CYPHERPUNKS TO THE RESCUE
by fnerd＠smds.com 17 Dec '03

17 Dec '03

I think Norm gets the prize for the best garage door opener: > ...How about the car unit signing successive numbers.... But this raises an idle question: how much easier is it to break a DES key given a sequence of (n, DES(n)) where the n's are successive numbers, than it is if the n's are random (but still known)? I doubt this is a practical threat for garage doors. - -Steve - - - - - - - - - - - - - - - nutritional information per serving: less than one (1) bit -----BEGIN PGP SIGNATURE----- Version: 2.3a aKxB8nktcBAeQHabQP/d7yhWgpGZBIoIqII8cY9nG55HYHgvt3niQCVAgUBLMs3K ui6XaCZmKH68fOWYYySKAzPkXyfYKnOlzsIjp2tPEot1Q5A3/n54PBKrUDN9tHVz 3Ch466q9EKUuDulTU6OLsilzmRvQJn0EJhzd4pht6hSnC1R3seYNhUYhoJViCcCG sRjLQs4iVVM= =9wqs -----END PGP SIGNATURE-----

2 1

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

(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

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

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

Cryptosplit
by rjc＠powermail.com 17 Dec '03

17 Dec '03

The recent postings about crypto sharing/spliting programs renewed my interest, so I dusted off cryptosplit (a Shamir secret sharing program I wrote around November of last year) and fixed up the bugs which made it unusable. Here it is, less bugged, about 10 times faster than before, but still ugly. # This is a shell archive. Save it in a file, remove anything before # this line, and then unpack it by entering "sh file". Note, it may # create directories; files and directories will be owned by you and # have default permissions. # # This archive contains: # # README # Makefile # cryptosplit.c # gf.h # echo x - README sed 's/^X//' >README << 'END-of-README' X XHow to use X---------- XTo encode: X Xcsplit -g <number of pieces> -q <minimum number required for decode> [filename] X Xtake filename and split it into the number of pieces given by -g. Each Xpiece is "filename.0", "filename.1", ..., "filename.(n-1)" if Xfilename isn't supplied, it operates like kinda like a filter taking the Xincoming data and spliting it into files "piece.0", "piece.1", ... X Xto decode: X Xprovide atleast the number of pieces specified by -q when you encoded. XIf you specify less than the minimum number, it will not decode. X Xexample: X Xcsplit -g 5 -q 3 file X[split file into 5 pieces, any 3 of which will reconstruct it] X Xcsplit file.0 file.1 file.2 X[put them together in the decoded file and output to stdout] X Xif you want to put it into a file, redirect it using the shell, or Xuse "-o filename" X X-Ray X X END-of-README echo x - Makefile sed 's/^X//' >Makefile << 'END-of-Makefile' X XCFLAGS=-O X X Xcsplit: cryptosplit.c gf.h X cc $(CFLAGS) cryptosplit.c -o csplit X END-of-Makefile echo x - cryptosplit.c sed 's/^X//' >cryptosplit.c << 'END-of-cryptosplit.c' X/* X * Cryptosplit 2.03 An implementation of Shamir secret sharing over GF(2^8) X * X * written by Ray Cromwell <rjc(a)gnu.ai.mit.edu> Version 2.01 - fixed bug and X * make it generate a different polynomial for each byte X */ X X/* Pay no attention to the sloppy code, this is only a first draft */ X X#include "gf.h" X#include <sys/types.h> X#include <sys/stat.h> X#include <ctype.h> X#include <stdio.h> X Xwrite_pieces(char **, char **, int); Xwrite_key(char *, char *, int); Xint read_key(char *, int); Xint read_pieces(char **, int); Xgenerate_key(char *); X Xint quorum = 2; Xint pieces = 3; X Xint generate = 0; Xchar *key = 0; Xchar *tmpkey = 0; Xchar **keypieces; Xchar *keyfiles[256]; Xchar *outputfile = (char *) 0; X X#define CHUNKSIZE 8192 X#define RANDINIT(x) srand(time(0)) X#define RAND rand X Xmain(int argc, char *argv[]) X{ X int c = 1, k = 0; X X RANDINIT(0); X X if (argc == 1) X print_help(); X keyfiles[0] = (char *) 0; X X while (c < argc) { X if (argv[c][0] == '-') { X if (argv[c][1] == 'g') { X generate = 1; X c++; X if (c >= argc) X print_help(); X pieces = atoi(argv[c++]); X } else if (argv[c][1] == 'q') { X c++; X if (c >= argc) X print_help(); X quorum = atoi(argv[c++]); X } else if (argv[c][1] == 'o') { X c++; X if (c >= argc) X print_help(); X outputfile = argv[c++]; X } X } else { X keyfiles[k++] = argv[c++]; X } X } X if (generate) { X if (k > 0) { X init_buffers(); X if(quorum > pieces) pieces=quorum; X generate_keys(keyfiles[0]); X } X } else { X if (k < 2) { X fprintf(stderr, "You didn't supply enough pieces.\n"); X exit(1); X } X quorum = pieces = k; X init_buffers(); X rebuild_key(k); X } X} X Xinit_buffers() X{ X int i; X keypieces = (char **) malloc(sizeof(char *) * pieces); X for (i = 0; i < pieces; i++) X keypieces[i] = (char *) malloc(CHUNKSIZE); X key = (char *) malloc(CHUNKSIZE); X tmpkey = (char *) malloc(CHUNKSIZE); X} X Xint Xread_pieces(char **files, int offset) X{ X int i, s; X FILE *f; X for (i = 0; i < quorum; i++) { X if (!(f = fopen(files[i], "r"))) { X perror("Cryptosplit"); X exit(1); X } X fseek(f, offset, SEEK_SET); X if (feof(f)) { X fclose(f); X return 0; X } X s = fread(keypieces[i], 1, CHUNKSIZE, f); X fclose(f); X } X return s; X} X Xrebuild_key(int ksize) X{ X unsigned char **coeffs; X unsigned char *consts; X int i, j, k, p, t, sr, ip, klen, off = 0; X unsigned char x, y, z, r; X coeffs = (unsigned char **) malloc(sizeof(char *) * quorum); X t = 1; X x = 0; X for (i = 0; i < quorum; i++) { X coeffs[i] = (char *) malloc(quorum); X } X consts = (char *) malloc(quorum); X while (klen = read_pieces(keyfiles, off)) { X off += klen; X t = 1; X while (t < klen) { X for (i = 0; i < quorum; i++) { X x = keypieces[i][0]; X y = keypieces[i][t]; X consts[i] = y; X coeffs[i][quorum - 1] = 1; X z = x; X for (j = quorum - 2; j >= 0; j--) { X coeffs[i][j] = z; X z = GFMUL(z, x); X } X } X sr = 0; X ip = 0; X/* Invert quorum x quorum matrix to obtain the constant factor */ X/* We can use lagrange interpolation or something better later. X Shamir says there is an O(n^2 log n) method, I'll code it when X I see it. */ X X for (i = sr; i < quorum; i++) { X/* print_matrix(coeffs, consts); */ X r = GFINV(coeffs[i][i]); X consts[i] = GFMUL(consts[i], r); X coeffs[i][i] = 1; X for (j = sr + 1; j < quorum; j++) { X coeffs[i][j] = GFMUL(coeffs[i][j], r); X } X for (ip = i + 1; ip < quorum; ip++) { X r = coeffs[ip][sr]; X for (j = sr; j < quorum; j++) { X z = GFMUL(coeffs[i][j], r); X coeffs[ip][j] = GFADD(coeffs[ip][j], GFMUL(coeffs[i][j], r)); X } X consts[ip] = GFADD(consts[ip], GFMUL(consts[i], r)); X } X sr = sr + 1; X } X/* print_matrix(coeffs, consts); */ X key[t - 1] = consts[quorum - 1]; X t++; X } X write_key(outputfile, key, klen - 1); X } X} X Xint Xread_key(char *file, int offset) X{ X int size; X FILE *f; X if (file) X f = fopen(file, "r"); X else X f = stdin; X fseek(f, offset, SEEK_SET); X if (feof(f)) { X fclose(f); X return 0; X } X size = fread(key, 1, CHUNKSIZE - 1, f); X fclose(f); X return size; X} X Xint Xfilesize(char *file) X{ X struct stat s; X if (stat(file, &s)) { X perror("Cryptosplit"); X exit(0); X } X return s.st_size; X} X Xgenerate_keys(char *keyfilename) X{ X int i, j, k, o, keylength, off; X unsigned char *coeffs; X unsigned char x, y, z; X char tmpname[256]; X coeffs = (char *) malloc(sizeof(char *) * quorum); X off = 0; X if (!keyfilename) X keyfilename = "piece"; X X for (i = 0; i < pieces; i++) { X keyfiles[i] = (char *) malloc(256); X sprintf(keyfiles[i], "%s.%d", keyfilename, i); X unlink(keyfiles[i]); X } X while (keylength = read_key(keyfilename, off)) { X off += keylength; X for (j = 0; j < keylength; j++) { X /* Generate a random quorum-1'th degree polynomial */ X for (o = 1; o < quorum; o++) { X coeffs[o] = GF(RAND() % 256); X } X for (i = 0; i < pieces; i++) { X y = key[j]; X x = GF(i + 1); X keypieces[i][0] = x; X z = x; X for (k = 1; k < quorum; k++) { X y = GFADD(y, GFMUL(coeffs[k], x)); X x = GFMUL(x, z); X } X keypieces[i][j + 1] = y; X } X } X write_pieces(keyfiles, keypieces, keylength + 1); X } X} X Xwrite_pieces(char **files, char **data, int ks) X{ X FILE *f; X int i; X for (i = 0; i < pieces; i++) { X f = fopen(files[i], "a"); X fwrite(data[i], ks, 1, f); X fclose(f); X } X} X Xwrite_key(char *file, char *t, int k) X{ X FILE *f; X if (file) X f = fopen(file, "a"); X else X f = stdout; X fwrite(t, k, 1, f); X fclose(f); X} X Xprint_help() X{ X fprintf(stderr, "To generate 'pieces' of a 'key'\n"); X fprintf(stderr, "Usage: cryptosplit -g <# of pieces> -q <quorum required to rebuild> keyfile\n\n"); X fprintf(stderr, "To reconstruct the original file from n 'pieces'\n"); X fprintf(stderr, "Usage: cryptosplit piece_1 piece_2 ... piece_n [-o output filename]\n"); X exit(0); X} X Xprint_matrix(char **co, char *c) X{ X int i, j; X for (i = 0; i < quorum; i++) { X for (j = 0; j < quorum; j++) { X printf("%3u ", ((unsigned long) co[i][j] & 0xFF)); X } X printf("= %3u\n", ((unsigned long) c[i] & 0xFF)); X } X printf("\n"); X} END-of-cryptosplit.c echo x - gf.h sed 's/^X//' >gf.h << 'END-of-gf.h' X/* Cryptosplit X * An implementation of Shamir secret sharing over GF(2^8) X * X * written by Ray Cromwell <rjc(a)gnu.ai.mit.edu> X */ X X/* Pay no attention to the sloppy code, this is only a first draft */ X X/* g is a primitive element, this table represents g^k for 0 <= k <= 255 */ Xint G[]={ X1, 103, 129, 227, 78, 81, 222, 46, 50, 20, 176, 94, 170, 253, 166, 32, X33, 70, 199, 36, 106, 59, 229, 203, 249, 237, 93, 3, 169, 84, 242, 210, X243, 181, 114, 86, 60, 7, 226, 41, 208, 61, 96, 99, 202, 158, 108, 190, X77, 248, 138, 220, 224, 231, 5, 44, 252, 193, 161, 194, 8, 150, 250, 68, X9, 241, 123, 167, 71, 160, 165, 137, 117, 180, 21, 215, 223, 73, 179, 247, X254, 15, 116, 211, 148, 52, 145, 24, 109, 217, 204, 27, 196, 141, 62, 201, X55, 56, 76, 159, 11, 63, 174, 182, 219, 2, 206, 213, 17, 156, 162, 107, X92, 100, 40, 183, 188, 131, 45, 155, 64, 66, 140, 89, 72, 212, 118, 29, X65, 37, 13, 186, 6, 133, 168, 51, 115, 49, 189, 228, 172, 120, 14, 19, X82, 119, 122, 192, 198, 67, 235, 216, 171, 154, 39, 195, 111, 23, 25, 10, X88, 47, 85, 149, 83, 16, 251, 35, 136, 18, 53, 246, 153, 142, 151, 157, X197, 234, 191, 42, 121, 105, 146, 177, 57, 43, 30, 232, 113, 255, 104, 245, X48, 218, 101, 79, 54, 95, 205, 124, 69, 110, 112, 152, 233, 22, 126, 139, X187, 97, 4, 75, 125, 34, 239, 147, 214, 184, 200, 80, 185, 175, 209, 90, X225, 128, 132, 207, 178, 144, 127, 236, 58, 130, 74, 26, 163, 12, 221, 135, X102, 230, 98, 173, 31, 143, 240, 28, 38, 164, 238, 244, 87, 91, 134, 1, X}; X X/* if n=g^k, this table returns k=lg n */ Xint I[]={ X0, 255, 105, 27, 210, 54, 132, 37, 60, 64, 159, 100, 237, 130, 142, 81, X165, 108, 169, 143, 9, 74, 205, 157, 87, 158, 235, 91, 247, 127, 186, 244, X15, 16, 213, 167, 19, 129, 248, 154, 114, 39, 179, 185, 55, 118, 7, 161, X192, 137, 8, 135, 85, 170, 196, 96, 97, 184, 232, 21, 36, 41, 94, 101, X120, 128, 121, 149, 63, 200, 17, 68, 124, 77, 234, 211, 98, 48, 4, 195, X219, 5, 144, 164, 29, 162, 35, 252, 160, 123, 223, 253, 112, 26, 11, 197, X42, 209, 242, 43, 113, 194, 240, 1, 190, 181, 20, 111, 46, 88, 201, 156, X202, 188, 34, 136, 82, 72, 126, 145, 141, 180, 146, 66, 199, 212, 206, 230, X225, 2, 233, 117, 226, 133, 254, 239, 168, 71, 50, 207, 122, 93, 173, 245, X229, 86, 182, 215, 84, 163, 61, 174, 203, 172, 153, 119, 109, 175, 45, 99, X69, 58, 110, 236, 249, 70, 14, 67, 134, 28, 12, 152, 140, 243, 102, 221, X10, 183, 228, 78, 73, 33, 103, 115, 217, 220, 131, 208, 116, 138, 47, 178, X147, 57, 59, 155, 92, 176, 148, 18, 218, 95, 44, 23, 90, 198, 106, 227, X40, 222, 31, 83, 125, 107, 216, 75, 151, 89, 193, 104, 51, 238, 6, 76, X52, 224, 38, 3, 139, 22, 241, 53, 187, 204, 177, 150, 231, 25, 250, 214, X246, 65, 30, 32, 251, 191, 171, 79, 49, 24, 62, 166, 56, 13, 80, 189, X}; X X#define GFADD(a,b) ((a) ^ (b)) X#define GFMUL(a,b) (((a)==0 || (b)==0) ? 0 : G[(I[(a)] + I[(b)]) % 255]) X#define GFINV(a) ((a)==0 ? 0 : G[255-I[(a)]]) X#define GF(a) (G[(a) % 255]) X#define LOGGF(a) (I[(a)%255]) X END-of-gf.h exit

1 0