December 2003 - cypherpunks-legacy

State of the Union Address
by bubbabill＠whitehouse.gov 17 Dec '03

17 Dec '03

Hear that the State of the Union next Monday has a section on Internet - networks - critical infrastructure protection et al. Anyone have any details?

1 0

Ultra computer
by Nobuki Nakatuji 17 Dec '03

17 Dec '03

Ultra computer which NEC had the calculation speed of the world maximum of about 1000 times of the super computer to was decided to be developed. Ultra computer will be completed in 2001. It has the performance that the calculation which takes 10000 years with the personal computer is made of 3, 4 days. ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com

4 3

Cybersitter censors code
by Secret Squirrel 17 Dec '03

17 Dec '03

>>Turns out, someone had inadvertly installed this piece of garbage >>called CyberSitter, which purports to protect you from nasty internet >>content. Turns out that it does this by patching the TCP drivers and >>watching the data flow over EVERY TCP STREAM. Can you spot the offense >>word in my example? It's "NUDE". Seems that cybersitter doesn't care if >>there are other characters in between. So it blanks out "nu */ #de" >>without blanking out the punctuation and line breaks. Very strange and >>stupid. Find out who it is and fire his ass for sabotage of the company computer systems.

1 0

[Long] How to recover private keys for various Microsoft products
by pgut001＠cs.auckland.ac.nz 17 Dec '03

17 Dec '03

