December 2003 - cypherpunks-legacy

Re: Remind me why we're so mad at Netscape
by Bill Stewart 17 Dec '03

17 Dec '03

At 09:33 PM 12/2/95 -0500, Matt Blaze <mab(a)crypto.com> wrote: >Could someone please remind me what it is we're mad at Netscape about? >As far as I can tell it's some combination of the following offenses: > >(a) - Jim Clark made a speech in which he revealed that he thought the >government would be a player in determining the way cryptography ends >up being deployed on the Internet. He was quoted in the trade press, >but it was unclear exactly which words were actually his. Asked to >clarify, he said that Netscape would implement mandatory government >access across its product line only if required to by law, but he >observed that things seem to be moving in that direction. I share his >pessimism, unfortunately, unless we find a way to shift the winds. I give Netscape a lot of credit for the way they've handled things so far; their US commercial version supports strong crypto (modulo a few bugs :-), and interoperates with their free exportable version, which is itself far stronger than a minimal 40-bit version could have been. And they're adding secure email to the new version. And (while they can't officially say this, of course) anybody overseas can pirate the strong-crypto version if 40 bits aren't enough. PGP gave anybody who wanted to do a bit of work the ability to do trusted communications, but it's still not widely used because it does take extra work; the most important things it's done have been to raise public awareness and make it obvious to everybody that the cat's out of the bag, which also pressured the government into dealing with the issue. Netscape is putting built-in strong crypto in the hands of tens of millions of people; fait accompli like that make it much harder for governments to impose stupid and offensive rules. Maybe Netscape will come out with GAKed versions for export to nosy-governmented countries like France and the US; as long as the main version has secure communications, and they're open about how their crypto really works, we can talk securely domestically, and other folks can pirate them to use instead of GAKware. If the government wants to pay extra to support special hardware crypto modules for their own use, and the modules do GAK, that's an internal problem (as long as we can subpoena their records.) Of course, in case the main US versions ever have GAK as a default, I do reserve the right to flame Netscape again :-) >(d) Their stock price is very high, many times greater than their >profits and physical assets would seem to justify. I'm not sure I >understand the implication here. I think it's that "Netscape is now in a financial position that pushes them to care more about making some profits to justify their appallingly high stock price so they're more likely to lose big bucks if they don't sell out, and I should have bought it at $70..." >Disclaimer: I'm employed full time by a soon-to-be-tri-vested major >player in the military industrial complex, and us sellouts like to >stick together. Definitely. Back when I was a tool of the military-industrial complex, I was two floors down from Matt, in an RF-shielded room :-) #-- # Thanks; Bill # Bill Stewart, Freelance Information Architect, stewarts(a)ix.netcom.com # Phone +1-510-247-0663 Pager/Voicemail 1-408-787-1281 # Anybody notice that Microsoft's Wide Open Road ad has barbed-wire fences # on both sides of the road?

1 0

Re: Use of PGP as an export?
by Bill Stewart 17 Dec '03

17 Dec '03

At 09:09 PM 12/2/95 -0800, Ted Cabeen <cabeen(a)netcom.com> wrote: >I think this has been brought up before, but I could only find one reference >to it in the archives and it wasn't too helpful, so I'll ask again. If a >university provided a copy of PGP for use on their unix machines and a >non-resident, non-citizen *used* the copy of PGP on the server, but did not >download it onto their own machine, but instead just ran PGP on the server >alone, would it be a violation of the ITAR? My school is interested in >putting a copy of PGP on the university server and wants to know if they >should somehow restrict access to citizens and legal residents only. Thanks. That's not giving technical data to the foreigner, that's providing a service; the ITAR doesn't seem to restrict that. It's not an especially secure way to operate, but that's an inherent problem with multi-user systems or file servers. One way to implement it that would be only mildly insecure would be to put PGP on a file server, with execute-only permissions; users of client machines still could be attacked by somebody faking out NFS, but they wouldn't have to send their passphrases across the net the way they would in a telnet session. #-- # Thanks; Bill # Bill Stewart, Freelance Information Architect, stewarts(a)ix.netcom.com # Phone +1-510-247-0663 Pager/Voicemail 1-408-787-1281 # Anybody notice that Microsoft's Wide Open Road ad has barbed-wire fences # on both sides of the road?

