December 2003 - cypherpunks-legacy

[IRS] Elvis in Escrow
by Dave Del Torto 17 Dec '03

17 Dec '03

[from SF Examiner somewhere around 12-14 April 96] .............................................................................. "IRS Worker Took Peek at Celebrities' Records" [Associated Press] Memphis - A former IRS employee who said boredom had led him to peek at the tax records of President Clinton, Elvis Presley and other famous people has been acquitted of federal charges. Robert Patterson, 38, said it wasn't malicious - he was just trying to learn how to better use the Internal Revenue Service computers. "I was sitting there bored, so I started punching up names," said Patterson. .............................................................................. Hmmm. _We_ do it, it's "malicious cracking/hacking" and they toss us in the clink... _they_ do it, and it's "practice" (and they get acquitted). And _these_ are the people who want to escrow _my_ keys? As IF! Not only that, but also if the guy's so damn _bored_, why doesn't he spend some time FIXING the damn computer systems at IRS (see current cover of Information Week mag). Not that I particularly WANT them to fix the infernal revenue suckers... BTW, where do they _find_ these people? He's hacking around in Clinton's tax records and he _doesn't_ expect Secret Service agents crawling up his yin-yang within minutes? Obviously, "thinking too much" is _not_ this chap's problem.

1 0

TIME Daily: Policing China's Firewall
by nobody＠REPLAY.COM 17 Dec '03

17 Dec '03

>From http://pathfinder.com/time/daily/ Policing China's Firewall BEIJING: The Chinese government is requiring all Internet users and companies marketing Internet services to register with the police. Mailed warnings from the Beijing Police Public Security Bureau announce all individuals using the Internet must register with a special police section of Computer Security Supervision, and include their email addresses, presumably for monitoring purposes. The rules, which are taking effect as these notices surface, require each Chinese registering to sign a pledge agreeing to abide by Chinese law and respect state security. Users are also required to pay a 400 yuan (about $50) registration fee, and pay 100 yuan a month for six hours nline time. The fee, close to a month's salary many urban Chinese, could stop many from logging on. The country's some 100,000 Internet users are already barred from newsgroups containing 'undesirable' material such as government human rights violations and pornography. "This is the latest move to try to control the Internet," says TIME's Beijing Bureau Chief, Jaime Florcruz. "It dawned on the Chinese government that new ideas from overseas were leaking into the psyche of the Chinese people. It's still unclear how they will block the flow of information, especially when the government has such need for it, itself. Its a losing battle, especially in the provinces. If the Party cadres there want Internet access, or satellite TV, Beijing will have a hard time curbing them."

1 0

Re: What can the judge do to me? (fwd)
by Mark Eckenwiler 17 Dec '03

17 Dec '03

+ From: Black Unicorn <unicorn(a)schloss.li> + + "Contempts such as failure to comply with document discovery, for + example, while occurring outside the court's presence, impede the + court's ability to adjudicate the proceedings before it and thus touch + upon the core justification for the contempt power.... Similarly, + indirect contempts involving discrete, readily ascertainable acts, + _such as turning over a key_ or payment of a judgment, properly may be + adjudicated through civil proceedings since the need for extensive, + impartial fact-finding is less pressing." International Union, supra + (emphasis added). ... + I think it's clear, the court literally spells this out, that holding + a witness indefinitely until he complies with court orders is within + the discretion of a judge. Compelling through sanctions the + production of a "key" (though I'm not sure a crypto key is directly + contemplated) is likewise clearly permitted. Producing a physical key may or may not be testimonial under the "production privilege" doctrine established by the Supreme Court in Fisher and the Doe cases. Producing a *crypto* key -- if it exists only in one's mind -- is indisputably full-fledged Fifth Amendment testimony. I refer you to the language in Doe II (joined by all 9 Justices) distinguishing between "the key to a safe and the combination to a safe" -- the latter enjoying full Fifth Amendment protection from forced disclosure. (The message to which I'm responding was forwarded to me, as I do not subscribe to c-punks. If you want me to see a reply, cc me.)

1 0

Re: Bank transactions on Internet
by Charles Watt 17 Dec '03

17 Dec '03

