- cypherpunks-legacy - lists.cpunks.org

Net Papa: Global Internet Taxes Inevitable
by nobody＠REPLAY.COM 17 Dec '03

17 Dec '03

(09/09/97; 12:00 p.m. EDT) By Douglas Hayward, TechWire GENEVA -- Internet taxes are inevitable, according to the man dubbed the "Father of the Net." The only way to avoid global chaos is to create an international agreement on how to do it, added Vint Cerf at a meeting of the Internet Society here. Cerf co-developed the TCP/IP[LINK] protocol on which all Web and Net transaction depend. ...Taxation of the Internet, also called "bit taxes," must be well planned, Cerf said. "And it must also be thought through on a global scale -- not parochially," he said. In the United States. alone, there are 30,000 taxing authorities that might be interested in taxing transactions on the Internet, said Cerf, adding that right now, there is no way to determine which of those authorities should have jurisdiction over a particular transaction. ..."If something is becoming an infrastructure that is important for people's daily lives, then governments will have the right to be concerned about the public's safety and well-being," Cerf said. "When you build roads, you make rules about how people are to behave on these roads, in order to protect people." TW http://192.215.107.71/wire/news/1997/09/0909tax.html

1 0

Re: netscape's response (source code review)
by John Gilmore 17 Dec '03

17 Dec '03

> > "Netscape has also begun to engage an external group of world-class > > security experts who will review our solution to this problem before > > it is sent to customers." > > A group which offered to review the first version, but > > Netscape refused. > Do you mean that cypherpunks offered to review the netscape code > if only we made all the source available on the net? I think "the group" was RSADSI, based on a remark of Jim Bidzos. However, I do think that, like the S1 cipher, your code would get examined for interesting features and flaws by the cypherpunks if you released it. > We will be having at least some of our code reviewed by a > wider audience, but I don't yet know which code, or how wide a review > group. If anyone has specific suggestions for pieces of code that > you would like to see widely reviewed (such as RNG and seed generation) > let me know. It is becoming gradually clearer in cryptanalysis that you can't test security of pieces in isolation. Their interaction with the surrounding code and protocols is key to their security. Ross Anderson's paper at Crypto last month was all about this (``Robustness Principles for Public Key Protocols''). There were also several papers there that showed how you couldn't just treat hash functions like MD5 as black boxes, since embedding them naively into signature protocols made it possible to do things like turn a signed short message into a signed longer (modified!) message. So far the c'punks haven't done anything clever to your protocols; they've exploited basic weaknesses in key length and key generation. There's still a lot of potential in active attacks, three-cornered attacks, replays, etc, that is unexplored. > I realize that some cypherpunks think that we should make all of > our code publicly available. In an ideal world that would be great, > but we live in a world with politicians, crooks, lawyers, stockholders, > etc... Don't expect to see us posting our entire security > library source code to cypherpunks. Naah. I think NCSA should've made Mosaic publicly available, because they wrote it with our tax dollars. And I hold it against them that they started the trend of "zero-cost personal-use binaries but no commercial use" that many Net users still confuse with Real Free Software (free as in freedom). But Netscape owns its code, it can do whatever it wants with it. I'd still encourage you to err on the side of release. The strongest tendency in the security industry is for "security by obscurity", i.e. if we just keep this quiet, nobody will figure it out. Customers, even less sophisticated than vendors, often let the vendors get away with it. But it doesn't stop the crooks, and stopping the crooks is what your customers are paying you to do. Code that gets public scrutiny, like published scientific papers, gets debunked and honed and made to really work. Much faster than code and ideas that only circulate in small, closed groups. The reason Kerberos V5 is a lot more secure than V4 is because its security features and flaws could be publicly discussed. Steve Bellovin wrote a whole paper about what was wrong in V4, and lots of people got to chew on that and think about how to fix it. The question that only Netscape management can estimate is: what damage would it risk to your business, if you released *this much* crypto code instead of *that much*. Particularly if you copyright it and prevent commercial re-use without licensing, I doubt it will help your competitors much. There is the risk of revealing a flaw that makes it easy to crack. That has to be balanced against the risk of having such a flaw and not noticing it for years. And finally, I thought a marketing goal was to make your security scheme (SSL) a standard throughout the industry? In that case, publishing it *and allowing* commercial use would encourage people to adopt it -- which is what I think you want. [We all realize that "publishing" crypto code is unconstitutionally regulated by the State Department. So there are logistics to the release process. But you are presumably solving them for the 128-bit domestic version; you can use the same procedures to let people download whatever crypto source code you release.] John Gilmore