1 0

Re: Questions/Comments on ecash protocol
by Hal 17 Dec '03

17 Dec '03

From: Ian Goldberg <iang(a)cory.EECS.Berkeley.EDU> > I read these specs for a little while last night. Here are some of my > questions/comments. To prevent this message from becoming huge, I won't > quote much from the protocol document itself; the URL is above if you want it. > I'll ignore the spelling/grammar; they can be fixed later. I was also reading it, and I share some of Ian's questions, but for some things I have a few different guesses. > What is the function f, used in the payment_hdr to hash the payer_code > and desc fields, as well as in WITHDRAW3 to calculate N = f(n) * r**h? > There is reason to believe it is SHA, but I thought I saw some stuff in the > client that indicated that the output of f is 132 _bytes_ long (but I'm > not exceptionally sure of this, not having source and all). One rather cryptic sentence, which Ian alludes to later, relates to cancelling payments: "The 'payer_hash' is the one-way image of a by the payer generated random number...". In the diagram it shows it as f(payer_code), where payer_code is shown as "random code generated by player". (And, as Ian points out later, the document inconsistently says that "the player generated random number" should be kept secret while requiring that it be sent to the shop - at least, this is inconsistent if it refers to payer_code.) Assuming the use of the word "a" is not a typo but refers to some number, this suggests that f() is at least potentially a two-input function, some value a and a player generated random number. > Please clarify what parts of the payment_hdr are shipped around. The document > says that the shop checks if the descr_hash matches the description. > Since the description is in the second part of the payment_hdr, does that > mean that both parts are sent to the shop? Noticing that the payer_code > (which the payer is supposed to keep secret) is in the second part, this > doesn't seem to be right. Also, the document states that the payment hash > is not sent from the payer to the shop or from the shop to the mint. However, > the payment hash is just the SHA of the first part of the payment_hdr, > which _is_ sent around, so although the payment hash isn't transmitted > per se, it can certainly be calculated. It seems that the whole payment_hdr is sent to the shop, and only the portion before the line is sent to the bank. This is enough, as you say, to calculate the payment hash, so the bank can decrypt the coins. This prevents the shop from changing any of the information in that first part of the payment header before sending it to the bank. My question in this part relates to coins made out to "@" which we have been told can be deposited by anyone. How does the bank know to which account to deposit such a coin, given a deposit message? The shop's ID does not seem to be present in such a message, assuming that the shop_accID field of the payment_hdr just has "@" in that case. Is it the userid field in the userhdr message which tells the bank this info? BTW since apparently both deposit and payment messages are not encrypted, coins made out to "@" are in danger of being stolen both while en route from customer to shop and from shop to bank. This is significant from the point of view of payee anonymous systems, which will need to use such coins. More encryption will be necessary when such coins are passed around. > A (very slight) privacy concern: the payer's bank is sent in the clear, > which gives a very small amount of information about the identity of the > payer. More on who knows what later. Well, I would think identification of the payer's bank will be necessary for any coin based system so you know where to cash in the coins, so I don't think this is going to go away. Of course as of now everyone has the same bank so it is not an issue. > Is it in fact the case that all coins on one payment use the same payment hash > when encrypting their signatures (the field sig in onl_coin)? The signatures are xor'd with the payment hash, but this is not the main way they are encrypted - they are then encrypted with the bank's public key. The purpose of this xor is not so much to protect the coins as to bind them unbreakably to the payment header. Since the coins are always sent around with that payment header I think they all do use the same payment hash. > If (M,e) is the mint's public modulus/exponent, and (N,h) is public mod/exp > for a particular coin denomination, are the following statements true: > > o If n is the coin number (in onl_coin, assumedly the same n as used in the > withdraw request), and hdr is the first part of the payment header, > then sig (in onl_coin) equals > > ([ SHA(hdr) XOR ((f(n)^(1/h)) mod N) ] ^ e) mod M I was wondering about this too. There is a reblocking problem in trying to concatentate "pure RSA" operations. In particular M must be at least as big as N. This is not necessarily a problem, but it is a slightly unusual constraint on key creation. However I agree overall that this formula is a reasonable reading of the doc. > o A deposit (which contains a userID in the userhdr, a payment_hdr in > the dep record, and a pair (n,sig) for each coin) is accepted by the bank iff > > ([ SHA(payment_hdr) XOR ((sig^(1/e)) mod M) ] ^ h) mod N = f(n) > > _and_ either payment_hdr.shop_accID corresponds to userID, > or a payer_code is supplied such that > payment_hdr.payer_hash = f(payer_code). There also needs to be some clause for the "@" payee. In that case I think the payment is accepted if the signature checks, with credit to the userID account. That business about cancelling via payer_code I agree is not very sensible. It doesn't seem necessary - the coin can just be re-spent, made out to someone else. > Where is the facility for tracing double spenders? Perhaps it's just > part of the "incomplete" part of the document, but I can't even see > where it would fit in to what we've got; neither the withdrawal nor the > payment messages seem to encode _any_ information about the payer in > the coins, and the bank cannot seem to know who withdrew the coin that > ended up being spent twice (due to the blinding). There is no such thing! This is one of the most common misconceptions. This version of ecash does not trace double spenders. It prevents double spending by checking each coin to make sure it has not already been spent. Tracing of double spending is only necessary in offline systems where coins are not checked right away, but that is not present here. > Is there a way to change the public key associated with an account? > Is it just a meeter of sending another OPENACC1 message? My guess is there would need to be some manual intervention to do this. > Exactly what kind of anonymity/privacy/security does ecash offer? > Let's examine who knows what. > [...] > If Eve or Mitch can determine either r (the blinding factor) used in > the withdrawal, or the payer_code, used in the payment, they can steal the > money. This has ramifications to Doug's "agnostic" banks; more security > has to be added to the present ecash system if unblinded withdrawals are > allowed. This also brings up the "Netscape" question: how are these numbers > generated? Does it have to do with that 25 character string you enter > at the beginning? I've noticed a bit in the program that seeds a RNG with > (time(0) ^ ((getpid()<<16)|getuid())). I think publication of _at least_ > the code pertaining to blinding factor and payer_code generation is > _absolutely vital_. Well, as I said, I think this payer_code business is pretty questionable. I'm sure the next version of the doc will clear that up a great deal. As far as determining r, that is not possible from the protocol messages. Chaum has proven that it is absolutely indeterminate. So I don't understand what you mean about "more security has to be added to the present ecash system if unblinded withdrawals are allowed." Do you just mean that the coin messages should not be sent in the clear in that case? I observed that coin withdrawal messages can be sent in the clear in some postings I made last year - the use of r effectively encrypts them. But of course that can't be done with unblinded messages. There have been claims that the long string you type in at startup time deterministically seeds the RNG, so that if you lose your wallet but you tell DigiCash this string (via some secure channel, presumably) they can reconstruct the coins you should have. Presumably they could figure out what the r values were when you withdrew all your coins, reconstruct the coin numbers, and see which ones haven't been spent. This is both good and bad, in that it provides a well understood amount of entropy (rather than relying on whatever it can scrounge up), but of course is vulnerable to lazy typing. Also, you have to write down the string, and if someone found this they could perhaps get your coins. > I think I'll stop here; comments from anyone, and especially answers to my > questions from DigiCash people, are welcome. I'm sorry if it's not as > complete as you (or I) would like; I'm quite tired, as my building had > two fire alarms in a row at 3am this morning... > > - Ian "Well, it's a start..." Very good comments. I'm sure the next version will be much better if they are careful to clear up the kinds of issues you have raised. Hal