-----BEGIN PRIVACY-ENHANCED MESSAGE----- Proc-Type: 4,MIC-CLEAR Content-Domain: RFC822 Originator-Certificate: MIIBvzCCAWkCEFmOln6ip0w49CuyWr9vDVUwDQYJKoZIhvcNAQECBQAwWTELMAkG A1UEBhMCVVMxGDAWBgNVBAoTD1NlY3VyZVdhcmUgSW5jLjEXMBUGA1UECxMOU2Vj dXJlV2FyZSBQQ0ExFzAVBgNVBAsTDkVuZ2luZWVyaW5nIENBMB4XDTk1MDUwODIw MjMzNVoXDTk3MDUwNzIwMjMzNVowcDELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1Nl Y3VyZVdhcmUgSW5jLjEXMBUGA1UECxMOU2VjdXJlV2FyZSBQQ0ExFzAVBgNVBAsT DkVuZ2luZWVyaW5nIENBMRUwEwYDVQQDEwxDaGFybGVzIFdhdHQwWTAKBgRVCAEB AgICBANLADBIAkEM2ZSp7b6eqDqK5RbPFpd6DGSLjbpHOZU07pUcdgJXiduj9Ytf 1rsmf/adaplQr+X5FeoIdT/bVSv2MUi3gY0eFwIDAQABMA0GCSqGSIb3DQEBAgUA A0EApEjzeBjiSnGImJXgeY1K8HWSufpJ2DpLBF7DYqqIVAX9H7gmfOJhfeGEYVjK aTxjgASxqHhzkx7PkOnL4JrN+Q== MIC-Info: RSA-MD5,RSA, ApDNkoCKfI0iz1XP4rYpl2XlbqF9/llmB3tLaunuqLWlnD5+VcGwYDNR/HJQa+AV 7s41qt0zFhiYbhidj7zh4e8= > From: Eric Young <eay(a)mincom.oz.au> > On Mon, 8 Apr 1996, JR Weaver wrote: > > with SFNB to purchase my own copy of 128-bit Netscape Navigator. You can make > > transactions over the net and SFNB does not limit you to 128-bit. Is it really > > that easy to break 40-bit? Don't you need access to a "fair amount of cpu > > power" to brute force crack 40bit? As far as I know client authentication is > Put put it in a word, 'yes'. > > > strictly username & password. What other authentication system exists?? > This would be a very good system to attack. > > ... (details on Eric's break-SSL saga) > > Please remember that I'm not talking about theory. Besides the person > working next to me, no-one at work knew I was participating in the brute > force beaking attempt. Well this is not totally true, the owner of the SGI > with 6 R4400 CPU's noticed that I was using a few of the CPU's but they > did not know what the programs were doing :-). > > I would say that RC4 40 should not be used if possible, especially to do > with anything to do with banking. > > eric (just putting in his own 2 certs worth). As Chief Scientist for SecureWare and one of the designers of SFNB's security architecture, I would like to make a couple of points regarding this thread: 1. SFNB customers are at absolutely NO RISK from Internet attacks 2. It's a whole lot harder to break into SFNB than just cracking a 40-bit RC4 key. 3. 40-bit SSL, when used within a properly designed security framework, is more than adequate for personal banking transactions. Along the way I'll outline my understanding of SFNB's plans for future security enhancements (as only an advisor to SFNB I cannot speak for them directly) with the hope of getting some useful feedback from the experts on this list. I'll apologize in advance for the length of this post, but while I enjoy this list for its occasional emphasis on crypto, sometimes the participents get a little too focused and forget that encryption does not equate to security. First, the U.S. banking system is very nice to account holders. The banks, rather than the customers, assume all risk associated with security problems in telephone banking, ATMs, etc... Internet banking is no different, which explains why so few banks have jumped onto the net with real transactions. If an SFNB customer should lose any funds due to a security problem, SFNB pays, not the customer. Second, in order to break the SSL-protected password of an SFNB account holder, you need access to the encrypted data. This is not easy to obtain over the Internet, and would generally require illegal activity in order to gain control of a host within the Internet infrastructure or collusion with the account holder. Should an attacker crack the key and obtain the account number and password of an SFNB account holder, they are clearly warned upon login that they are engaging in illegal activity. Once they have logged in, there is no way to transfer money out of the account without leaving a target address and phone number for the recipient. Furthermore, any payment to an individual or unknown entity would be made in the form of a physical check that would have to be cashed at a physical bank. The whole process is heavily audited with real-time audit filtering and pattern matching capabilities -- SFNB is, afterall, running on a military grade secure operating system (see SWP at www.secureware.com) Any security system that is deployed should be compared against the value you are trying to protect. It seems like a pretty big risk to an attacker -- and I assure you SFNB will prosecute. Finally, I whole-heartedly agree that 40-bit encryption is far too weak for many applications, and that the current export limitations are absurd. I have my own copy of the Xilinx development tool set at home and am quite capable of using it to design a 40-bit key cracking engine. I assume that others on this list might be able to as well. However, it is important to note that strong encryption does NOT equate to strong security. Encryption is merely one of many tools that are available in building secure systems. For example, a Web-based application running over 128-bit SSL would still be vulnerable to: - attacks against the server host - server spoof attacks - client side attacks, e.g. a Trojan Horse In my estimation, all of these are more likely (and more dangerous if successful) than an attacker cracking the 40-bit key used for a bank transaction. Any security sensitive application, such as Internet banking, that does not protect against all of these attacks is asking for trouble in the long run. Note that in the long run the Trojan Horse problem is the most severe for a banking application, for the bank cannot control end user PCs. And no matter how good the tools they are provided for their protection (see Troy at www.secureware.com) ultimately the bank cannot protect users from their own foolish actions. Also, despite the noise currently being made in Washington about relaxing export regulations, the current limitations are reality. Thus, it has been SFNB's goal from the start to design a personal banking solution that protects against all of these attacks and is secure running over 40-bits. At this time, as SFNB does not have this solution fully deployed, SNFB offers the 128-bit version of the Netscape browswer FREE to any SFNB customer that wants it. Just call their customer support line. The trick to secure personal banking at 40-bits is to remember that encryption can be used for many functions. For personal checking, it is the authenticity and integrity of a transaction that must be strongly protected, not the confidentiality. For the latter, 40-bits is sufficient, i.e., while confidentiality of account holder transactions is certainly important, the value of discovering this information does not justify the cost of an attack against the encryption. Thus, if the 40-bit encrypted traffic between the browser and server does not contain any repeatable authentication information, 40-bits is sufficient. For commercial accounts this is not the case and SFNB does is planning to use security beyond SSL. In the long term SFNB plans to disassociate the authentication of a transaction from its encryption through the use of SmartCard-based client-side private keys and bank-issued certificates. This has the advantage of permitting signatures to obtain non-repudiable transactions, making the bank "electronic commerce enabled". However, this feature has not been available in commercial browsers within the originally estimated time frame. We considered running the browsers transparently over SecureWare's Hannah product (www.secureware.com) to get client-side keying and a stronger protocol than SSL, but SFNB decided it was a better business decision to wait for client-side support in the browsers -- i.e, the cost to SFNB of distributing and supporting special client-side software >> cost of projected loss due to successful attacks on the bank during the estimated interval before browser support becomes available. It is, after all, SFNB's decision to make. They, not the customer, will pay any costs associated with a successful attack, whether financial or PR. But as the availability of client-side certificates has been pushed out, we have prepared two interim solutions, both of which solve the list of problems above. SFNB is currently debating whether to deploy one (or both): 1. Distribute a browser plug-in or locally resident Java applet to calculate an MD5/SHA hash computed over: - the user's password - a secret key created and distributed by SFNB that is unique to the account holder - a login challenge (random number) issued by the server This hash, rather than the password, would be sent over the SSL protected connection to authenticate the user. 2. Distribute SecureID or some other token-based authentication device to account holders. (Remember when banks used to give away toasters?). With either approach server-spoof attacks are prevented, for the server cannot access the local key material or token. Attacks against 40-bit keys are effectively negated, for any such attack would have to be mounted: - in real-time before the account holder logs out of the bank and invalidates the session key. SFNB imposes an inactivity log out. - from a gateway through which the account holder's SSL session is routed in order to grab control of the account holder's session due to the complex cookie mechanism being used. Note that even our final solution using hardware-based crypto is not perfect. But then there is no such thing as perfect security. SFNB does have, even with its current implementation, a system that is more difficult to defeat than current financial instruments such as paper checks, credit cards, ATM cards, etc... Charles Watt SecureWare, Inc. -----END PRIVACY-ENHANCED MESSAGE-----