How to recover private keys for Microsoft Internet Explorer, Internet Information Server, Outlook Express, and many others - or - Where do your encryption keys want to go today? Peter Gutmann, <pgut001(a)cs.auckland.ac.nz> Summary ------- Microsoft uses two different file formats to protect users private keys, the original (unnamed) format which was used in older versions of MSIE, IIS, and other software and which is still supported for backwards-compatibility reasons in newer versions, and the newer PFX/PKCS #12 format. Due to a number of design and implementation flaws in Microsofts software, it is possible to break the security of both of these formats and recover users private keys, often in a matter of seconds. In addition, a major security hole in Microsofts CryptoAPI means that many keys can be recovered without even needing to break the encryption. These attacks do not rely for their success on the presence of weak, US-exportable encryption, they also affect US versions. As a result of these flaws, no Microsoft internet product is capable of protecting a users keys from hostile attack. By combining the attacks described below with widely-publicised bugs in MSIE which allow hostile sites to read the contents of users hard drives or with an ActiveX control, a victim can have their private key sucked off their machine and the encryption which "protects" it broken at a remote site without their knowledge. Once an attacker has obtained a users private key in this manner, they have effectively stolen their (digitial) identity, and can use it to digitally sign contracts and agreements, to recover every encryption session key it's ever protected in the past and will ever protect in the future, to access private and confidential email, and so on and so on. The ease with which this attack can be carried out represents a critical weakness which compromises all other encryption components on web servers and browsers - once the private key is compromised, all security services which depend on it are also compromised. A really clever attacker might even do the following: - Use (say) an MSIE bug to steal someones ActiveX code signing key. - Decrypt it using one of the attacks described below. - Use it to sign an ActiveX control which steals other peoples keys. - Put it on a web page and wait. On the remote chance that the ActiveX control is discovered (which is extremely unlikely, since it runs and deletes itself almost instantly, and can't be stopped even with the highest "security" setting in MSIE), the attack will be blamed on the person the key was stolen from rather than the real attacker. This demonstrates major problems in both Microsoft's private key security (an attacker can decrypt, and therefore misuse, your private key), and ActiveX security (an attacker can create an effectively unstoppable malicious ActiveX control and, on the remote chance that it's ever discovered, ensure that someone else takes the blame). Background ---------- About a year ago I posted an article on how to break Netscape's (then) server key encryption to the cypherpunks list (Netscape corrected this problem at about the same time as I posted the article). However more than a year after the code was published, and 2 1/2 years after a similar problem with Windows .PWL file encryption was publicised, Microsoft are still using exactly the same weak, easily-broken data format to "protect" users private keys. To break this format I simply dusted off my year-old software, changed the "Netscape" strings to "Microsoft", and had an encryption-breaker which would recover most private keys "protected" with this format in a matter of seconds. In addition to the older format, newer Microsoft products also support the PKCS #12 format (which they originally called PFX), which Microsoft render as useless as the older format by employing the RC2 cipher with a 40-bit key. In a truly egalitarian manner, this same level of "security" is used worldwide, ensuring that even US users get no security whatsoever when storing their private keys. However even RC2/40 can take awhile to break (the exact definition of "a while" depends on how much computing power you have available, for most non-funded attackers it ranges from a few hours to a few days). Fortunately, there are enough design flaws in PKCS #12 and bugs in Microsofts implementation to ensure that we can ignore the encryption key size. This has the useful - to an attacker - side-effect that even if Microsoft switch to using RC2/128 or triple DES for the encryption, it doesn't make the attackers task any more difficult. By combining the code to break the PKCS #12 format with the code mentioned above which breaks the older format, we obtain a single program which, when run on either type of key file, should be able to recover the users private keys from most files in a matter of seconds. A (somewhat limited) example of this type of program is available in source code form from http://www.cs.auckland.ac.nz/~pgut001/pubs/breakms.c. Because it's meant as a proof-of-concept program it's somewhat crude, and restricted to recovering passwords which are single dictionary words. Note: This does not mean that using (say) two words as a password instead of one will protect your private key. All it means is that I haven't bothered to write anything more sophisticated - no doubt anyone who was serious about this could adapt something like cracklib's password-generation rules and routines to provide a more comprehensive and powerful type of attack. Similarly, by making trivial changes to the key file data format it's possible to fool the program until someone makes an equally trivial change to the program to track the format change - this is meant as a demonstrator only, not a do-everything encryption breaker. To use the program, compile and invoke it with: breakms <Microsoft key file> <word list file> Here's what the output should look like (some of the lines have been trimmed a bit): File is a PFX/PKCS #12 key file. Encrypted data is 1048 bytes long. The password which was used to encrypt this Microsoft PFX/PKCS #12 file is 'orthogonality'. Modulus = 00BB6FE79432CC6EA2D8F970675A5A87BFBE1AFF0BE63E879F2AFFB93644D [...] Public exponent = 010001 Private exponent = 6F05EAD2F27FFAEC84BEC360C4B928FD5F3A9865D0FCAAD291E2 [...] Prime 1 = 00F3929B9435608F8A22C208D86795271D54EBDFB09DDEF539AB083DA912D [...] Prime 2 = 00C50016F89DFF2561347ED1186A46E150E28BF2D0F539A1594BBD7FE4674 [...] Exponent 1 = 009E7D4326C924AFC1DEA40B45650134966D6F9DFA3A7F9D698CD4ABEA [...] Exponent 2 = 00BA84003BB95355AFB7C50DF140C60513D0BA51D637272E355E397779 [...] Coefficient = 30B9E4F2AFA5AC679F920FC83F1F2DF1BAF1779CF989447FABC2F5628 [...] Someone sent me a test Microsoft key they had created with MSIE 3.0 and the program took just a few seconds to recover the password used to encrypt the file. One excuse offered by Microsoft is that Windows NT has access control lists (ACL's) for files which can be used to protect against this attacks and the one described below. However this isn't notably useful: Most users will be running Windows '95 which doesn't have ACL's, of the small remainder using NT most won't bother setting the ACL's, and in any case since the attack is coming from software running as the current user (who has full access to the file), the ACL's have no effect. The ACL issue is merely a red herring, and offers no further protection. Further Attacks (information provided by Steve Henson <shenson(a)bigfoot.com>) --------------- There is a further attack possible which works because Microsoft's security products rely on the presence of the Microsoft CryptoAPI, which has a wonderful function called CryptExportKey(). This function hands over a users private key to anyone who asks for it. The key is encrypted under the current user, so any other program running under the user can obtain their private key with a single function call. For example an ActiveX control on a web page could ask for the current users key, ship it out to a remote site, and then delete itself from the system leaving no trace of what happened, a bit like the mail.exe program I wrote about 2 years ago which did the same thing for Windows passwords. If the control is signed, there's no way to stop it from running even with the highest security level selected in MSIE, and since it immediately erases all traces of its existence the code signing is worthless. Newer versions of the CryptoAPI which come with MSIE 4 allow the user to set a flag (CRYPT_USER_PROTECTED) which specifies that the key export function should be protected with no protection (the default), user notification, or password protection. However the way this is implemented makes it pretty much useless. Firstly, if the certificate request script used to generate the key doesn't set this flag, you end up with the default of "no protection" (and the majority of users will just use the default of "no protection" anyway). Although Microsoft claim that "reputable CA's won't forget to set this flag", a number of CA's tested (including Verisign) don't bother to set it (does this mean that Microsoft regard Verisign as a disreputable CA? :-). Because of this, they don't even provide the user with the option of selecting something other than "no security whatsoever". In addition at least one version of CryptoAPI would allow the "user notification" level of security to be bypassed by deleting the notification dialog resource from memory so that the call would quietly fail and the key would be exported anyway (this is fairly tricky to do and involves playing with the CPU's page protection mechanism, there are easier ways to get the key than this). Finally, the "password protection" level of security asks for the password a whopping 16 (yes, *sixteen*) times when exporting the key, even though it only needs to do this once. After about the fifth time the user will probably click on the "remember password" box, moving them back to zero security until they reboot the machine and clear the setting, since the key will be exported with no notification or password check once the box is clicked. To check which level of security you have, try exporting your key certificate. If there's no warning/password dialog, you have zero security for your key, and don't even need to use the encryption-breaking technique I describe elsewhere in this article. Any web page you browse could be stealing your key (through an embedded ActiveX control) without you ever being aware of it. Details on Breaking the Older Format ------------------------------------ The Microsoft key format is very susceptible to both a dictionary attack and to keystream recovery. It uses the PKCS #8 format for private keys, which provides a large amount of known plaintext at the start of the data, in combination with RC4 without any form of IV or other preprocessing (even though PKCS #8 recommends that PKCS #5 password-based encryption be used), which means you can recover the first 100-odd bytes of key stream with a simple XOR (the same mistake they made with their .PWL files, which was publicised 2 1/2 years earlier). Although the password is hashed with MD5 (allowing them to claim the use of a 128-bit key), the way the key is applied provides almost no security. This means two things: 1. It's very simple to write a program to perform a dictionary attack on the server key (it originally took me about half an hour using cryptlib, http://www.cs.auckland.ac.nz/~pgut001/cryptlib/, another half hour to rip the appropriate code out of cryptlib to create a standalone program, and a few minutes to retarget the program from Netscape to Microsoft). 2. The recovered key stream from the encrypted server key can be used to decrypt any other resource encrypted with the server password, *without knowing the password*. This is because there's enough known plaintext (ASN.1 objects, object identifiers, and public key components) at the start of the encrypted data to recover large quantities of key stream. This means that even if you use a million-bit encryption key, an attacker can still recover at least the first 100 bytes of anything you encrypt without needing to know your key (Frank Stevenson's glide.exe program uses this to recover passwords from Windows .PWL files in a fraction of a second). The problem here is caused by a combination of the PKCS #8 format (which is rather nonoptimal for protecting private keys) and the use of RC4 to encryt fixed, known plaintext. Since everything is constant, you don't even need to run the password-transformation process more than once - just store a dictionary of the resulting key stream for each password in a database, and you can break the encryption with a single lookup (this would be avoided by the use of PKCS #5 password-based encryption, which iterates the key setup and uses a salt to make a precomputed dictionary attack impossible. PKCS #5 states that its primary intended application is for protecting private keys, but Microsoft (and Netscape) chose not to use this and went with straight RC4 encryption instead). This is exactly the same problem which came up with Microsoft's .PWL file encryption in 1995, and yet in the 2 1/2 years since I exposed this problem they still haven't learnt from their previous mistakes. For the curious (and ASN.1-aware), here's what the data formats look like. First there's the outer encapsulation which Microsoft use to wrap up the encrypted key: MicrosoftKey ::= SEQUENCE { identifier OCTET STRING ('private-key'), encryptedPrivateKeyInfo EncryptedPrivateKeyInfo } Inside this is a PKCS #8 private key: EncryptedPrivateKeyInfo ::= SEQUENCE { encryptionAlgorithm EncryptionAlgorithmIdentifier, encryptedData EncryptedData } EncryptionAlgorithmIdentifier ::= AlgorithmIdentifier EncryptedData = OCTET STRING Now the EncryptionAlgorithmIdentifier is supposed to be something like pbeWithMD5AndDES, with an associated 64-bit salt and iteration count, but Microsoft (and Netscape) ignored this and used straight rc4 with no salt or iteration count. The EncryptedData decrypts to: PrivateKeyInfo ::= SEQUENCE { version Version privateKeyAlgorithm PrivateKeyAlgorithmIdentifier privateKey PrivateKey attributes [ 0 ] IMPLICIT Attributes OPTIONAL } Version ::= INTEGER PrivateKeyAlgorithmIdentifier ::= AlgorithmIdentifier PrivateKey ::= OCTET STRING Attributes ::= SET OF Attribute (and so on and so on, I haven't bothered going down any further). One thing worth noting is that Microsoft encode the AlgorithmIdentifier incorrectly by omitting the parameters, these should be encoded as a NULL value if there are no parameters. In this they differ from Netscape, indicating that both companies managed to independently come up with the same broken key storage format. Wow. For people picking apart the inner key, Microsoft also encode their ASN.1 INTEGERs incorrectly, so you need to be aware of this when reading out the data. Details on Breaking the PFX/PKCS #12 Format ------------------------------------------- The PFX/PKCS #12 format is vastly more complex (and braindamaged) than the older format. You can find an overview of some of the bletcherousness in this format at http://www.cs.auckland.ac.nz/~pgut001/pfx.html. After Microsoft originally designed the format (calling it PFX) and presented it to the world as a fait accompli, cleanup crews from other companies rushed in and fixed some of the worst problems and security flaws. However by this time Microsoft had already shipped implementations which were based on the earlier version with all its flaws and holes, and didn't want to change their code any more. A side-effect of this was that to be compatible, other vendors had to copy Microsofts bugs rather than produce an implementation in accordance with the standard. Newer versions of the standard have now been amended to define the implementation bugs as a part of the standard. Anyway, as a result of this it's possible to mount three independant types of attack on Microsoft's PFX/PKCS #12 keys: 1. Attack the RC2/40 encryption used in all versions, even the US-only one. 2. Attack the MAC used to protect the entire file. Since the same password is used for the MAC and the encrypted key, recovering the MAC password also recovers the password used to encrypt the private key. The cleanup crews added a MAC iteration count to make this attack harder, but Microsoft ignored it. 3. Attack the private key encryption key directly. Like the MAC's, this also has an interation count. Microsoft don't use it. Even if one of these flaws is fixed, an attacker can simply switch over and concentrate on a different flaw. I decided to see which one could be implemented the most efficiently. Obviously (1) was out (you need to perform 2^39 RC2 key schedules on average to find the key), which left (2) and (3). With the refinements I'm about to describe, it turns out that an attack on the private key encryption is significantly more efficient than an attack on the MAC. To understand how the attack works, you need to look at how PKCS #12 does its key processing. The original PFX spec included only some very vague thoughts on how to do this. In later PKCS #12 versions this evolved into a somewhat garbled offshoot of the PKCS #5 and TLS key processing methods. To decrypt data which is "protected" using the PKCS #12 key processing, you need to do the following: construct a 64-byte "diversifier" (which differs depending on whether you want to set up a key or an IV) and hash it; stretch the salt out to 64 bytes and hash it after the diversifier hash; stretch the password out to 64 bytes (using incorrect processing of the text string, this is one of Microsofts implementation bugs which has now become enshrined in the standard) and hash it after the salt hash; complete the hash and return the resulting value as either the key or the IV, depending on the diversifier setting; (it's actually rather more complex than that, this is a stripped-down version which is equivalent to what Microsoft use). This process is carried out twice, once for the key and once for the IV. The hashing is performed using SHA-1, and each of the two invocations of the process require 4 passes through the SHA-1 compression function, for a total of 8 passes through the function. Because the PKCS #12 spec conveniently requires that all data be stretched out to 64 bytes, which happens to be the data block size for SHA-1, there's no need for the input processing which is usually required for SHA-1 so we can strip this code out and feed the data directly into the compression function. Thus the compression function (along with the RC2 key setup) is the limiting factor for the speed of an attack. Obviously we want to reduce the effort required as much as possible. As it turns out, we can eliminate 6 of the 8 passes, cutting our workload by 75%. First, we observe that the the diversifier is a constant value, so instead of setting it up and hashing it, we precompute the hash and store the hash value. This eliminates the diversifier, and one pass through SHA-1. Next, we observe that the salt never changes for the file being attacked, so again instead of setting it up and hashing it, we precompute the hash and store the hash value. This eliminates the diversifier, and another pass through SHA-1. Finally, all that's left is the password. This requires two passes through the compression function, one for the password (again conveniently stretched to 64 bytes) and a second one to wrap up the hashing. In theory we'd need to repeat this process twice, once to generate the decryption key and a second time to generate the decryption IV which is used to encrypt the data in CBC mode. However the start of the decrypted plaintext is: SEQUENCE { SEQUENCE { OBJECT IDENTIFIER, ... and the SEQUENCE is encoded as 30 82 xx xx (where xx xx are the length bytes). This means the first 8 bytes will be 30 82 xx xx 30 82 xx xx, and will be followed by the object identifier. We can therefore skip the first 8 bytes and, using them as the IV, decrypt the second 8 bytes and check for the object identifier. This eliminates the second PKCS #12 key initialisation call which is normally required to generate the IV. As this analysis (and the program) shows, Microsoft managed to design a "security" format in which you can eliminate 75% of the encryption processing work while still allowing an attack on the encrypted data. To make it even easier for an attacker, they then dumbed the key down to only 40 bits, even in the US-only version of the software. In fact this doesn't really have any effect on security, even if they used 128-bit RC2 or triple DES or whatever, it would provide no extra security thanks to the broken key processing.