1 0

Questions
by rmarquis＠umich.edu 17 Dec '03

17 Dec '03

Hello. I was wondering if anyone would be able to help me out. I am writing a research paper and I need some interviews for it. If you could answer any of these questions about security, I would greatly appreciate it. Thanks for your time. --Bob Marquis Please send responses to rmarquis(a)umich.edu - How can PGP help secure something like e-mail? - Are there any encryption schemes which are "unbreakable"? - What would someone need to do to send an e-mail message which cannot be read or altered by anyone else, or is it not possible? ____________________________________________ Robert Marquis, Jr. University of Michigan - Dearborn e-mail: rmarquis(a)umich.edu www: http://www.umd.umich.edu/~rmarquis

2 1

Re: The future will be easy to use
by ahupp＠primenet.com 17 Dec '03

17 Dec '03

>That's today's method, more or less. It doesn't address my needs. The >name you pick for your key may or may not mean anything to me. It might be >pronounceable, giving it some advantage over a radix-64 string, but it >might also be non-unique, making it worthless as an identifier. > >What means something to me is whatever name (or symbol) I assign to the >person behind the key in question. That's the one in my mind and therefore >the only one of interest to me. You, however, don't know what's in my >mind. You don't even know my preferred symbol set. > Why not give it two names? A local name that could be a icon or something, and a universal name (i.e. MD5 hash of key) -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6 mQBtAzCNppQAAAEDALhWZl7IuGZ9zZT5bACo0b/1L0Nv0C72vKHIO3IHh+cwpHHa 2Ozb9aeO0UvXGwkkZIYgUm0EvmzKh7yb1GTLvBp5kXpR3I9w+Yj4LGlBDERpUWw6 x4ED49pwDnz1Hl5FBQAFEbQYYXNoIDxhaHVwcEBwcmltZW5ldC5jb20+ =PtJK -----END PGP PUBLIC KEY BLOCK-----