1 0

IRO_nic
by John Young 17 Dec '03

17 Dec '03

4-16-96. Jour: "Bidzos Holds Key to Guarding Internet Secrets." Mr. Bidzos has made shrewd deals to build a powerful franchise, but he has also angered the government's security apparatus and some of his own customers and partners. Mr. Bidzos has fended off the government with a mix of stratagems and chutzpah. Lynn McNulty, an ex- Commerce official, said Mr. Bidzos always found "the open door that we hadn't thought about locking." Adds NSAper Stew Baker, "Jim has made a career out of bashing the NSA." 4-16-96. Fint: "A hacker's paradise. One computer on the Internet is broken into every 20 seconds." Despite a proliferation of computer security products ranging from "secure" server and browser software to firewalls, encryption and authentication schemes, computer break-ins are on the rise. Security experts say US Internet sites are under frequent attack by hackers from eastern Europe. But there are also now more than 20,000 aggressive, deliberately destructive hackers in the US and the number is said to be growing at a minimum of 5 per cent per month. Ironically, as the number of sophisticated hackers rises, there is a dire shortage of computer security professionals. IRO_nic

2 1

Re: [IRS] Elvis in Escrow
by jim bell 17 Dec '03

17 Dec '03

At 04:40 AM 4/16/96 -0700, Dave Del Torto wrote: >[from SF Examiner somewhere around 12-14 April 96] >.............................................................................. >"IRS Worker Took Peek at Celebrities' Records" >[Associated Press] > Memphis - A former IRS employee who said boredom had led him to peek at >the tax records of President Clinton, Elvis Presley and other famous people >has been acquitted of federal charges. > Robert Patterson, 38, said it wasn't malicious - he was just trying to >learn how to better use the Internal Revenue Service computers. > "I was sitting there bored, so I started punching up names," said Patterson. >.............................................................................. >Hmmm. _We_ do it, it's "malicious cracking/hacking" and they toss us in the >clink... _they_ do it, and it's "practice" (and they get acquitted). And >_these_ are the people who want to escrow _my_ keys? As IF! I have a solution to this problem. Jim Bell jimbell(a)pacifier.com

