December 2003 - cypherpunks-legacy

Distributed Key Breaking
by Mark Cooke 17 Dec '03

17 Dec '03

Just as a quick thought - given the prevelance of Web Browsers - has anyone considered writing a Java Applet that would could run key space searches and factoring in an easily distributed manner. This would seem to be a 'reasonable' way to gain access to more CPU power - even though the Java code would not be as efficient as a native app. Perhaps as a supplement to the more 'traditional' methods that have been used in the past. Regards, Mark ------------------------------------------------------------------------------ Mark Cooke The views expressed above are mine Systems Programmer and do not reflect in any way the University Of Birmingham current policy of my employers. ------------------------------------------------------------------------------

2 1

Re[2]: What's the "Human Interaction Institute" at CMU For ???
by ssalgaller＠CCGATE.HAC.COM 17 Dec '03

17 Dec '03

Dear Concerned Citizen, Am I the only one worrying about the use of technology to implement a "New World Order" ??? If not, where else can I post this message ??? Yes, AOL has a movie trivia board, but I'm serious ! A similar concern could be made about biotechnology: with gene splicing, it would be possible to create a race of "sub humans" to do slave labor and fight wars. This has been done in several Sci-Fi movies, but it's not going to stay fiction much longer. Stephen S. PS: Shouldn't these be the questions that CMU worries about? Which is worse, genetic slavery or "dirty duck" photos ?

3 2

Re: why compression doesn't perfectly even out entropy
by rick hoselton 17 Dec '03

17 Dec '03

At 10:07 AM 4/16/96 -0400, Perry E. Metzger wrote: >...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... But even if it came from a completely random source, it would still make a bad one-time pad. When people say "compressable" or "algorithmic complexity" or "random", a context is always implied. In the context of "fair coin flips" the text of Hamlet is NOT compressible. Because no string is more likely than any other. Any algorithm that could compress that string, will, on the average INCREASE the length of "fair coin flip" strings it tries to compress. Under the context of "pads that might be used for cryptographic purposes" the text of Hamlet is quite compressible. An attacker is much more likely to test for such a stream than one that appears more random. So, even if you got "Hamlet" from a perfectly random source, you should reject it for crypto purposes. There is an exception to this rule. If you are so revered as a cryptographer that no analyst would believe that you would deliberately choose a non-random pad, then it would be safe to use Hamlet if it appeared in a random source. It is amazing that one's reputation can affect the randomness of the bitstrings one uses. PS: I have written a compressor that can compress ANY string to the single byte "X". There are 2**n different decompressor programs, where n is the bit size of the original file. All you have to do is specify the number of the correct decompressor program, and you have the original file. Note that no computer is required for either the compressor or the decompressor. (patent pending)

4 4

Spaces in passwords
by Ben Rothke 17 Dec '03

17 Dec '03

Do spaces (ASCII 20) in passwords make them less secure? I was speaking with a security admin who feels that spaces decrease the effectiveness of passwords. I thought that they would actually do the opposite & increase password efficacy, as most password dictionary attacks do not attempt to attack embedded spaces. An attack trying to penetrate embedded spaces would seem to make the dictionary orders or magnitude larger. Any comments? Ben ------------------------------------------------------------ The views expressed are exclusively my own & not that of my employer -----------------------------------------------------------

5 5

[NEWS] Security Dynamics Buys RSA
by Dave Del Torto 17 Dec '03

17 Dec '03

<http://www.rsa.com/ANNOUNCE/buyout.htm> For information about RSA: Patrick Corman or Lisa Croel Corman/Croel Marketing & Communications (415) 326-9648 or (415) 326-0487 Corman(a)cerf.net or Lcroel(a)mediacity.com FOR IMMEDIATE RELEASE Security Dynamics to Acquire RSA in Transaction Valued at Approximately $200 Million Cambridge MA and Redwood City, CA -- April 15, 1996 -- Security Dynamics Technologies, Inc. (NASDAQ: SDTI) and RSA Data Security, Inc. today announced that they have signed a definitive agreement for Security Dynamics to acquire RSA, a Redwood City, California vendor of encryption software. The transaction is intended to be carried out by the merger of RSA and a wholly-owned subsidiary of Security Dynamics in a tax-free transaction accounted for as a pooling of interests. For the year ended December 31, 1995, RSA had revenues and net income of approximately $11,6000,000 and $950,000, respectively. Upon consummation of the merger, Security Dynamics will issue or reserve for issuance 4,000,000 shares of its Common Stock in exchange for all of the outstanding shares and options to acquire shares of RSA. Based on the closing price of Security Dynamics Common Stock on the Nasdaq Market on April 12, 1996, the transaction is valued at approximately $200,000,000. The transaction is scheduled to close in June 1996. The consummation of the merger is subject to approval by the stockholders of both Security Dynamics and RSA and the satisfaction of antitrust and certain other conditions. In connection with the merger agreement, certain RSA stockholders, who currently own approximately 70% of the outstanding shares of RSA, have agreed to vote their RSA shares in favor of the merger. "RSA's technology is an excellent fit with Security Dynamics' enterprise-wide security solutions," said Charles R. Stuckey, Jr., President and Chief Executive Office of Security Dynamics. "In the rapidly growing Internet and Intranet markets, security has become on of the major issues. The merger of RSA and Security Dynamics combines our user identification and authentication technology and RSA's public key and encryption technology, each of which is a de facto standard. We believe this brings into a single organization the management and technical talent needed to bring to market the most effective security applications." "The synergy between the two companies is outstanding," said Jim Bidzos, President and Chief Executive Officer of RSA. "RSA and Security Dynamics technologies must be delivered as an integrated solution to corporate and Internet users. The best way to accomplish this is for the two companies to become one." According to both executives, RSA will continue its existing license business as a subsidiary of Security Dynamics. Security Dynamics Technologies, Inc. Security Dynamics designs, develops, markets and supports a family of security products used to protect and manage access to computer-based information resources and is the de facto standard for secure user identification and authentication. The Company's family of products employ a patent-protected combination of super smart token technology and software for hardware access control products to authenticate the identity of users accessing networked or stand-alone computing resources. The Company's customers include Fortune 500 companies and financial institutions as well as academic institutions, research laboratories, hospitals and federal, state and foreign government organizations. RSA Data Security, Inc. RSA is a recognized world leader in cryptography, with millions of copies of RSA software encryption and authentication technologies installed and in use worldwide. RSA's encryption technology is embedded in Microsoft Windows, Netscape Navigator, Intuit's Quicken, Lotus Notes, and hundreds of other products. RSA technologies are part of existing and proposed standards for the Internet and World Wide Web, CCITT, ISO, ANSI, and IEEE as well as business, financial and electronic commerce networks around the world. RSA develops and markets platform-independent software developers' kits and end-user products and also provides comprehensive cryptographic consulting services. Founded in 1982 by the inventors of the RSA Public Key Cryptosystem, the company is headquartered in Redwood City, Calif.

1 0

[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

None
by K00l Secrets 17 Dec '03

17 Dec '03

> If the Diffie-Hellmann patent covers all kind of public key crypto, > you need a license from Cylink, i.e. BSAFE is not enough, and if it > doesn't you can use El Gamal without a license. Are there any freely available implementations of El Gamal?

3 2

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