1 0

bulk RC4 brute forcing
by lyalc＠ozemail.com.au 17 Dec '03

17 Dec '03

Some time ago, I wrote about testing multiple plain/cipher pairs against a key as a possible speed up for brute forcing 40 bit RC4 key cracking. I have finally done something about it, written some code, and run tests which I believe gives a about 6-8 times improvement over single key/plain/cipher testing against RC4-40 encryption. Basically: A single RC4 master "key schedule" is generated. This is copied to an master array of 126 RC4_keys (126 chosen due to segment boundary probs). Then each of 126 plain/cipher (P/C) pairs are tested for a match. Acquiring the plain/cipher pairs in real life is another question. If a match is found, the pair is marked 'found', and testing continues on the remaining unfound P/C pairs. This loops until all 126 plain/cipher/keys have been tested and found. 8 plaintext, 8 cipher bytes are used. Keys are 8 bytes, the last 5 of which are variable (40 bits). Test results : A test set of data was created by incrementing a key byte, and making a P/C pair. Then all keys bytes are set to 0, and testing commenced. Typically, a 486/33 with the above in 'C' code running on DOS achieves about 15000 tests per second. One extended test ran about 480 million tests in 7.5 hours and found 68% of the keys - approx 17,700/sec, averaging 5.6 million tests per found key. My reasoning follows thus: For 126 plain/cipher pairs, with "randomly" generated keys, one valid key/plain/cipher pairs 'should' be located in 2^33 key tries (126 is approx. 2^7) 15000 tests/sec across 126 P/C pairs is about 119 keys/second tested. at 119/second, 2^33 key tests will take 835 days. This should "guarantee" a key match is found. By contrast: The "bruterc4.c" code used by this forum earlier showed approximately 2200 key tests per second on my machine. Testing 2^40 keys at 2200/sec will take 5784 days to guarantee a key match (using 2^39, 2892 days). This is a 6.9(3.46) ratio, that finds a single key match. Finding all 126 keyswould should take approximately 293 years in "bulk" mode, or 1996 years in single mode (126x5784 days). The code is available, and will be posted here is desired (it is messy). Ideally, faster key/plain/cipher testing could be accomplished if a larger array of keys could be used. The Intel segment problem has prevented me for making larger arrays - I don't know how to turn these features in my compiler (yes - I am a beginner at coding, but the "huge" directive in Borland C did not seem to work, and I don't know why - yet). Tests on 31, 63 and 126 P/C pairs showed results of 10689, 13326 and 15689 tests/sec, respectively. This indicates array size has a direct relationship with test/sec. I invite others who can better manipulate statistics, or better exeprienced, to comment, refute, or otherwise contribute to this. lyal All mistakes in this message belong to me - you should not use them!

2 1

Re: Info on Netscape's key escrow position
by Hal 17 Dec '03