1 0

Re: why compression doesn't perfectly even out entropy
by tcmay＠got.net 17 Dec '03

17 Dec '03

At 2:07 PM 4/16/96, Perry E. Metzger wrote: >Timothy C. May writes: >> Well, I don't view any of the "simple definitions" of randomness as >> especially useful; that is, the simple definitions have a kind of >> circularity (implicit in the points we both make). For example, "an object >> is "random" if it has no shorter description than itself," the classic >> Solomonoff-Kolmogorov-Chaitin definition, is quite elegant, but doesn't >> help much in many cases. > >Except that it goes against our normal definitions of random in a >crypto context. A string that is compressable might still be >random. There is no reason you can't have a string of 20 1 bits in >a row in a perfectly random sequence, for example. Usually, random >sequences are non-compressable, but it is possible (though very >improbable) for Hamlet to appear out of a random number generator, >and it is of course quite compressable... Sure, compressibility is not a determinant of randomness....nothing is, actually. This is my point about there being no simple definition of randomness. However, "most" objects derived from a "random-like process" have no shorter description than themselves, by a variant of the pigeonhole principle (i.e., there are more things of some size than descriptions of less than that size, so most "random" objects, are, perforce, not describable in short descriptions). --Tim May Boycott "Big Brother Inside" software! We got computers, we're tapping phone lines, we know that that ain't allowed. ---------:---------:---------:---------:---------:---------:---------:---- Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)got.net 408-728-0152 | anonymous networks, digital pseudonyms, zero W.A.S.T.E.: Corralitos, CA | knowledge, reputations, information markets, Higher Power: 2^756839 - 1 | black markets, collapse of governments. "National borders aren't even speed bumps on the information superhighway."

