December 2003 - cypherpunks-legacy

[NOISE] Re: photographed license plates
by mccoy＠communities.com 17 Dec '03

17 Dec '03

rpowell(a)algorithmics.com writes: >Simon Spero <ses(a)tipper.oit.unc.edu> writes: > > In the UK they now use cameras to deter speeding [...] > > In Ontario, they tried this on some of the major highways. The most > interesting thing about it was that it was proved time and time again > that the technology was not up to snuff: there was an almost 0% chance > of being caught. When the license plate wasn't obscured or unreadable > (which it usually was) the computerized mailing system made some > stupid mistake that allowed the person to get off if they challenged > it. One problem with using such systems in the US (I have no idea about traffic laws in Ontario so maybe this was the loophole you mentioned) is that even with a perfect shot of the license plate the system only identifies a car, not a driver. Speeding tickets are given to drivers, not necessarily to the owner of the speeding car. Here in the states the easy challenge to such a ticket would be "it was not me driving when that photo was taken" and the burden of proof is on the prosecution to prove that you were the driver. Since some states do not require front license plates the cameras take shots of the tail end of the car, not the best angle for identifying drivers. jim

3 2

Replace Key
by Pronto Secure Beta Feedback 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Type Bits/KeyID Date User ID pub 1024/998463CD 1996/04/01 Pronto Secure Beta <secure(a)commtouch.com> - -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.3i mQCNAzFf7jAAAAEEAMI8wSoVVRRv0Sr68myImRaQH9N/uvZ2agoJHgxk70NYkQhp BD72rz/7lO4HK51pe/9kTTFsZPAUoTG+xdWAgSrclG1auTjHQPnb/9m/H4SYKi4n hcNDrq3HmbaHYZjsJGAUHdWV7Kj82z1ad39nCS2yjuh396RcpSbCxfqZhGPNAAUR tClQcm9udG8gU2VjdXJlIEJldGEgPHNlY3VyZUBjb21tdG91Y2guY29tPokAlQMF EDFgONAmwsX6mYRjzQEB7M8D/0yjy/7i6ICm9Qa6ff8skvnZdKrPJYqgnOg14Nx5 2DKGbSAbwnvq94UaQ0tCqsQNrKRO0pWOnBIOT++3oibKl39tTi/uQV4vtSPvSvia xUp4emtY/hhhls7Nbv0TcHPysjT8cp4vtRk7zpFbCsNIKIk7tAWF3U7OSEc/sLCg ixxW =Ovh1 - -----END PGP PUBLIC KEY BLOCK----- - --- [This message has been signed by an auto-signing service. A valid signature means only that it has been received at the address corresponding to the signature and forwarded.] -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Gratis auto-signing service iQBFAwUBMhEG2SoZzwIn1bdtAQG3xQF/Vlb4Cy/l1JVTHBiMZ0AWl+TuhjjjRRFz T3mDP76QBCPrmftAA68a1krz0wOl6Dh6 =1HZk -----END PGP SIGNATURE-----

1 0

Re: [NOISE] Geek Apartments
by Jeremy Mineweaser 17 Dec '03

17 Dec '03

At 10:41 AM 8/13/96 -0500, you wrote: >* I can see it now. Apartments full of geeks because the apartments >* were originally built with 100BaseX to each place and a T3 in the >* basement going direct to the local ISP. > >Yes, it has already happened, although in a slightly different >context. The Georgia Tech campus dormatories got wired with Ethernet >back in 1994, and there was quite a rush by the sizable geek >population to get dorm rooms in the buildings slated to get >installation first. It worked out quite well, especially the privacy >aspects, as the dorm routers encrypted all packets so only the >intended Ethernet node could receive it (at least that is what they >said). > >So, in this case it was only 10BaseT and gatech.edu as the ISP, but it >still was very neat. Thanks to the Olympics, Georgia Tech now has 100% Ethernet availability in its dormitories. Currently the system utilizes a fiber-optic campus backbone with network hardware in each building providing a 10BaseT port to each student. Work is underway to install ATM hardware and upgrade ports to 100Mb/s networking technology. Jeremy L. Mineweaser | GCS/E d->-- s:- a--- C++(+++)$ ULC++(++++)>$ P+>++$ gt4436c(a)prism.gatech.edu | L+>++ E-(---) W++ N+ !o-- K+>++ w+(++++) O- M-- | V-(--) PS+(--) PE++ Y++>$ PGP++>+++$ t+() 5 X+ R+() *ai*vr*vx*crypto* | tv(+) b++>+++ DI+(++) D+ G++ e>+++ h-() r-@ !y-