17 Dec '03

I will join the chorus of criticism: From: Jeff Weinstein <jsw(a)netscape.com>, quoting Jim Clark: > I said that if we are to use this encryption technology in business, we must > have a better solution than to limit keylength or put keys in escrow. I don't understand this. What is the better solution? No other solution seems to be discussed by Clark. Most of his message is devoted to rationalizing the inevitable changeover to key escrow, which he just dismissed as unacceptable. > All > governments of the world have a valid concern about terrorism and other > activities of concern to the security of their nations. All of them will > continue to restrict our ability to provide products to their markets unless > we build in some mechanism that allows them to legally access > information that is in the interest of their national security. This isn't true! The US government (and I believe most other Western governments, France excepted) does not presently provide any restrictions on providing products to US citizens which have strong cryptography. There are serious constitutional questions about whether it could ever do so. Clark's message seems to be based on the assumption that legal restrictions on crypto are a fait accompli. Nothing could be further from the case. What makes me mad is that his messages seems to promote an attitude which could increase the likelihood of these kinds of restrictions. If people think the battle is already lost, they will be less likely to fight. IMO this is going to be a big, knockdown fight and the eventual outcome is far from certain. > A lot of ordinary citizens are rightly concerned about their own privacy. I > am one of them. I do not want the government to snoop on me, but in fact the > government, through the FBI, can now tap my phone without my knowing it by > simply getting sufficient evidence that I am conducting illegal activities, > then presenting this evidence to a court to get permission. I have no say in > the matter. Again Clark is preaching acquiescence. We have no say in the matter. Our phones can be tapped any time the FBI wants. What is the relevance of this to the issue of network communications privacy? Doesn't this again sound like a justification for giving up the battle before it is joined? Where is his righteous indignation? Where is the recognition that the right to tap communications is not granted by God but an accident of technology, one which can be taken away by technological progress as easily as it was granted? > If we as a company were to take the position that in no case will we allow > a government to get access to our encrypted messages, or refuse to allow > key escrow with our products, the governments of the world will quickly put > us out of business by outlawing the sale of our products in their countries. False! I can open a company today in this country and take exactly that position, and the US government will NOT put me out of business. What country is Clark living in? > The fundamental issue is how do we accommodate the requirements of governments, > while protecting our rights as citizens. As I wrote in another context, when a question is framed in terms of conflicts between the rights of governments and citizens, it is based on a totally misguided premise. There are no conflicts between the rights of governments and citizens in our country. The only rights are those of citizens. The real issue is the conflict between the rights of the citizens to privacy and freedom versus their right to security and safety. I think we all know what Ben Franklin had to say about that. > None of this represents the position of Netscape with respect to what we > will do. But if we do not come up with a solution to this problem that is > acceptable to each government, we will not be able to export our products, > except with a short key length (e.g. 40 bit keys), and that will not be > acceptable to corporate customers in other countries. They will create their > own solution, and we will not be able to sell to a larger world market. In > fact, we could even be ordered by our own government to establish a key > escrow system for its use inside the US. Again Clark attempts to anticipate the advent of a totalitarian style system of controls on access to cryptography in this country. Should we really base our policies on the assumption that this will actually happen? Will the American people stand by for such an unprecedented invasion of privacy? Some governments are capable of all kinds of evil restrictions on products. Is Netscape committed to building in provisions so that their software won't access sites owned by Jews, so they can sell in Arab countries? Obviously they will draw a line somewhere. I urge them to consider the moral issues involved in endorsing Big Brother GAK systems before accepting them as just another cost of doing business. > I chair an industry group called the "Global Internet Project", with members > from almost twenty companies, including companies from Asia and Europe. This > was the central issue we all agreed upon this morning, and we are putting > together a policy statement whose purpose is to educate lawmakers on the > importance of quick resolution of this matter. I am afraid that what the companies really want is global consistency. That way they can use one set of policies for all countries, and no one company can get a competitive advantage over others by producing stronger privacy protections, because they will be forbidden by law to do so. Whether the policies protect freedom and privacy or not is not really relevant from this view. If this is the way things develop, I predict that it will not be acceptable to the general public. Netscape more than anyone has seen how much pressure can be brought through a public perception of weak software security. Our own brute force key hacks as well as the RNG seed problems have well demonstrated that. Do you think the same thing won't happen, only far worse, if the government tries to force weak software down people's throats? I understand that Jeff has stated that Netscape is actually opposed to GAK. It would have been nicer to hear that from Jim Clark, in unequivocal terms. The overall tone of his message, as I have pointed out above, is one of accommodation and compromise with government restrictions on the rights of free citizens to communicate securely. He almost seems to think that free strong crypto is already illegal. I think he needs to take a good hard look around and remember that he is still a free citizen of the United States. My guess is that he has spent too much time in the company of law enforcement people. He had better start trying to understand the grass roots members of his market if he wants to continue to succeed. Hal Finney hfinney(a)shell.portal.com