1 0

Re: RSA & SDI
by vin＠shore.net 17 Dec '03

17 Dec '03

Steve Reid <steve(a)edmweb.com> exclaimed: >> It's true: >> FOR IMMEDIATE RELEASE >> Security Dynamics to Acquire RSA in Transaction Valued at >> Approximately $200 Million > >Okay, so what do we know about Security Dynamics? What are they expected >to do about licensing etc? I know a lot about SDI's technology and history. (Under contract to SDI, I just finished writing a draft FAQ on their ACE/SecurID user authenication system. It's unofficial and in-process, but I'm willing to e-mail the SecurID FAQ to anyone willing to read it and give me comments, criticism, and suggestions on how to improve it. Fair warning: it is 20,000+ words and written to educate a lay audience.) I haven't heard anything yet about SDI's position on RSA licences; but I doubt if there will be any surprises in that area soon. Among people associated with either company, it has been common knowledge that SDI and RSA folk have been very close for years, on both personal and professional levels. RSA's technical expertise has been apparent in SDI's user authentication system at several levels (albiet undocumented) and SDI's marketing expertise has doubtless informed RSA's policies in recent years. SDI, with over 150 salesmen on the street, fields the largest and most successful sales force selling Computer Security. SDI's SecurIDs tokens dominate the large-site (<1,500 tokens) corporate market for user authentication tokens with an estimated 70-80 percent of the market -- largely on the basis of the relative ease-of-use of the SecurID over its challenge/response competitors; SDI's early committment to client/server environments; and SDI's corporate promise to evolve to meet the changing CompSec threat. A SecurID generates the token's 4-8 digit token-code from an SDI-proprietary hash that puts Current Time and a token-specific key through a one-way function to create a PRN that changes every 30 or 60 seconds. All SecurID authentication calls also require two-factor validation; both the token-code and a user-memorized PIN must be submitted to the ACE/Sever for validation. There has never been any doubt -- given the evolving risks and the needs of on-line business community -- that SDI would eventually sell both authentication and encryption services. (It has also been obvious for years that SDI had, in its SecurID token-code, a neat symmetrical encryption key-generator already in widespread use in many networked environments. SDI had a mocked-up system that effectively used a SecurID token to generate DES keys seven or eight years ago, as I recall -- but apparently SDI never felt the market opportunities were sufficient to lure them into the political malestrom around crypto... until now.) I have no secrets to share, but it would surprise me if many SDI customers don't read a major opportunity for themselves in SDI's purchase of RSA. Last fall, SDI upgraded its ACE/Server to a new version (2.X) which manages user records on a fully-integrated Progress relational database. This integration of a SQL and 4GL-accessible RDBS brought a whole new level of functionality, complexity, and opportunity into ACE system administration -- but it also offers the security, scalability, and RDBS-to-RDBS communication options necessary to manage enterprise-wide IS security systems. Managing a large key-management system through a flat text database would be a nightmare. With the flexibility of an indexed RDBS, it becomes feasible to look to SDI's ACE/Server as a vehicle to hold and manage crypto keys, either PKC pairs or symmetrical keys, for an enterprise-wide system with multiple and distributed sysadmin sites. Some ACE/Server systems now support over 20,000 SecurID users, and the ESQL comm options will finally open the door to integrated multiple-server environments. >The question of the day is... HOW WILL THIS AFFECT CRYPTO? I have no answer on that one, but the marrage of RSA's technology and SDI's marketing muscle -- given RSA's credibility and SDI's installed base in commercial MIS sites -- unveils a world of interesting opportunities. One interesting thought: since SDI has a shoe-leather sales force on the street in 20-odd nations, SDI (with RSA) might be able to leverage an integrated crypto/authentication technology and sell in markets where RSA's algorithms doesn't even enjoy patent protection. In the best of commercial traditions, SDI would be selling a solution rather than a technology. Suerte, _Vin Vin McLellan +The Privacy Guild+ <vin(a)shore.net> 53 Nichols St., Chelsea, Ma. 02150 USA Tel: (617) 884-5548 <*><*><*><*><*><*><*><*><*>