5 5

Re: (eternity) Eternity as a secure filesystem/backup medium
by John Kelsey 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- [ To: cypherpunks ## Date: 01/21/98 ## Subject: Re: (eternity) Eternity as a secure filesystem/backup medium ] >Subject: Re: (eternity) Eternity as a secure filesystem/backup medium >From: Adam Back <aba(a)dcs.ex.ac.uk> >Date: 1998/01/18 >1. communications crypto used by the author in submitting > the document is broken This is only a threat if the authorities have a good idea who submitted the data, and want to prove it. Otherwise, you end up with billions of encrypted documents, each encrypted with a moderately weak cipher. (Even assuming that the cipher turns out to have only 40 bits of strength, this is too expensive to do for more than a handful of documents.) >2. the eternity architecture contains encrypted documents to > frustrate attempts to locate documents, and to hide the > contents of documents from individual servers Again, this won't be too economical unless the eternity service is rarely used. >3. communications crypto used to request and deliver > documents is broken thus revealing the readers identity >So it is useful to design upgrade paths for ciphers into the >protocols where possible. Definitely--this is always a good idea, right? >Other approaches we could take are to use very conservative >cipher key sizes and protocols combining multiple ciphers in >ways which gives us the security of the best of the ciphers. >For example: > R = random, C = 5DES( R ) || blowfish-484( M xor R ) >Where 5DES is say E-D-E-D-E with 5 independent DES keys. >Constructs to combine in strong ways hash functions, macs, >symmetric and asymmetric ciphers would be useful. Is there >much research in this area? Yes. Massey and Maurer did a Journal of Cryptography paper titled ``The Importance of Being First,'' which says that in any chain of encryptions with different ciphers and independent keys, such as E_1(E_2(E_3(data))), the whole thing is provably as strong as the first cipher used on the data (E_3, in my example above). This is really obvious, when you reflect that an attacker can always try to break data encrypted with E_3 by superencrypting it with E_1 and E_2, and then mounting his attack on E_1(E_2(E_3(data))). Of course, if keys aren't independent among the three ciphers, then you don't get any guarantee of this kind. The other thing to note is that if you're just generating keystream sequences, as you would with RC4 or SEAL, then all ciphers are ``first.'' Rivest and Sherman also did some work on randomized encryption, of the kind you discuss, in the Crypto '82 proceedings. Your construction is very similar to one of theirs. Let M = message and R = a message-sized random number, then in E_1(R), E_2(R XOR M) both E_1 and E_2 must be broken to learn M. (Imagine this isn't the case, then either E_1 or E_2 wasn't broken. If you didn't break E_2 but broke E_1, then you only learn R, which is useless to you--it's random and uncorrelated with M. If you broke E_2 but not E_1, you would have a message encrypted with a one-time pad.) This generalizes nicely to E_1(R1), E_2(R2), ..., E_N(RN), E_{N+1}(R1 XOR R2 XOR ... XOR M). If those random numbers are really random, then if any one of those ciphers resists your attacks, the message can't be recovered. Now, you can also do this with things that approximate random functions, which they also discuss. Thus, you might use: f_1(),f_2(), ..., f_n() are N independently-keyed different cryptographic functions that approximate random functions. The funny thing is, if you instantiate this intelligently, you get a message encrypted by N different stream ciphers, perhaps with a random parameter per message thrown in during keying of those ciphers. Thus, suppose s_1(K1) = RC4(K1) s_2(K2) = 3DES-OFB(K2) s_3(K3) = SHA1-Counter-Mode(K3) s_4(K4) = Blowfish-OFB(K4) s_5(K5) = SAFER-SK128(K5). and that these keys are different per message and are all independent. Then, you get the result that M XOR s_1(K1) XOR S_2(k2) XOR ... XOR s_5(k5). leaves no way to recover M unless all five s_i() can be guessed. Note that, in practice, this isn't likely to be useful unless you've done the same kind of thing for symmetric key distribution, random number generation, etc. Otherwise, your attacker in 2050 will bypass the symmetric encryption entirely and factor your RSA modulus, or guess all the entropy sources used for your PRNG, or whatever else you can think of. The good news, though, is that active attacks (like chosen input attacks) and many side-channel attacks (e.g., timing attacks) turn out not to be possible if you are trying to mount them after the encryption has been carried out. >Adam - --John Kelsey, kelsey(a)counterpane.com / kelsey(a)plnet.net NEW PGP print = 5D91 6F57 2646 83F9 6D7F 9C87 886D 88AF -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBNMeCqSZv+/Ry/LrBAQGxpgQAloxNjdZMf6l/7U520ZSIVuk7lFZcu0+J 5tUyQgHtS4EAplC1OBnYc8B3pzCir6VCXinmNbClgalXhrRFfmV7vTQLZySaVv/+ 0T44TFkJ0Ldu4cTsA2ertL0jcCXiBp38mhVK2IFbPtN+04B+een8jrUYtzx/qIj5 ztBpBb4yil8= =wBTR -----END PGP SIGNATURE-----

4 3

Revenge on the Nerds -Maureen on a rampage
by Attila T. Hun 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- and everyone thought I have been blowing smoke over the few years over the need to dismember Micro$haft. More aye-sayers than naysayers have joined the fray, some even eloquently. even the opinion polls are against BadBillyG: bubba is more trusted! as is the government... Mickey$lop no longer generates terror in the hearts of everyone --just the OEMs who can not afford to even testify for fear of retaliation --and it is a real fear. keep your fire extinguisher handy. Maureen is really smoking! January 21, 1998 NYTimes OpEd Columnist LIBERTIES / By MAUREEN DOWD Revenge on the Nerds WASHINGTON -- I figured things were way out of perspective in the Other Washington when I heard that Bill Gates had put an inscription from "The Great Gatsby" around the domed ceiling of the library in his new $100 million pad: "He had come a long way to this blue lawn and his dream must have seemed so close that he could hardly fail to grasp it." Bill Gates was obviously unaware of the magnitude of the truth that he had unwittingly admitted. When he read about the blue lawn, he must have imagined computers with glowing blue screens stretching to infinity. And he must certainly have liked the proximity of the words "dream" and "grasp." With a judge who is likely soon to hold Microsoft in contempt for petulantly defying an order designed to give its rivals any chance, Mr. Gates's dream may at last have exceeded his grasp. The Justice Department never came down on Gatsby. This Washington has disabused that Washington of its arrogant presumption that what's good for Microsoft is good for America. This Washington has stripped that Washington of its image as warm, tender, flannel-and-soyburger pioneers of the new economy, and properly pegged Microsoft as an egomaniacal, dangerous giant that has cut off the air supply of competitors in a bid to control cyberspace. "The only thing the robber barons did that Bill Gates hasn't done is use dynamite against their competitors," Gary Reback, a Silicon Valley antitrust lawyer, told John Heilemann of The New Yorker. The disheveled college dropout who used to get adoring headlines like "A Regular Guy Who's a Legend: Bill Gates Puts a New Face on the American Dream" now looks like a spoiled rich brat. When they treated the Justice Department and the judge with the same contempt with which they treat competitors, the masters of the virtual universe got hit with a grim truth: People hate Microsoft even more than they hate the Government. Mr. Gates has gone from Horatio Alger similes to virus similes. Frederick Warren-Boulton, another antitrust expert, told The New Yorker: "Gates is like smallpox. You have to go in there and you have to nail it. If you leave it lying around, it will just come back." When asked who they thought had done more good for the future of America, Bill Gates or Bill Clinton, more Americans chose Mr. Clinton. (Even though portfolio-obsessed Americans would still rather have their children grow up to be more like Mr. Gates than Mr. Clinton, by 47 to 24 percent.) As Jacob Weisberg plaintively wrote in Slate, Microsoft's on-line magazine: "A few months ago, everyone I met seemed to think that working for Microsoft was a pretty cool thing to do. Now, strangers treat us like we work for Philip Morris." The Times's Timothy Egan explored the angst that has gripped the Redmond campus since Microsoft lost its sheen. Some fret that the fate of the entire Pacific Northwest is at stake. All the instant millionaires in thermal shirts, droopy drawers and sandals with wool socks are suddenly Wondering If It's All Worth It. They have staggered out of the Seattle fog long enough to listen to their inner browsers. This has been a rude shock to them because they honestly believed that our Washington was full of anti-business, careerist bureaucrats, and their Washington was full of imaginative idealists and entrepreneurs who buy and sell to the beat of a different drum. They didn't reckon smokestack laws could apply to high technology. As Mr. Gates's lawyer, William Neukom, told Steve Lohr of The Times, "We sincerely believe that we are a force for good in the economy." Actually, Microsoft has been a force for greed in the economy, more brilliant at marketing and purloining and crushing than it has been at innovating. The company saw the fight with the Justice Department as a defense of its way of life. And that way was hardball on software; anything it decided was a core threat to Microsoft was sucked into the operating system. These are Darwinian nerds. Besides, Microsoft couldn't even save the universe in "Independence Day." It took an Apple to do that. -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: latin1 Comment: No safety this side of the grave. Never was; never will be iQBVAwUBNMZSQ7R8UA6T6u61AQH2fgH+OQT3p1cE1lRxSzMvhyt9AvvH2N3jFUmO UZzpqRbrn9pB1VPxZLKG2lgBwOW4hPIlpFRWg8Fp+Uu6KoL6kKObuw== =n+/c -----END PGP SIGNATURE-----

18 23

RE: Announcement: RPK InvisiMail released on 12 Jan, 1998
by Jack Oswald 17 Dec '03

17 Dec '03

It seems that there is some confusion WRT to the origin of this product. The encryption technology was developed in New Zealand. The application itself was developed on the Isle of Man (British Isles). As a result, the US gov't has had nothing to do with the product and therefore none of the "concerns" represented in the previous message have any merit. What was meant by use of "honey" is that if you pick a fight with a government official, they will be happy to fight back. If you complement them on their farsighted visionary non-meddling approach you get a very different response. Our experience has been that we get a reasonable response from the NZ government that does not restrict the security that our products offer nor in the way that we choose to do business. Jack -----Original Message----- From: John Young [SMTP:jya@pipeline.com] Sent: Tuesday, January 27, 1998 4:02 PM To: cypherpunks(a)toad.com Cc: Jack Oswald Subject: RE: Announcement: RPK InvisiMail released on 12 Jan, 1998 On "using honey not vinegar" rationale of RPK InvisiMail for obtaining crypto export licenses: Applied Cryptography, Bruce Schneier, 2nd Edition, pp. 215-16 Algorithms for Export Algorithms for export out of the United States must be approved by the U.S. government (actually, by the NSA--see Section 25.1) It is widely believed that these export-approved algorithms can be broken by the NSA. Although no one has admitted this on the record, these are some of the things the NSA is rumored to privately suggest to companies wishing to export their cryptographic products: - Leak a key bit once in a while, embedded in the ciphertext. - "Dumb down" the effective key to something in the 30-bit range. For example, while the algorithm might accept a 100-bit key, most of those keys might be equivalent. - Use a fixed IV, or encrypt a fixed header at the beginning of each encrypted message. This facilitates a known-plaintext attack. - Generate a few random bytes, encrypt them with the key, and then put both the plaintext and the ciphertext of those random bytes at the beginning of the encrypted message. This also facilitates a known-plaintext attack. NSA gets a copy of the source code, but the algorithm's details remain secret from everyone else. Certainly no one advertises any of these deliberate weaknesses, but beware if you buy a U.S. encryption product that has been approved for export. ----- Bruce added the last "beware" phrase to the 2nd edition.

1 0

Re: Planetary rovers, SETI and other musings, was Re: update.356 (fwd)
by Jim Choate 17 Dec '03

17 Dec '03

Forwarded message: > Date: Wed, 28 Jan 1998 10:44:57 -0800 > From: Steve Schear <schear(a)lvdi.net> > Subject: Re: Planetary rovers, SETI and other musings, was Re: update.356 > (fwd) > >The state is determined *at the time of collapse*. Once the collapse occurs > >the synchronization is no longer present and subsequent events can indeed > >alter the polarization of one particle without altering the other. Simply > >bouncing that photon via refraction off a surface can alter the > >polarization. > > If that is the case, I still don't understand why and out-of-band signal is > required. If the sender collapses the wave function shortly before the > signal reaches the intended receiver its unlikely to have changed > polarization again. What do you mean 'shortly before', the collapse is instantaneous. There ain't no time to send anything. The channle can carry one bit of data, the collapse has occured (1) or it hasn't (0). It isn't like a modem, CD, or other comm channels where you have a bandwidth and can piggy back signals for synchronization by using parts of that bandwidth. ____________________________________________________________________ | | | The most powerful passion in life is not love or hate, | | but the desire to edit somebody elses words. | | | | Sign in Ed Barsis' office | | | | _____ The Armadillo Group | | ,::////;::-. Austin, Tx. USA | | /:'///// ``::>/|/ http://www.ssz.com/ | | .', |||| `/( e\ | | -====~~mm-'`-```-mm --'- Jim Choate | | ravage(a)ssz.com | | 512-451-7087 | |____________________________________________________________________|

1 0

Oregon no-knock leads to conflict [CNN]
by Jim Choate 17 Dec '03

17 Dec '03

Forwarded message: > OFFICER KILLED, 2 WOUNDED IN OREGON SHOOT-OUT > > Map of Oregon January 28, 1998 > Web posted at: 2:06 p.m. EST (1906 GMT) > > PORTLAND, Oregon (AP) -- One officer was killed and two were wounded > in Portland Tuesday as they forced their way through the door of a > home that neighbors say was stocked with high-powered weapons. > > Police with black body armor and shields surrounded the house and > wounded the lone suspect. He was taken out three hours later and > hospitalized with gunshot wounds to the chest and stomach. > > The suspect, identified as 37-year-old Steven Dons, was stripped by > officers and driven away naked and bleeding on the tailgate of an > armored SWAT van. > ____________________________________________________________________ | | | The most powerful passion in life is not love or hate, | | but the desire to edit somebody elses words. | | | | Sign in Ed Barsis' office | | | | _____ The Armadillo Group | | ,::////;::-. Austin, Tx. USA | | /:'///// ``::>/|/ http://www.ssz.com/ | | .', |||| `/( e\ | | -====~~mm-'`-```-mm --'- Jim Choate | | ravage(a)ssz.com | | 512-451-7087 | |____________________________________________________________________|

2 1

EPR, Bell, and FTL Bandwidth
by Eric Cordian 17 Dec '03

17 Dec '03

Steve Schear writes" > Why aren't the coding techniques commonly used in telecom and disk > data encoding adequate to both synchonize and convey data? Think of the classical case. I bake two fortune cookies, one with "FOO" written on the slip of paper inside, and the other reading "BAR." I then put them in a box and shake it for quite a while, until the final state has chaotic dependence upon initial conditions, and cannot be predicted. I then keep one fortune cookie, and mail the other one to Lucky Green in Tonga. Someday in the future, I open my cookie, and instantly know what Lucky will see when he opens his. In doing so, I have created a "instantaneous" correlation between two things separated by a vast distance, which were in an identical state of ambiguity prior to one of them being examined. I am sure we will agree that there was no genuine faster-then-light communication of information in this case. In quantum mechanics, pairs of observables may have the property that both of them may not be known precisely for a physical system. The Heisenberg Uncertainty principle states this for position and momentum. Similar relationships exist for energy and time, polarization or angular momentum measured with respect to different axes, and various other things. In addition, measuring a physical system for one such variable always changes its wavefunction into one for which the value of that variable is precisely specified, and the value of the other "non-commuting" variable is not. You can see this easily with three polarizing filters. If you shine a light through two of them at right angles to each other, it will be completely blocked. But it you insert third filter at a 45 degree angle, some light will get through. This is because light whose polarization is known to be vertical or horizontal is in a mixed state with respect to its polarization rotated 45 degrees. It is therefore tempting to think that perhaps the miracle of quantum mechanics could be employed in our fortune cookie experiment for the transmission of information. I generate many pairs of cookies, with random but identical polarization, keeping one of each pair for myself, and sending the other to Lucky. I then encode a stream of bits by measuring the polarization of 100 cookies, vertically if I wish to transmit a "0", and at a 45 degree angle if I choose to transmit a "1". I then know Lucky's corresponding cookie to be in an exact state with respect to one of these observables, and in a mixed state with respect to the other, and if Lucky measures the vertical polarization of his groups of cookies, there should be a correlation between his results and mine which can only be explained by non-local communication of my choice, on the fly, of which way I measured the polarization, to his apparatus. Now here we have good news and bad news. The good news is that when we do such an experiment, precisely enough to know for sure that there is a spacelike separation between the two measurement events, we do indeed see the correlation predicted by quantum mechanics. The bad news is that either end of the experiment, by itself, cannot see this correlation without knowing what results were obtained by the person at the other end. The correlation is between both ends. There is no experiment that can be done by either end alone which will turn out differently depending upon what the guy at the opposite end is doing. Thus, while such experiments involve non-local communication between two locations separated by a spacelike distance, such communication is obvious only to someone able to see what is going on in both places at once, but not to either isolated experimenter. Hence, the non-local collapse of quantum mechanical wavefunctions cannot be employed for the transmission of information. A similar argument applies to quantum teleporation, in which the value of some measurable variable is transferred from a dynamical system to one of two particles in correlated but unknown quantum states, causing the particle's twin to take on an identical value. Again, a person able to view both systems can see that non-local communication has taken place, but there is nothing either end can do by itself to learn what has transpired at the other end. This is because the correlation which proves non-local communication is present only in combined data from both ends of the experiment, but not in data from either end alone. -- Eric Michael Cordian 0+ O:.T:.O:. Mathematical Munitions Division "Do What Thou Wilt Shall Be The Whole Of The Law"

1 0