1 0

Re: (none)
by James A. Donald 17 Dec '03

17 Dec '03

At 06:05 AM 9/21/95 GMT, Phil Karlton wrote: >James A. Donald <jamesd(a)echeque.com> writes: > Whenever you need a random number, take a one way checksum, > for example MD5, of the most recently altered part of that > buffer. Use that as your random number. > > How is this any better than feeding the data into the MD5 > hash as I go? This is not a rhetorical question. Assuming that MD5 loses no entropy, it is identical, or very similar in strength, since in the algorithm that I described the most recently altered part of the buffer depends sensitively on all previous noise accumulated into the buffer, so if the total cumulated entropy is larger than your block size, you are OK. However the algorithm I described simply used less computation, but the overhead of continually doing MD5 is probably modest. No matter what you do, if you cumulate a hundred bits of entropy, and if you use a one way hash to generate random numbers so that your session keys do not leak information about your entropy, you are going to be safe against a random number generator attack. I suggested accumulating a very large amount of entropy, but obviously this is just gilding the lily. --------------------------------------------------------------------- | We have the right to defend ourselves | http://www.jim.com/jamesd/ and our property, because of the kind | of animals that we are. True law | James A. Donald derives from this right, not from the | arbitrary power of the state. | jamesd(a)echeque.com

2 1

Re: Entropy vs Random Bits
by David Van Wie 17 Dec '03

17 Dec '03

>Your use of the word random is incorrect: The throw of a dice is >random, but only contains 2.6 bits of entropy. The throw isn't random, the data read from the die after it is thrown is random. The use of the term in many of the postings I have read indicate the need for an "unpredictable" quantity in most cases. This quantity may be drawn from a source that has entropy, but it is random. >> why invent new terms? Why use them to mean at least two different things? >This is old term of the art, a term of information theory: We use >the same word because entropy in information theory has the same >measure as entropy in thermodynamics. > >In both cases the entropy, measured in bits, of an ensemble of >possible states is sum of - P(i) * lg[P(i)] over all the possible states. In thermodynamics, counting states in this fashion is a dicey proposition, but I appreciate the clarification. Still, it seems to me that the property "bits of entropy" is often substituted for the actual "bits of random data" and is just as puzzling as gathering the "entropy of cool steam"! One can't _do_ anything with a dimensionless measurement. By which I mean, the measure of a property of data is not the data itself, so it still seems like the usage is odd, at times. However, your explanation does address some of the phrases I have seen. Does this mean that entropy is conserved in information theory? dvw

1 0

Re: Please send me SSL problems...
by jsw＠neon.netscape.com 17 Dec '03

17 Dec '03

In article <9509210118.ZM154@tofuhut>, jsw(a)netscape.com (Jeff Weinstein) writes: > I don't think that the API that SSLRef export is not particularly interesting. Yikes!! I can't believe I wrote that. What I meant was: I don't think that the API that SSLRef exports is particularly interesting. --Jeff -- Jeff Weinstein - Electronic Munitions Specialist Netscape Communication Corporation jsw(a)netscape.com - http://home.netscape.com/people/jsw Any opinions expressed above are mine.

1 0

Re: House National Security committee guts SAFE, worse than nobill
by Jonah Seiger 17 Dec '03

17 Dec '03