2 1

The Ostrich Method of dealing with ITAR: PGP from OnNet
by Rich Graves 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- This message is sent from an evaluation version of FTP OnNet32 2.0, which has PGP- compatible encryption built-in. This software is distributed from http://www.ftp.com/mkt_info/onnet32/mail/mail_dl.htm which doesn't have a hell of a lot as technical enforcement of ITAR goes. You may download the software through the Anonymizer, www.anonymizer.com, if you wish. Unfuckingbelievable. By the way, encrypting and decrypting large messages with OnNet is about 10 times faster than with Private Idaho/PGP for DOS on my P6-200 running NT 3.51. The user interface is pretty good, too. Somebody pinch me. - -rich -----BEGIN PGP SIGNATURE----- Version: 2.9 iQBVAgUBMhEXDJNcNyVVy0jxAQHDXQH/aQSrU3ZqhOJXGanSDnS/o+DdsH2GMKcI 6A8J3cGZAZ3ESK30GxwozdHpBjJRHIww4i/rrxK9aBNpzm/vQnovXg== =8dGx -----END PGP SIGNATURE-----

1 0

INVITATION
by Sandy Sandfort 17 Dec '03

17 Dec '03

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ SANDY SANDFORT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C'punks, Below, is the invitation to my next costume party. Everyone on Cypherpunks is invited. I hope to see a lot of you there. The last party was a HUGE success; this one should be even better. S a n d y ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I'M NOT 50 YET! The Pleasure of Your Company is Cordially Requested at the: Second Occasional Anarcho-Dilettante Pick-Your-Own-Damned-Theme Masquerade Ball And Hallowe'en Rehearsal 7:00 PM FRIDAY THE 13TH September 1996 650 Kenwyn Road (at McKinley) Oakland, CA Lots of stuff happened on September 13th. We're not going to tell you which one to commemorate. That's up to you. Check out the birthdays and historical events listed below. Pick one or go with something else. Your choice. But no matter what theme you pick, it's still a masquerade ball, so you MUST wear a costume (or at least a mask). NO EXCEPTIONS THE ENTERTAINMENT At 8:00pm there will be a Dance Recital featuring Rainbeau, Gracie, Tish, Blythe, Michelle and special guests. You DO NOT want to miss this. (Please, adults only. We regret that our house is very unsuitable for children.) DOOR PRIZES Around Midnight, there will be a drawing for valuable and/or unique Door Prizes. (You must be present to win.) THE EATS I'm poorer this time around, so don't expect a complete buffet as with past parties. There will be some snacks and soft drinks, but you are encouraged to bring things to share. As always, BYOB RSVP Whether or not you plan to attend, we need to hear from you. Please give one of your hosts a call so we can plan on your presence OR your absence. Invited guests may bring other persons with prior approval of the hosts. This means if there are people you would like to bring, call a host to get permission for each of those people. THE HOSTS Head Anarchist in Charge, Sandy Sandfort 510-839-3441/sandfort(a)crl.com House Hosts with the Most, Gracie & Zarkov 510-832-2044/emyrt(a)aol.com Communications Officer, Sameer Parekh 510-547-3617/sameer(a)c2.org SEPTEMBER 13 IN HISTORY Birthdays: 1755--Oliver Evans, pioneered high-pressure steam engine. 1766--Samuel Wilson ("Uncle Sam"). 1851--Walter Reed, US Army physician (yellow fever work). 1857--Milton Hershey, candy maker. 1860--General John J. "Black Jack" Pershing, hero of WW I. 1876--Sherwood Anderson, US author ("Winesburg Ohio"). 1894--J.B. Priestley, English critic, playwright, and novelist ("Lost Empires"). 1905--Claudette Colbert (Claudette Chauchoin), actress. 1910--Chu Berry, saxophonist. 1916--Ronald Dahl, author ("Charlie and the Chocolate Factory"). 1925--Mel Torme, singer. 1928--Ernest L. Boyer, educator. 1928--Robert Indiana, artist. 1937--Fred Silverman, TV producer. 1938--Judith Martin, "Miss Manners", author, journalist. 1939--Larry Speakes, former White House spokesman. 1944--Jacqueline Bisset, actress ("Rich and Famous"). 1944--Peter Cetera, singer and songwriter. 1948--Nell Carter, actress. 1962--Cypherpunk, "Lucky Green." On this day... 122--Building of Hadrian's Wall began. 1592--Michel de Montaigne, French essayist, died. 1759--British defeated French at Abraham near Quebec City. 1759--James Wolfe, British General, died. 1788--Congress authorized the 1st US national election. 1788--New York City selected as location for US government. 1789--US received its first loan. 1803--Commodore John Barry, First American commodore who fought in the Revolutionary War, died. 1814--Battle over Ft. McHenry which inspired "The Star Spangled Banner." 1826--Rhinoceros 1st seen in NYC. 1899--1st automobile fatality. 1943--Chiang Kai-Shek became president of China. 1946--Ted Williams hit his only inside-the-park homer. 1946--Host Sandy Sandfort was -6 days old. 1950--70,000 UN troops landed at Inchon harbor (Korea). 1971--Attica State Prison stormed. 1983--Menachem Begin resigned as Israeli Prime Minister. 1988--Hurricane Gilbert hit the Caribbean. Another version of this invitation and a street map can be found at: http://www.c2.org/party/masquerade P.S. We love you so much, we want to make sure you do not miss any of our party. Therefore, you will be fined a Sprint fee (10 cents a minute, "one minute, two minutes...) for each minute you arrives after 8:00pm. The party starts at 7:00, so you get an hour for free. The late fee money will be used to defray costs. (We're not kidding. At the last party, more than $100 was collected.)