1 0

Re: RSA-130 Falls to NFS - Lenstra Posting to sci.crypt.research
by E. ALLEN SMITH 17 Dec '03

17 Dec '03

From: Bruce Marshall <brucem(a)wichita.fn.net> > However, I do feel that you may have a valid point when switching >"hackers" to "opponents of the research." Anyone with an interest in >preventing or slowing down the progress in such a project would be more >dangerous in my mind than your average hacker. > Preventing that from happening would be necessary if it is decided >that such a threat truly exists. Actually, people would also have a motivation to turn in false results if they were being paid (perhaps in ecash) for their computer time. If they could take less time and turn in a supposedly correct job, they would be able to be paid the same amount for less work. Fortunately, it does appear possible to filter out bad ones. In creating such a paid system, keeping this possibility in mind would be needed. -Allen

1 0

RE: math patents
by jim bell 17 Dec '03

17 Dec '03

At 11:21 PM 4/15/96 -0700, Robin Felix wrote: >At 04/14/96 1457, jim bell may have written: >>At 09:08 AM 4/14/96 -0800, Lee Tien wrote: >>>My recollection from law >>>school is that the law was friendly to math patents in the period before >>>the Supreme Court weighed in. There were some PTO denials, which courts >>>reversed (I think the Court of Claims heard these back then). So I think >>>the trend was toward patenting processes even if mathematical until >>>Gottschalk v. Benson > >>I seem to recall reading that one of the breakthrough "algorithm" patents >>was from the 1970's, in which a rubber-curing/molding process's cure time >>was determined by a mathematical formula based on heat, pressure, mold >>shape, and a number of other variables. > >You're referring to Diamond v. Diehr, 450 U.S. 175, 195 (1981). I have a >half-finished article I wrote in 1994 on software algorithm patents, about >32K, available at <http://www.delfinsd.delfin.com/felix/Algorithm_Patents.htm. It's the good >part, the background material minus footnotes. Although it's a bit dated, >the description of foundational cases is still accurate. Thanks for the reference, and yes, the article was very interesting. As usual, it sounds like the legal system has gotten the whole thing screwed up. I am still mystified, however! If I understand the thrust of the legal cases you cited, purely mathematical algorithms are still not patentable, yet the patents on public-key cryptography are about the most purely mathematical ones that could be imagined. They are not an element in the process, they ARE the process. To recap, I've asserted (with no definitive proof, obviously) that when public-key cryptography was invented, in about 1976, the US government decided that it wanted to restrict it as much as possible from ordinary US citizens. Due to the 1st amendment, legal restrictions on speech would not fly, and copyright was out because that would only have protected one particular program, if even that much. The final alternative, patent protection, was essentially unavailable (or thought to be so) because of the traditional non-patentability of software and mathematics. Patents would not have prevented the Russians from using RSA, nor any other foreigners, so as far as I can see the only group of people impaired by the RSA patent were American citizens as a group. To me, there are at least two mysteries that need to be solved here. The first is why the cryptography patents were issued in the first place. The second, and perhaps even more incriminating, has to do with why the patents were applied for. Because the patent application has to be filed within a year of disclosure, the RSA patent would have to have been filed at latest by April of 1977. Yet, that predates some of the earliest cases in your article by a year or more. I've never heard a cogent explanation as to how R, S, and A decided that a "doomed" patent application was worthwhile, unless they had some insider information that the Gottschalk v. Benson case would be essentially ignored and the patent granted anyway. This isn't unrealistic paranoia or conspiracy theory, either. It is reasonable to assume that since the government would be the first, largest beneficiary of keeping RSA out of the hands of the public, and since the government made up and controlled the patent office and the court system as well, it could easily have made a decision that RSA was going to be patented, and Messr's Rivest, Shamir, and Adleman told of their luck in plenty of time to apply for a patent. The other cases from 1978 on might simply have been window-dressing, to make it look like the courts had had a change of heart unrelated to the subject of public-key cryptography. My question is this: "Is there anything you're aware of that contradicts this impression?" Or, is there a way to confirm this?

1 0