1 0

Mr. Bubble II
by nobody＠REPLAY.COM 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Tim May, 12/3/95, 2:22 PM : >My thesis is that both Netscape and Microsoft are in positions at this time >to either do the right thing (tm) or to help build in the tools for a >police state, an Orwellian surveillance state. Gee, Tim, this is *your* thesis? >Netscape, being the dominant browser company, and Microsoft, being the >dominant OS company, are in special positions to "build in Big Brother." >I'm not claiming they are, just that they are clearly in a position to make >it technologically more feasible to make non-GAK illegal. They both need to >carefully think about the role that's been "given" to them (whether by >fortune, hard work, or being in the right place at the right time) and do >what's right. And? >Strong words, perhaps, but the implications of mandatory key escrow are Not strong at all, actually. >quite clear. We debated these points for a long time during the Clipper >debate, and later when "Software Key Escrow" began to rear its head. I >won't repeat these arguments against GAK here, but will take this >opportunity to quote from a new book that actually quotes my words: [self-congratulations deleted] >It is important that such companies as Netscape and Microsoft fully >understand that crypto policy will largely determine civil liberties in >this country and other countries for a long time to come. And they must >understand that they can influence the direction. Bill Gates, after some >early waffling, seems to now fully understand the implications of GAK and >has written persuasively against it. Jim Clark does not seem to me have >thought about it as deeply, or perhaps has views of civil liberties which >are not at odds with mandatory key escrow, the "open door policy" mentioned >above. Like many entrepreneurs, he is an opportunist in every sense, good and bad. He has yet to advance -- "graduate" maybe -- beyond that point. NS's stance re GAK is a golden opportunity for Mr. Bubble either to graduate or to get popped: either patted on the back by Papa State or popped in the noggin. When "opportunity" is at stake, he's a shrewd maneuverer; but when pitting his integrity against federal charges is at stake, he's still a kid -- he doesn't see the opportunity in it. >And time is of the essence. Things move very fast. It is no longer the case >that a law is passed, then companies respond to the new legal regime with >their own policies and products. Companies, especially in high tech, are >"partners" from the start, as we saw with the Clipper development (where >AT&T had known about Clipper for years prior to the first public >announcement, and was cooperating in the development of it, not to mention >the other companies such as Mykotronx, VLSI Technology, etc., which were >involved in secret for years). Partner, schmartner: "partners" can be adversarial, and adversarial relations can become *very* adversarial. Here's the question: is the dog gonna wag the tail or vice versa? The USG has, as we all know, demonstrated its infinite capacity to knuckle under in the face of hardened opposition, whether announced or de facto. NS is in a privileged position to drag the LEA establishment onto the mat, with the whole of the American public watching. And it stands to gain from doing so, as do we all. But Mr. Bubble wants to be friends, wants to receive genteel toasts. With the kind of money Mr. Bubble stands to make -- whether from NS or from subsequent ventures -- he should be maybe just a bit tougher. If he's looking for models, names like Carnegie and and Bismarck come to mind. (Note that their progeny *still* have money, not 2 years later but *generations* later.) >It is only sheer speculation on our part (some of us, at least) that >negotiations about GAK have been going on with the major software >companies. Jim Clark, for example, learned what he knows about key escrow >_someplace_, and it probably wasn't from our list or from articles he'd >read. I'm betting, but could of course be wrong, that he and other folks at >Netscape (and I mustn't leave out Microsoft, Sun, SGI, Apple, etc.) have >been briefed on key escrow and that various negotiations are already >underway. This would match how things were done with Clipper, and would >explain Clark's voiced support for the need for GAK. On the contrary, it is sheer speculation that negotiations about GAK *haven't* been going on. This shit doesn't happen by magic. >I hope Jeff W. and Jim C. can have some _long_ chats. The stakes are too >high for product decisions to be made without full awareness of the >implications. The statements from Jim Clark do tend to imply a kind of >defeatism, and even Jeff's comments seemed laden with qualifications about >"only if the government requires us to." As Hal Finney noted in his post, >it's as if the Netscape people are preparing for the inevitable. Maybe it's >not an indication that GAK is being considered within Netscape, but maybe >it is. After all, one rarely hears "only if we have to" qualifications on >things that are truly from out in left field. Yes. >And what Netscape agrees to put in future releases of its browsers or its >servers could have dramatic effects on the whole climate. Yes. [social darwinism deleated] >Should Netscape play ball with the NSA or refuse to cooperate? I'm not >suggesting that Netscape "break the law." Actually, there are *no* laws at >present about GAK or about the use of strong crypto within the U.S., and >most of us want to keep it that way. Thus, Jim Clark and Netscape could >strongly lobby for keeping things the way they are, and could even say "If >foreign governments demand GAK, let them build it in themselves--we will >not produce the software to run a police state." NS should implement strong crypto, make it publicly available by FTP and in a box, and see how the USG responds. The public is on its side. >And if export laws demand GAK in exported products, Netscape should "do the >right thing" and have two versions. It may add to their costs a little, but >it's better than building in the machinery for a GAK law to later be >passed. Yes. >(Explain something to me. I have never, ever understood why it is a concern >of the U.S. government that we help build in GAK for foreign governments, >that we make sure that products intended for export to France or Syria have >GAK that allows those governments to read the traffic of their citizens. >And if the concern is that exported versions of software must be readable >to the _United States_, then this is a non-starter in terms of sales in >many or even most foreign countries! I'm sure France will welcome with open >arms a version of Netscape that allows the NSA to read the traffic of >French citizens. Oh, by the way, what legal jurisdictions will be involved >in obtaining the escrowed keys of foreigners? The answers are both clear >and murky, if you catch my drift.) Because it isn't interested in freedom, here or anywhere else. It is interested in a "controlled burn" distribution of stability and instability. Its willingness to do business with its "enemies" has been amply demonstrated. But your drift is clear, and it is right. >If the U.S. insists on GAK _within the U.S._, as many of us fear is the >long-term danger, then all bets are off anyway. But I would hope that >Netscape does nothing to make it _easier_ to make this the case! On the contrary: That's when bets are on. That's when *you* -- and all of us -- might have to start putting our money and our homes in Corralitos on the line. That's when Black Unicorn will upload the papers he claims to have, when I will start wrapping PGP-encrypted mail in pretty-looking wrappers. That's when we'll have no one but ourselves to blame. Not even Netscape. >A viable thing for Netscape to do is to announce forthrightly that it will >separate the issue of export from what it sells in the U.S., that there >will be NO GAK included in any U.S.-sold packages. The quest for an "all >world" version, freely exportable, should not take precedence over the >civil liberties issues. And I predict that any slight losses in market >share or slight increases in product cost will be _less_ than the effects >Netscape will see if their product comes to be associated with "Big Brother >Inside." Yes. But NS should act first, explain second. If NS wants money, that's how to get it. >Enough for now. Yes. Hieronymous. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQBVAwUBMMIHhr3g0mNE55u1AQFI3QH/Y32u8ASp61MPjkaeQJJly7qwQ5BuGNYx XndZMAPBVXJjOr4Mx5BieouM5GG5WgBc1fMTTRrnAJtSHQO3dgwwBQ== =WCJS -----END PGP SIGNATURE-----

1 0

Sixth Conference on Computers, Freedom, and Privacy
by Hal Abelson 17 Dec '03

17 Dec '03

Please redistribute widely **************************************** The Sixth Conference on Computers, Freedom, and Privacy will take place at the Massachusetts Institute of Technology on March 27-30, 1996. CFP96 is hosted by MIT and by the World Wide Web Consortium. Since its inception in 1991, the series of CFP conferences has brought together experts and advocates from the fields of computer science, law, business, public policy, law enforcement, government, and many other areas to explore how computer and telecommunications technologies are affecting freedom and privacy. Registration for CFP96 will open on December 8. Conference attendance will be limited. Due to the enormous public interest in CFP issues over the past year, we encourage you to register early. SPECIAL NOTE TO STUDENTS: There are a limited number of places available at a special student rate. These will be allotted on a first-come first-served basis, so register as soon as possible. Events planned for this year's conference include: - Federal prosecutors square off against civil-liberties lawyers in a Supreme Court test of the "Cryptography Control Act of 1996", which criminalizes non-escrowed encryption. - Authors Pat Cadigan, Tom Maddox, Bruce Sterling, and Vernor Vinge divine the future of privacy. - College administrators, students, lawyers, and journalists role-play scenarios that plumb the limits of on-line expression on campus networks. - Panels on international issues in privacy and encryption; on the struggle to control controversial content on the Internet; on tensions between copyright of digital information and freedom of expression; on threats posed by electronic money to law enforcement, privacy, and freedom; on mass communication versus mass media. You can register for CFP96, starting December 8, by US Mail, by fax, or via the World Wide Web. For more information, see the CFP96 Web page at http://web.mit.edu/cfp96 or send a blank email message to cfp96-info(a)mit.edu

1 0

a foot here, a foot there -- pretty soon your mouth is *really* full (was: Re:Netscape, Corporations, and GAK Support)
by Dave Del Torto 17 Dec '03

17 Dec '03

At 11:36 AM 11/30/95, Timothy C. May wrote: >It's possible that Jim Clark--whose quotations I have not yet seen denied >by Netscape--is merely naive on matters of mandated key escrow. It's >possible that he hasn't given it much thought. I watched him in acquisition mode once upon a time and I rather doubt this: I imagine that he's giving this considerable thought (he has the time while counting stacks of shares on his bed every night ;), watching this space and letting the "petty officers" navigate through this reef for now. His statements so far indicate nothing more to me than that he's just playing his cards very close for now so as not to alienate anyone: this is what a captain should be expected to do when the waters are potentially this "dangerous." Why would/should he chop the Feds off at the knees until he knows exactly which way _their_ smoke blows? They're still trying to figure out what the hell we're up to, and if we can manage to stay ahead of their lumbering giants (Freeh, et alia), it'll pretty much stay that way for a long time. Anyway, no policy statements coming from Netscape NOW can be a reliable indicator of where they're going to be -- even in a year -- on crypto policy or on the internal development. All we're seeing for the forseeable future is trial balloons and other strategic positioning. I bet Jim's read the Book of Five Rings... > It's also possible that he >sincerely is supportive of plans for Big Brother to have an "escrowed" copy >of our conversations, diaries, travel plans, etc. Jim may "appear" a tad "hawkish," but he's no dope. Look, a 70% share, even with momentum behind it, can slim down mighty fast with bad choices and lots of fast dogs at his heels and he knows it. Let me put it this way: "the higher they sell, the faster they drop." Tim, you're absolutely right that speaking out NOW (and directly at him) is the surest way for him and others to have data on which to base their future decisions. If there are other solutions for modules Netscape intends to provide (like...NS2.0's Mail module + GAK vs a c-neutral Eudora with an optional MOSS translation plug-in), then he'll lose market share proportional to how much we scream about it in public (I'm doing daily vocal exercises, just in case ;). If he makes enough bad choices, like throwing his full weight behind GAK and other atrocities, he'll end up like DigiCash *would* if they kept/keep the bank protocol hidden. I just refuse to believe he hates his work that much. At the worst, I see a special "gaak" version for the Feds, but I sure as hell wouldn't buy it (and I bought my copy of Netscape). It would be nice to hear from him here directly, though. One can only tolerate so much pussyfooting around before one becomes snippy. dave ________________________________________________________________ "I prefer a _real_ whorehouse to The Theatre." --Dorothy Parker

1 0