At 2:17 PM -0700 9/9/97, Declan McCullagh wrote: >This version of SAFE, in fact, is //much worse// for crypto freedom than >having no bill passed at all. True. <...> >It's time for advocates of crypto-freedom to turn obstructionist and >oppose all legislation dealing with encryption. And expect to accomplish what? To stick our heads in the sand now would just make it easier for the FBI to roll right over us. We still need to fight the expected FBI key recovey amendment when the Intelligence Committee and Commerce Committee vote this week, and then onto the floor (perhaps next year). Not to mention the Senate. This battle is FAR from over. It would be a serous mistake to give up now. Best, Jonah PS: Interestingly, Reuters is reporting that the Administraon has "serious problems" with the Dellums/Weldon Amendment: Clinton official not backing new encryption plan WASHINGTON, Sept 9 (Reuter) - The Clinton administration has serious problems with a new congressional proposal to tighten export limits on computer encoding technology even though it prefers the approach to one contained in earlier legislation, a top official said on Tuesday. Under Secretary of Commerce William Reinsch told Reuters that an amendment approved by the House National Security Committee earlier on Tuesday would give the secretary of defense veto power over encryption export decisions. "Giving the secretary of defense a veto is inconsistent with the president's executive order and inconsistent with the policies of four prior administrations," Reinsch said. "The administration thinks all relevent agencies should have a seat at the table and none should have a veto." Under current policy, enacted by presidential order last year, encryption export requests are reviewed by the Departments of State, Defense, Energy, Commerce and Justice, along with the Arms Control and Disarmament Agency. The most powerful encryption products cannot be exported unless they contain a feature allowing the government to decode any messages covertly. The amendment, authored by Rep. Curt Weldon, Republican of Pennsylvania, and Rep. Ron Dellums, Democrat of California, would require the president to set "the maximum level of encryption strength that could be exported from the United States ... without harm to the national security of the United States." Products at or below the established level could be exported after a one-time review specified by the secretary of commerce with the concurrence of the secretary of defense. The proposal virtually gutted the bill to which it was attached. The original bill, written by Virginia Republican Rep. Bob Goodlatte, would greatly relax export controls. Reinsch said the administration supported the "harm to the national security" standard. "It gives the administration the authority it needs," he said. "We'd much rather have this than (the original)." Software companies, civil libertarians and Internet user groups all favor relaxing the current limits and expressed strong concerns about the Weldon amendment. The amendment appeared to outlaw differential treatment currently accorded to some encryption products used by financial institutions or subsidiaries of U.S. companies. Reinsch said that section of the amendment "could be more artfully drafted." He also criticized the proposal for not requiring companies to export products with features allowing for government access to coded messages, an approach known as key recovery. The current policy "links all of the parts together and uses export controls as a device to move towards key recovery," he said. "We believe export controls should include key recovery." --Aaron Pressman((202-898-8312)) Tuesday, 9 September 1997 18:02:46 RTRS [nN0972124] * Value Your Privacy? The Government Doesn't. Say 'No' to Key Escrow! * Adopt Your Legislator - http://www.crypto.com/adopt -- Jonah Seiger, Communications Director (v) +1.202.637.9800 Center for Democracy and Technology pager: +1.202.859.2151 <jseiger(a)cdt.org> http://www.cdt.org PGP Key via finger http://www.cdt.org/homes/jseiger/

11 18

Letter sent to SJ Mercury staff on CA SJR-29 ...
by Ernest Hua 17 Dec '03

17 Dec '03