1 0

Re: Police prepare stunning end for high-speed car chases
by E. ALLEN SMITH 17 Dec '03

17 Dec '03

A: How possible is it to insulate cars from these effects? B: If it can't be insulated from with reasonable levels of effort, it would appear to be perfectly usable against cop cars. If the emitter is in a transparent baloon 1000 feet up, I doubt they're going to be able to track back to the user. -Allen

2 1

re: National Socio-Economic Security Need for Encryption Technology
by Bart Croughs 17 Dec '03

17 Dec '03

Sandy Sandfort wrote: >Been there, done that. I repeat, the error that Bart made is >assuming that because some US-source capital gets redirected >overseas, that the total amound of capital investment will >decline thus producing the wage drop he is fretting about. >Unless he can show that foreign capital investment will not flow >to US workers who are "forced" into working in industries where >they have a comparative advantage, his argument must fail. After >all, I--like the economists Bart cite--think international free >trade, the free flow of capital in persuit of the highest return >and division of labor are a GOOD thing. I also belief that international free trade, the free flow of capital in pursuit of the highest return and the division of labor are a GOOD thing. But in specific cases, I want to know the specific reasons. You claim that I must show that foreign capital investment will not flow back to US workers. But in my original post, I said: "Of course there are advantages also for the US (shareholders will get higher returns, trade will increase), but how can you proof that these advantages will offset the disadvantage of the lowered amount of capital in the US? " You haven't answered this question yet. I don't claim that the U.S. is worse off when US capital moves abroad. I only ask: how can you proof that the US isn't worse off when US capital moves abroad? If you don't know the answer, there's nothing to be ashamed of. I don't know the answer either. That's why I asked my question, in the hope that somebody could provide the answer, so that in the future I would be able to rebut arguments against the free movement of capital. Another thing: I don't assume that the *total amount* of capital will be lowered in the US when US capital moves abroad. I assume that the amount of capital in the US will be *relatively lower*. So the wages will be *relatively* lower (lower than when the capital wouldn't have left the US), but not necessarily lower in any absolute sense. I thought this was obvious, but since Arun Mehta also misunderstood me, maybe I should have been more explicit here. Bart Croughs

4 3

addenendum
by Brett Killins 17 Dec '03

17 Dec '03

The link on http://www.gatech.edu/lcc/idt/Miscellaneous/Glass_Houses/Organizations/Cyph… that points to the hotwired article on the cypherpunks has changed from http://www.hotwired.com/wired/1.2/features/cryptorebels.html to http://www.hotwired.com/wired/1.2/features/crypto.rebels.html. Or perhaps a typo? You may also want to include a link to http://www.hotwired.com/wired/1.2/features/crypto.rebels.sidebars.html Brett

1 0

key escrow idea from David Satelin of MIT Lincoln Labs
by Matt Blaze 17 Dec '03

17 Dec '03

My comments included below Rivest's message. -matt ------- Forwarded Message Received: from amontillado.research.att.com (amontillado.research.att.com [135.104.21.154]) by nsa.research.att.com (8.7.3/8.7.3) with ESMTP id QAA04438 for <mab-local(a)nsa.research.att.com>; Tue, 13 Aug 1996 16:17:05 -0400 (EDT) Received: from research.research.att.com (research.att.com [135.104.117.5]) by amontillado.research.att.com (8.7.5/8.7) with SMTP id QAA24830 for <mab(a)issr.research.att.com>; Tue, 13 Aug 1996 16:20:09 -0400 (EDT) Received: from theory.lcs.mit.edu by research; Tue Aug 13 16:17:17 EDT 1996 Received: from swan.lcs.mit.edu by theory.lcs.mit.edu (5.65c/TOC-1.2S) id AA05040; Tue, 13 Aug 96 16:16:20 EDT From: rivest(a)theory.lcs.mit.edu (Ron Rivest) Received: by swan.lcs.mit.edu (5.65c/TOC-1.2C) id AA00335; Tue, 13 Aug 96 16:16:20 EDT Date: Tue, 13 Aug 96 16:16:20 EDT Message-Id: <199608132016.AA00335(a)swan.lcs.mit.edu> To: jim(a)rsa.com, gnu(a)toad.com, whitfield.diffie(a)eng.sun.com, mab(a)research.att.com, denning(a)cs.georgetown.edu Cc: staelin(a)ll.mit.edu, mld(a)hq.lcs.mit.edu Subject: Crypto Policy Variant Hi -- Here is another MIT professor's (Dave Staelin's) suggestion for a national crypto policy. I thought you might be interested in seeing it; given the difficulty of the debate, any variant, even if only slightly different from previous ones, should be considered. Feel free to pass this note around, or to post it... Here is Staelin's idea: (1) You can use any crypto you want, but you must keep a record of the crypto keys you used. (2) The government can ask for the crypto keys later, if they have a court order, just as they can ask for any of your other papers or documents. You must give the key(s) to them, just as you must turn over your private papers in such a situation. (There would have to be an appropriate penalty for losing the key...) The attractive feature of this proposal is that it puts encrypted communications in the same category as private papers; the government is required to give notice to (at least one of) the affected individual(s) _before_ the search can be undertaken. This cures what is in my mind a defect in the current wire-tapping laws. DISCUSSION In a variant of Staelin's proposal (my twist) you could append to each encrypted message an encrypted form of the message key. The encryption could be with the public-key of a trusted third party who will not (and legally may not) reveal the message key without notifying you first (or ensuring that you have been appropriately served with the corresponding warrant). For example, the ACLU might be such a TTP. This protects the government's right to access and protects the individual from the penalties (or benefits) of losing the key. This procedure is technically simple; what is more complex is ensuring that the TTP's are appropriately registered and protected from undue government influence. The use of such a TTP would in any case be optional; the communicants need not use a TTP if they understand their obligation to keep the crypto keys around for some period of time afterwards. In Staelin's proposal government gains access to the communications, but does not gain "real-time access" as desired by the FBI. This loss may be tolerable, given the benefit obtained (forcing access to be made in accordance with the Constitutional requirements for notification before search). The use of wiretapping encrypted communications as a preventive measure might be severely limited, but its use as a means of gathering evidence to force a conviction would be preserved. For international communications, each communicant might be required to use a TTP that is bound to honor the laws of his country (which TTP to be used should be the choice of the communicant). It may be seem a bit strange to force individuals to keep around information (keys) that they no longer really need. However, this is more-or-less the case for financial records right now. CONCLUSION The fundamental idea is to give the government a right to access encrypted communication in return for a guarantee that access may not be obtained until there is BOTH proper legal authorization AND proper prior notice to (at least one of) the communicants. Is this workable?? ------- End of Forwarded Message [Matt's comments follow] The requirement to store your keys for some period of time would, I think, be very unusal, legaly. As far as I know there are virtually no records that an ordinary individual is required to keep today under criminal penalty of law. One has to keep tax records if one expects to be able to document deductions if audited, but for people without deductions, no records need be kept (and even those who do but who destroy their records risk having their deductions disallowed, but face criminal penalties only if the govenment can prove you intended fraud. Not having records does not by itself constitute fraud, as far as I know). According to the original message: The attractive feature of this proposal is that it puts encrypted communications in the same category as private papers; the government is required to give notice to (at least one of) the affected individual(s) _before_ the search can be undertaken. This cures what is in my mind a defect in the current wire-tapping laws. Yes and no. True, it makes it impossible to recover communication without the knowledge of one party. But it still goes well beyond the norms for private papers. The vast majority of private papers are, according to the law, just that - private. One is under no obligation to maintain "private papers" in any particular manner or for any period of time. Only very limited types of private papers (none for most people) have to be maintained at all. While, in general, the government can get a court order to force one to turn over documents that exist, one is not obligated to keep documents that are otherwise of no use in order to be ready should a court order happen sometime in the future. One can burn one's old love letters any time one feels like it. But enough philosophy. There are technical reasons to consider this proposal a bad idea. The main technical problem with the Staelin proposal is the requirement that the user maintain a large store of no longer useful but highly sensitive data in a secure manner for a period of time. This introduces an obvious storage burden (how does an encrypting phone or network connection store old keys?) that would make many kinds of otherwise simple encryption hardware and software far more complex and difficult to design and expensive to implement and operate. Consider a secure phone (like the TSD 3600 or STU III). A critical design feature of these devices is that they never have to emit secret keys outside their internal security boundaries. Consider, too, software that runs on PCs and workstations. Ordinarily, software that establishes, say, a secure Internet connection has no need to store any secret associated with the session anywhere. And that's a good thing - the file systems on most computers aren't secure enough to store keys, so including the key storage feature required by the Staelin scheme would entail implementing some kind of secure storage system that isn't otherwise needed by the application. Even if the design complexity is solved, there is the problem of maintaining the stored keys in a secure manner, introducing what would in most cases be a more serious security vulnerability than any other aspect of the application (since the keys would continue to exist long after the secure session has ended). Under the Staelin proposal, the design, implementation, and use of encryption software and hardware becomes much more complex, so complex that I honestly don't think we know how to do it. I touch on these points in discussing key escrow in general in my Senate testimony, ftp://research.att.com/dist/mab/testiomny.txt

1 0

resend: key escrow idea from David Staelin of MIT Lincoln Labs
by Matt Blaze 17 Dec '03

17 Dec '03

My first send of this message was garbled and truncated. Here it is again. Sorry. My comments included below Rivest's message. -matt ------- Forwarded Message Received: from amontillado.research.att.com (amontillado.research.att.com [135.104.21.154]) by nsa.research.att.com (8.7.3/8.7.3) with ESMTP id QAA04438 for <mab-local(a)nsa.research.att.com>; Tue, 13 Aug 1996 16:17:05 -0400 (EDT) Received: from research.research.att.com (research.att.com [135.104.117.5]) by amontillado.research.att.com (8.7.5/8.7) with SMTP id QAA24830 for <mab(a)issr.research.att.com>; Tue, 13 Aug 1996 16:20:09 -0400 (EDT) Received: from theory.lcs.mit.edu by research; Tue Aug 13 16:17:17 EDT 1996 Received: from swan.lcs.mit.edu by theory.lcs.mit.edu (5.65c/TOC-1.2S) id AA05040; Tue, 13 Aug 96 16:16:20 EDT From: rivest(a)theory.lcs.mit.edu (Ron Rivest) Received: by swan.lcs.mit.edu (5.65c/TOC-1.2C) id AA00335; Tue, 13 Aug 96 16:16:20 EDT Date: Tue, 13 Aug 96 16:16:20 EDT Message-Id: <199608132016.AA00335(a)swan.lcs.mit.edu> To: jim(a)rsa.com, gnu(a)toad.com, whitfield.diffie(a)eng.sun.com, mab(a)research.att.com, denning(a)cs.georgetown.edu Cc: staelin(a)ll.mit.edu, mld(a)hq.lcs.mit.edu Subject: Crypto Policy Variant Hi -- Here is another MIT professor's (Dave Staelin's) suggestion for a national crypto policy. I thought you might be interested in seeing it; given the difficulty of the debate, any variant, even if only slightly different from previous ones, should be considered. Feel free to pass this note around, or to post it... Here is Staelin's idea: (1) You can use any crypto you want, but you must keep a record of the crypto keys you used. (2) The government can ask for the crypto keys later, if they have a court order, just as they can ask for any of your other papers or documents. You must give the key(s) to them, just as you must turn over your private papers in such a situation. (There would have to be an appropriate penalty for losing the key...) The attractive feature of this proposal is that it puts encrypted communications in the same category as private papers; the government is required to give notice to (at least one of) the affected individual(s) _before_ the search can be undertaken. This cures what is in my mind a defect in the current wire-tapping laws. DISCUSSION In a variant of Staelin's proposal (my twist) you could append to each encrypted message an encrypted form of the message key. The encryption could be with the public-key of a trusted third party who will not (and legally may not) reveal the message key without notifying you first (or ensuring that you have been appropriately served with the corresponding warrant). For example, the ACLU might be such a TTP. This protects the government's right to access and protects the individual from the penalties (or benefits) of losing the key. This procedure is technically simple; what is more complex is ensuring that the TTP's are appropriately registered and protected from undue government influence. The use of such a TTP would in any case be optional; the communicants need not use a TTP if they understand their obligation to keep the crypto keys around for some period of time afterwards. In Staelin's proposal government gains access to the communications, but does not gain "real-time access" as desired by the FBI. This loss may be tolerable, given the benefit obtained (forcing access to be made in accordance with the Constitutional requirements for notification before search). The use of wiretapping encrypted communications as a preventive measure might be severely limited, but its use as a means of gathering evidence to force a conviction would be preserved. For international communications, each communicant might be required to use a TTP that is bound to honor the laws of his country (which TTP to be used should be the choice of the communicant). It may be seem a bit strange to force individuals to keep around information (keys) that they no longer really need. However, this is more-or-less the case for financial records right now. CONCLUSION The fundamental idea is to give the government a right to access encrypted communication in return for a guarantee that access may not be obtained until there is BOTH proper legal authorization AND proper prior notice to (at least one of) the communicants. Is this workable?? ------- End of Forwarded Message [Matt's comments follow] The requirement to store your keys for some period of time would, I think, be very unusal, legaly. As far as I know there are virtually no records that an ordinary individual is required to keep today under criminal penalty of law. One has to keep tax records if one expects to be able to document deductions if audited, but for people without deductions, no records need be kept (and even those who do but who destroy their records risk having their deductions disallowed, but face criminal penalties only if the govenment can prove you intended fraud. Not having records does not by itself constitute fraud, as far as I know). According to the original message: The attractive feature of this proposal is that it puts encrypted communications in the same category as private papers; the government is required to give notice to (at least one of) the affected individual(s) _before_ the search can be undertaken. This cures what is in my mind a defect in the current wire-tapping laws. Yes and no. True, it makes it impossible to recover communication without the knowledge of one party. But it still goes well beyond the norms for private papers. The vast majority of private papers are, according to the law, just that - private. One is under no obligation to maintain "private papers" in any particular manner or for any period of time. Only very limited types of private papers (none for most people) have to be maintained at all. While, in general, the government can get a court order to force one to turn over documents that exist, one is not obligated to keep documents that are otherwise of no use in order to be ready should a court order happen sometime in the future. One can burn one's old love letters any time one feels like it. But enough philosophy. There are technical reasons to consider this proposal a bad idea. The main technical problem with the Staelin proposal is the requirement that the user maintain a large store of no longer useful but highly sensitive data in a secure manner for a period of time. This introduces an obvious storage burden (how does an encrypting phone or network connection store old keys?) that would make many kinds of otherwise simple encryption hardware and software far more complex and difficult to design and expensive to implement and operate. Consider a secure phone (like the TSD 3600 or STU III). A critical design feature of these devices is that they never have to emit secret keys outside their internal security boundaries. Consider, too, software that runs on PCs and workstations. Ordinarily, software that establishes, say, a secure Internet connection has no need to store any secret associated with the session anywhere. And that's a good thing - the file systems on most computers aren't secure enough to store keys, so including the key storage feature required by the Staelin scheme would entail implementing some kind of secure storage system that isn't otherwise needed by the application. Even if the design complexity is solved, there is the problem of maintaining the stored keys in a secure manner, introducing what would in most cases be a more serious security vulnerability than any other aspect of the application (since the keys would continue to exist long after the secure session has ended). Under the Staelin proposal, the design, implementation, and use of encryption software and hardware becomes much more complex, so complex that I honestly don't think we know how to do it. I touch on these points in discussing key escrow in general in my Senate testimony, ftp://research.att.com/dist/mab/testimony.txt . While Ron's twist decreases some of the burden on the user it eliminates the main benefit of the Staelin proposal - that one cannot obtain cleartext without the knowledge of at least one party. The TTP could be compelled (as the phone company is now for regular wiretaps) to keep the request secret, under court order. And the design complexity problem doesn't even go away - in fact, it gets worse, since now there's a protocol with a third party involved. -matt

1 0