Date: Tue, 9 Sep 1997 13:26:34 -0700 (PDT) From: Ernest Hua <hua(a)chromatic.com> To: business(a)sjmercury.com, computing(a)sjmercury.com, state(a)sjmercury.com Subject: Why no coverage of CA resolution on Encryption? Cc: hua(a)chromatic.com Why was there no coverage of CA State resolution SJR-29? I find it using the search facility at: http://www.sen.ca.gov/www/leginfo/SearchText.html And the result is at: http://www.sen.ca.gov/htbin/ca-billpage/SJR/29/gopher_root2:[bill.current.s… The on-line magazine has a full article by Will Rodger on this: http://www.zdnet.com/intweek/daily/970908b.html Apparently there was some attempt by the Clinton Administration to cover up their lobbying effort. I don't understand why the Administration would care about a California state RESOLUTION of all things. Why does the Clinton Administration want to prevent a state legislature from speaking its mind? And what's with this attempt to claim "copyright" on that fax? Please get some answers on this! The US Senate/House will be voting on important encryption legislation in the coming days. The people of this country deserves to have a open, informed, serious discussion of one of the most important privacy issues of the information age. We cannot afford to let a few intelligence and law enforcement agencies dictate policy TO us against our will. Ern

1 0

Re: Patents and trade secrets was: Encryption algorithms used in PrivaSoft
by Pat Farrell 17 Dec '03

17 Dec '03

thad(a)hammerhead.com (Thaddeus J. Beier) writes: > At this point, in this country, a patent is secret until it is issued. This will change in the US fairly soon. It is fallout of one of the world-wide trade and tarriff treaties -- we have to make our patent process be more in line with the rest of the world. One of the big technical challenges that the PTO and PRC have is how to release in-process patents securly. (PRC is the systems integrator for the PTO's APS (advanced Patent System) that had all the text and images of all patents since 1970 online.) They have even talked about putting patents on the WWW, but actually doing it is quite a way off in the future. Pat Pat Farrell Grad Student http://www.isse.gmu.edu/students/pfarrell Info. Systems & Software Engineering, George Mason University, Fairfax, VA PGP key available on homepage #include <standard.disclaimer>

1 0

Re: USA Today on Fear of Credit Cards over Net
by Randy Catoe 17 Dec '03

17 Dec '03

At 07:35 PM 9/20/95 -0400, Perry E. Metzger wrote: > >Re: The risk of credit cards. > >I suppose that indeed there are large risks elsewhere in the credit >card system. However, I think that the credit card system itself is >stupid and insecure and ought to be scrapped -- sending around account >numbers as magic keys to get payment is a stupid move. Its not >suprising how large credit card fraud is. > >One of the great hopes I have for cryptographic technology is its >ability to lower the incidence of fraud, and thus lower transaction >costs a lot. Someday, hopefully, everyone will be able to be a credit >card merchant because you won't have to trust the merchants not to >steal. > >Perry > > I'm told that the revenue lost to fraud in the credit card industry is around .15 percent of the gross purchase value. I'm also told that the credit card companies actually face higher costs from disputes, i.e. when you call them up and busy out a person to resolve a question on you bill. Randy

2 1

Re: Net Papa: Global Internet Taxes Inevitable
by jf_avon＠citenet.net 17 Dec '03

17 Dec '03

> --------------------------------------------------------------------- > This mail is brought to you by the e$pam mailing list > --------------------------------------------------------------------- > (09/09/97; 12:00 p.m. EDT) > By Douglas Hayward, TechWire > > Cerf co-developed the > TCP/IP[LINK] protocol on which all Web and Net transaction depend. Net-Papa bullshit! > ..."If something is becoming an infrastructure that is important for > people's daily lives, then governments will have the right to be > concerned about the public's safety and well-being," Cerf said. Absolute Bullshit! Bit tax comes down to taxing thinking! This guy might have been a (past tense) a smart programmer but he'd better shut up about the rest... jfa -- Jean-Francois Avon, Pierrefonds(Montreal) QC Canada DePompadour, Societe d'Importation Ltee Finest of Limoges porcelain and crystal JFA Technologies, R&D consultants physicists and engineers, LabView programing. PGP encryption keys at: http://w3.citenet.net/users/jf_avon http://bs.mit.edu:8001/pks-toplev.html ID# C58ADD0D : 529645E8205A8A5E F87CC86FAEFEF891 ID# 5B51964D : 152ACCBCD4A481B0 254011193237822C

1 0