- cypherpunks-legacy - lists.cpunks.org

Re: NSA on GAK
by patrick＠Verity.COM 17 Dec '03

17 Dec '03

I've reformatted this to make it easier to read...If you've already read it, then just delete it:) ~~~~~~~ Included reformatted stuff starts here --\/ ~~~~~~~~~~~~~~~~~~~~~~ URL: http://csrc.ncsl.nist.gov/secnews/ees_q-a.txt ---------- Note: The following answers were provided by NSA to the Senate Subcommittee on Technology and the Law in response to their follow- up questions to the May 3, 1994 hearings. --------------------------- Senate Subcommittee on Technology and the Law Hearing on the Administration's Key Escrow Encryption Standard Written Questions for Vice Admiral McConnell, NSA *Questions for Senator Pressler: Q: Admiral, as you are aware, critics of the Administration's proposal argue that as a practical matter, no criminal, foreign spy, or terrorist of any sophisticated would be foolish enough to use an encryption device designed by the NSA and approved by the FBI. How do you respond? Why do[n't you] think the people whose telecommunications the NSA and the FBI want most to decode will be the very people most unlikely to use this technology? Answer: From what we know today, the overriding requirement that spies, terrorist, and criminals have is for readily available and easy to use equipment that interoperates. Key escrow encryption is not meant to be a tool to catch criminals. It will make excellent encryption available to legitimate businesses and private citizens without allowing criminals to use the telecommunications system to plan and commit crimes with impunity. We believe it would be irresponsible for government to make excellent encryption broadly available knowing that its use by criminals would make it impossible for law enforcement agencies to conduct lawful wiretaps against them. The Department of Justice credits information gleaned through wiretaps as leading to more than 20,000 felony convictions since the early 1980s. This would not have been possible if the criminals had been using encryption systems the FBI could not break. Without government action, however, this fortunate situation will change. At present most people, and most criminals, don't use encryption. However, there is an increasing public awareness of the value of encryption for protecting private personal and business communications. Increasing demand for encryption by the public will likely lead to the widespread use of some form of standardized encryption on the public telecommunications network. This development would have great benefits for the country. Legitimate businesses an private individuals could use the telecommunications system secure in the knowledge that their private information such as business records and credit card numbers could not be intercepted by third parties. But there is a down side. Criminals, terrorists, and others could also use the system to plan crimes, launder money, and the like, completely secure in the knowledge that law enforcement agencies could not listen to those communications. Just as legitimate businesses operate much more efficiently and effectively using the telecommunications system than they could without it, so will criminal enterprises be able to operate more efficiently and effectively if they no longer have to avoid using the telecommunications system. The United States is faced with a choice. We can sit back and watch as the emerging national information infrastructure becomes a valuable tool for criminals and terrorists to use to plan and carry out their activities with complete security, or we can take steps to maintain the current ability of government to conduct lawful wiretaps so that prudent criminals will have to find other less efficient ways to operate and foolish ones may be caught. Key escrow encryption is the later option. Q: Would widespread use of the Skipjack algorithm harm U.S. exports? Do you think it is unlikely foreign businesses will purchase American encryption technology if the U.S. Government holds a set of the decoding keys? Answer: I do not believe that widespread use of key escrow encryption in the United States will harm U.S. exports. If it has any effect at all, it could increase exports somewhat. Key escrow encryption products provide another option for foreign purchasers that they have not had in the past; to the extent that foreigners doe purchase key escrow encryption products, it will mean an increase in exports. Meanwhile, U.S. exporters are free to continue to sell the products they currently sell in foreign markets and to seek license approvals for new products. It is difficult to predict the foreign market for U.S. key escrow encryption technology. Businesses that fear U.S. Government interception of their communications presumably would avoid products for which the U.S. Government hold keys. However, there are a number of reasons why foreign businesses might purchase them. One major reason would be to communicate securely with U.S. businesses that use them. In addition, the superior level of security provided by key escrow products (against all but lawful U.S. Government access) may make them attractive to foreign business that do not view U.S Government access as a major concern. While some prospective users abroad may steer clear of key escrow products because the United States will retain access, there may be many who believe they are unlikely to be targeted by U.S. intelligence in any case or for whom the superior security offered by key escrow encryption products against threats of greater concern may make key escrow products an attractive option. For example, a distributor of pay-TV programming may depend on encryption to ensure that only those viewers who pay for the service can decrypt the TV signal. Such a distributor probably would not be concerned about the threat of access by the United States Government, and might favor suitable key escrow encryption products over competing products that use weaker encryption algorithms. Q: You were present when the previous panelist, Stephen Walker, described how present U.S. laws prohibit his company from exporting encryption products. As I understand it, Senator Murray's bill S.1846, attempts to relax these export controls somewhat. Please give us your views on this legislation. Answer: I support the Administration's position, as announced by the White House on February 4, that current export controls must remain in place and that regulatory changes should be implemented to speed exports and reduce the licensing burden on exporters. The bill you reference appears to be inconsistent with the Administration position. I would be happy to provide you further information on the Administration's reasons for maintaining the current export controls in an appropriate setting. *Questions from Senator Murray: Q: In my office in the Hart building this February, I downloaded from the Internet an Austrian program that uses DES encryption. This was on a laptop computer, using a modem over a phone line. The Software Publishers' Association says there are at least 120 DES or comparable programs world wide. However, U.S. export control laws prohibit American exporters from selling comparable DES programs abroad. With at least 20 million people hooked up to the Internet, how do U.S. export controls actually prevent criminals, terrorists, or whoever from obtaining DES encryption software? Answer: Serious users of encryption do not entrust their security to software distributed via networks o bulletin boards. There is simply too much risk that viruses, Trojan Horses, programming errors, and other security flaws may exist in such software which could not be detected by the user. Serious users of encryption, those who depend on encryption to protect valuable data and cannot afford to take such chances, instead turn to other sources in which they can have greater confidence. Such serious users include not only entitles which may threaten U.S. national security interests, but also businesses and other major consumers of encryption products. Encryption software distribution via Internet, bulletin board, or modem does not undermine the effectiveness of encryption export controls. [Primary written questions for Admiral McConnell] 1. The Defense Authorization Bill for Fiscal Year 1994 has authorized $800,000 to be spent by the National Research Council of the National Academy of Sciences to conduct a study of federal encryption policy. Can we wait to implement the key escrow encryption program until we have the benefit of the NRC's study? Do you think this study is necessary? Should this study be expedited? Answer: We do not believe that we can wait until after the NRC study is completed in 1996 to begin implementation of the key escrow initiative. The information technology industry is dynamic and fast-moving, and to wait another two years or more would, we believe, jeopardize the success of the initiative. Industry demand for encryption products is growing, and the technology is available now to meet that demand with encryption products that provide an outstanding level of security to the user conduct lawful wiretaps. To wait for the completion of the NRC study to other encryption products which would defeat lawful wiretaps. We believe that such a delay would not be in the best interest of the American people. Neither do we believe that the study should be expedited. For our part, we will carefully consider the conclusions of the NRC study. We expect that it will give very careful consideration to the issues, and we would not want the pressure of an unnecessarily short deadline to limit the study group's ability to produce the best report possible. 2. The Administration has said that it is continuing to restrict export of the most sophisticated encryption devices, in part, "because of the concerns of our allies who fear that strong encryption technology would inhibit their law enforcement capabilities." Do we really need to help our allies by prohibiting the export of strong American encryption products, since those same countries can simply control the encryption bought within their borders? Answer: Exports of encryption products are subject to review primarily to protect U.S. national interests, including national security, law enforcement, foreign policy, and other important interests. The law enforcement concerns of our allies are a consideration, especially as the ability of our allies to combat terrorism, drug trafficking, and other international law enforcement problems can have direct benefits to the United States. However, foreign law enforcement concerns do not drive our export control policy. We would continue to review encryption exports to protect U.S. national interests even if foreign law enforcement concerns disappeared. 3. Do you know whether foreign governments would be interested in importing key escrow encryption products to which they hold the decoding keys? Answer: Several foreign governments have expressed interest in key escrow encryption technology due to their own law enforcement concerns. There have been some preliminary discussions, but issues such as who would hold the escrowed keys and the circumstances of government access to escrowed keys must be fully vetted. 4. The Government wants the key escrow encryption standard to become the de facto industry standard in the United States. Would the Government abandon the Clipper Chip program if it is shown to be unsuccessful beyond government use? Answer: We do not expect the program to be unsuccessful beyond government. We have developed a sound security product that we expect will find many uses in government information systems and further believe that government use will bring with it a commercial market, particularly in the defense sector. We have developed a sound security product that we expect will find many uses in government information systems regardless of its success in commercial markets. 5. Openly available devices, such as Intel-compatible microprocessors, have seen dramatic gains, but only because everyone was free to try to build a better version. Given the restrictions on who can build devices with the classified skipjack algorithm, how will key escrow chips keep up with advances in semiconductor speed, power, capacity and integration? Answer: Despite the requirements that a firm must meet to produce key escrow encryption chips, we expect that there will be a number of manufacturers competing against each other to produce the best product, and that such competition will drive them to keep up with the latest technological advances. It is worth noting that only a few companies can produce the sophisticated microprocessors you reference, yet the competition in that market has driven them to achieve remarkable advances in that technology. NSA's STU-III secure telephone program provides an example of a cryptographic product line that keeps pace with technology. The presence of a classified algorithm does not preclude keeping pace with technology. Through NSA's use of a competitive, multi-vendor approach, STU-III secure telephone products have continued to evolve in response to user requirements and technological advances despite their use of a classified encryption algorithm and the consequent need for security restrictions on the manufacturers. 6. How well does the Skipjack algorithm work on telecommunications operating at very high speeds. Is NSA working on another algorithm, called BATON, that could be used in high speeds with a key escrow system? Will Capstone be compatible with BATON? Answer: Using currently available microelectronics technology the SKIPJACK algorithm could not be used for encryption at very high speeds. BATON is the name of an algorithm developed by NSA that could be used at higher rates of speed. We have no plans to develop key escrow encryption devices using BATON, however. Instead, we are considering another algorithm for use at high speeds with a key escrow system. A high-speed key escrow device based on an algorithm other than SKIPJACK would not be "compatible with Capstone" in the sense that traffic encrypted by such a device could not be decrypted by Capstone, and vice versa. However, since such a device would be used for much higher-speed applications than those for which Capstone was designed, there would be no need for it to be compatible with Capstone in that sense. 7. Can Capstone be used to encrypt video programming? If so, have cable companies been approached by any government agency to use Capstone to scramble or encrypt cable program? Answer: Capstone could be used to encrypt any digital signal, including video programming, operating at up to about 10 million bits per second. It could be used for encrypting individual video channels but not for bulk encryption of many channels multiplexed together in a single link. NSA is not aware of any government agency approaching cable companies to urge the use of Capstone. Two manufacturers have asked us about the suitability of key escrow devices for this purpose, however. 8. Encryption software is available that can be used with Clipper to encrypt a message before after it has been encrypted with Clipper. This "double encrypting" risks bypassing the key escrow feature. If a sender first encrypts the message with software using DES, and then transmits the message "double encrypted" with Clipper, can tell you from looking at the cipher, or encrypted text, that the underlying message was encrypted? Answer: The only way to tell that a message has been "double encrypted" in this way would be to decrypt the "outer layer" of encryption, i.e. that done with Clipper. Only then would one be able to tell that the message had first been encrypted with something else. ---------- _______________________________________________________________________ / These opinions are mine, and not Verity's (except by coincidence;). \ | (\ | | Patrick J. Horgan Verity Inc. \\ Have | | patrick(a)verity.com 1550 Plymouth Street \\ _ Sword | | Phone : (415)960-7600 Mountain View \\/ Will | | FAX : (415)960-7750 California 94303 _/\\ Travel | \___________________________________________________________\)__________/

2 1

Net Police, Red and in Bed
by John Young 17 Dec '03

17 Dec '03

WSJ, 15 February 1996: China Tells Internet Users To Register With Police Beijing (AP) - China ordered all users of the Internet and other international computer networks to register with the police, as part of an effort to tighten control over information. The order came in a circular issued by the Ministry of Public Security, according to the state-run Xinhua News Agency. Xinhua didn't give a date by which current users must register but said new users and those switching or terminating services must inform police within 30 days. It was unclear how foreigners would be affected. The rules haven't been published in detail, but previous Xinhua reports warned network users not to harm national security, reveal state secrets or disseminate pornography. China embarked on a broad crackdown on Internet users and other sources of information potentially harmful to government interests in December. The Ministry of Post Telecommunications was made the sole provider of channels connecting Chinese computer users with international networks. ----- Financial Times, 15 February, 1996 Cyberlaws [Editorial] Communication *sans frontieres*. To the Internet's fans that is the essence of its appeal. But to anyone putting information on the Internet's World Wide Web, its global nature is the cause of a growing headache: how to uphold intellectual property rights to the rivers of information pouring over its wires. Online computer systems such as the Net are among the fastest growing ways to distribute information -- music and pictures as well as words and numbers. But existing copyright laws deal inadequately with digital transmission. Regulation is complicated by the way that information downloaded in one country can have originated almost anywhere in the world. The $35bn-a-year music industry now believes that digital copyright abuse is a big future threat to its revenues. The century-old Berne convention on copyright and the General Agreement on Tariffs and Trade represent a degree of international agreement on the treatment of such issues. However, many countries are not signatories, while standards of intellectual property protection vary widely among those which have signed. Moreover, there are technological problems in enforcing agreements even where they exist. At present, it is often difficult to identify both those who have accessed information, and those who have entered it on the Net. Given that problem, some groups want companies providing Internet access to be responsible for upholding rules, rather than users or publishers. But this is highly unattractive: service providers will be unaware of much on the Net. The currently imperfect state of protection is one reason why much cyberinformation is junk, of value to almost nobody, deposited partly to stir up interest in paidfor services beyond the Net. However, new ways to restrict access to parts of the Net, and to charge for subscriptions to that information, may address that shortcoming. Companies are also working on "electronic tags" which will show whether information is passed to unauthorised users. If such technological developments bear fruit, the whole game may change. The mainstay of the Internet may no longer be information already published in another medium. Instead, publishers could put material of real value on the Net, knowing they would be paid. Other media may be squeezed as the Internet assumes some of their role. In this respect, copyright problems are a symptom of the Internet's immaturity, rather than a sign that electronic sophistication has made regulation impossible. The Net itself is a creation of technology, not policy, and the solutions to this problem are more likely to be technological than legal. But solutions must be found if the Net is to realise its enormous commercial potential. ----- FT has a front page article on what China may do if the US imposes sanctions for copyright violations. It includes overtures by the Chinese to Britain to reap the benefits of shutting down US businesses in retaliation. Noting the well-oiled handover of Hong Kong to China as an example of the mutual benefits of imperialist most- favored status, and sharing tips and tricks of crackdown on civil disorder.

1 0

Apple, AOCE, and key pair security
by greg＠ideath.goldenbear.com 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- A few months ago, I posted an excerpt from a MacWeek article re AOCE (Apple Open Collaboration Environment), a collection of services to be integrated into the Mac OS to facilitate groupware apps. The MacWeek article said that users would receive their public keys (to be used for digital signatures on documents) from RSADSI, instead of generating them themselves. Scott Collins wrote to disagree, saying that the AOCE software he'd seen didn't work that way. I E-mailed the author of the original article, who stood by what he wrote, saying that "very good sources" said that the keys would be provided to users by outside, allegedly trustworthy, sources. According to the 11/93 Macworld, users will not, in most cases, generate their own key pairs: "When you receive a signed digital document, how do you know that the signature is legitimate and that it isn't from a pretender? In many ways, your digital signature is similar to a credit card; it is issued by a known authority, it has an expiration date, and you can verify its validity. To get your own digital signature from RSA, you take a form to a notary public, who verifies your identity, notarizes the information on the form, and then mails the form to RSA. Based on the notary public's authority to say you are who you claim to be, you eventually receive a disk in the mail with your personal electronic signature. Your electronic signature has a two-year expiration date, and includes some verification information. If someone wants to make sure your signature is valid, he or she contacts the issuing authority listed in the certificate. There will be issuing authorities other than RSA. For example, Apple Computer's security department plans to issue signatures to all Apple employees with employee badges." "AOCE, Apple's plan for groupware", Macworld, 11/93, p. 167. -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLMtl4X3YhjZY3fMNAQHyFwQAgz42oEoWb3okT1pZt/buyIhpPls8hMFT WzvhVYSxQnaYzRz5jHRl0YdLUivW71dgHWTKffasZhMAd05Bn3t6m3LTz8zPc4sx LfgN4yvFTl/foepVegzMZPPoDnhb5Sp46cAC0O3+fgaCrmasZaoHIWNBRKsz0wnv hh07sCIsswM= =6i+9 -----END PGP SIGNATURE----- -- Greg Broiles greg(a)goldenbear.com Baked, not fried.

1 0

Re: taxonomies of 'real money' and e-cash
by tcmay＠got.net 17 Dec '03

17 Dec '03

At 11:33 PM 9/18/95, P.J. Ponder wrote: ... > Maybe I'm missing the larger point, but isn't it accurate that in the >digital world, one protocol or procedure may take the place of perhaps >several of the 'real-world' procedures or protocols? An effective >mechanism of signing with non-repudiation that was recognized as binding >on the signer would permit 'checks', 'promissory notes', 'IOUs', and I wasn't saying they are all on the same footing, or are all separate and compartmentalizable things. Clearly some of them are just slightly different "flavors" of other things. I listed a bunch of them not as a taxonomy or ontology, but as an illustration that there are many kinds of financial dealings, many kinds of roles played. That the real world has so many flavors of financial things could of course be due to inertia and ignorance, partly. But there are also different functionalities, and costs. Fitting the different needs, the different roles of the players. I won't go on and on, as my last post on this I think hit the main points, but consider how many flavors we have just of "checks": the "ordinary" checks we write, counter checks, dual-endorser checks, traveller's checks, and so on. (If you are arguing that only "digital cash" is a real issue, and all other constructs are "small matters of programming," then we disagree profoundly.) >'warrants'. Some of the other species listed in your post aren't really >money, anyway. They are things you can buy with money, like stock >certificates or Maseratis. One could conceivably buy convertible >debentures with e-cash, the same as one could buy them with 'real money', >but it doesn't follow that there should be some one-to-one mapping of real >money objects and classes onto electronic analogues. Once again, i've >probably missed the forest, but a couple of the trees distracted me. I don't get your point at all. I didn't claim they were all "money," whatver we may mean by _that_ loaded term, but that they are "things" with important features. And even your example of a thing like a "stock certificate" is not quite as simple as a thing like a "Maserati." My belief is counter to yours: I believe many or even most of the financial things and instruments we deal with today will be mapped into "digital economy" versions, albeit with new wrinkles and perhaps new names. (I could cite many examples of protocols that cannot be automated for use by agents if the only carry-over is "digital cash." Voting of shares, endorsements on instruments, various kinds of guarantees, reputations, and so on.) --Tim May ---------:---------:---------:---------:---------:---------:---------:---- Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)got.net 408-728-0152 | anonymous networks, digital pseudonyms, zero Corralitos, CA | knowledge, reputations, information markets, Higher Power: 2^756839 | black markets, collapse of governments. "National borders are just speed bumps on the information superhighway."

1 0

Re: PGP for Linux 1.2.8
by David K. Merriman 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- At 04:39 AM 9/19/95 +0000, you "wrote": >Attachment Converted: D:\DOWNLOAD\MIME\RePGPfor.8 > I, for one, don't need Mystery MIME Attachments cluttering up my drive. If it's worth saying, then *say* it. Thank you. Dave Merriman -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMF49HsVrTvyYOzAZAQE9aQP+JYa+eglyQCWWHxt5AexhapWyURziXX31 UN97I287MtJw62us1Usr3rpgSbm/7C1LaIZP4ucY0rEXXfvSRzbOPnaa0nPb18e/ Axf/5RzjsrgjvHiXsXm8e2/7z6fe+dByA6qSKLaE77yOkKNEoEPbUeJrjzX7PKSR qLFotWpaYvs= =VGzR -----END PGP SIGNATURE----- This is a test (3 UUE lines) of the unconstitutional ITAR - 1/713th of the PGP executable. See below for getting YOUR chunk! ------------------ PGP.ZIP Part [015/713] ------------------- M=$<(&L`#*IPP",(G6(,,S,`P](<2RWU96XCW86/JBYV8A\D8@X'HB_9H#&\X MX'PCUB.,13B"X8`R?^J-:UB.M_`U\>[#)BS&5$0C,Y#^1CS>1`\T1QTXX6!3 M8H,),S$8G>&.WP(8IRA`-M['+`Q%&_C"">5-F%LX@<_Q$;*P'',Q$Z/AA[8M ------------------------------------------------------------- for next chunk to export --> http://dcs.ex.ac.uk/~aba/export/ <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><> My web page: http://www.geopages.com/CapitolHill/1148

2 1

Automatic E-Mail
by Rick.Sciorra＠hudson.lm.com 17 Dec '03

17 Dec '03

Does anyone know of an E-Mail package that will automatically connect to the Internet and retreive mail at specific intervals?

1 0

Re: Encryption and Backups
by Alan Olsen 17 Dec '03

17 Dec '03

At 08:33 PM 2/4/96 -0800, John Pettitt wrote: > >On Sun, 4 Feb 1996, Alan Olsen wrote: > >> Something that I have not seen addressed is the need for strong encryption >> in backup software. >CP Backup (part of PC Tools for Central Point aka Symantec) has DES. As to >how good the implementation is: I have no idea. I have a copy, but I have not yet verified the key sizes. It is on my list of projects. (My current project is for determining if an app is accessing your PGP files under Win95. I may be stuck for a bit though... Looks like I might need the DDK to compile it.) Alan Olsen -- alano(a)teleport.com -- Contract Web Design & Instruction `finger -l alano(a)teleport.com` for PGP 2.6.2 key http://www.teleport.com/~alano/ Is the operating system half NT or half full?

1 0

Re: Automatic E-Mail
by Bill Stewart 17 Dec '03

17 Dec '03

[This isn't quite on topic, though you could stretch it to deal with remailers. Can the winsock remailer do this?] At 10:50 PM 9/18/95 GMT, Rick.Sciorra(a)hudson.lm.com wrote: >Does anyone know of an E-Mail package that will automatically connect >to the Internet and retreive mail at specific intervals? Sigh. Folks have gotten too used to PC-market email systems, which are generally braindamaged by having been around operating systems where you can't just run a listner program that waits for somebody to call you when they want to send you mail, which of course fits in very well with letting ISPs avoid having to make outgoing phone calls instead of just receiving, plus the market reluctance of many of them to forward mail for you to competing mail services and the client/server-orientation that makes peer-to-peer services harder to implement. Unix systems did this job just fine on PDP11/70s, which could support a dozen or two users on a machine with about the horsepower of a PC/AT. And Henry Spencer could do that on a /44 :-) Just about anything that does UUCP can be set to do that, if you've got an ISP who doesn't charge you lots extra for using UUCP. Most high-end terminal emulation packages have scripting languages that let you call up and do stuff, which you should be able to call from timer programs; you can probably even find a free Kermit version that will do it. I use Eudora Light with Trumpet to call Netcom's newbie-friendly Netcruiser service; when I hit the menu item for send or retrieve mail, it pops through all the layers and dials, and hangs up when it's done. If Commercial Eudora can't already do that automagically, it should - ask Qualcomm to add it to the next version... Alternatively, Winsock programming isn't really all that hard, and POP3 is a pretty simple protocol, so you could roll your own. #--- # Bill Stewart, Freelance Information Architect, stewarts(a)ix.netcom.com # Phone +1-510-247-0664 Pager/Voicemail 1-408-787-1281 #---

1 0

Re: MIME attachments and ranting.
by Bill Stewart 17 Dec '03

17 Dec '03

>> >Attachment Converted: D:\DOWNLOAD\MIME\RePGPfor.8 >> I, for one, don't need Mystery MIME Attachments cluttering up my drive. If >> it's worth saying, then *say* it. >I really don't know why any mailers call a monopart MIME message an >"attachment". Mail readers come in three basic flavors of unMIMEificationness: 1) Ignorance+bliss - the mailer doesn't know or care about MIME headers, and you can ignore them when you read them, and may be able to configure the reader not to bother you with most of them (e.g. BSD Mail.) 3) Intelligence - the mailer does something genuinely useful to help you read the attachment, like letting you pop up some appropriate reading tool. 2) Naive friendliness - the Sirius Cybernetics approach. "Your mail file has been tastefully shredded into little pieces and sprinkled around your disk drive. Thank you for making a humble mail system so _very_ happy." Free Eudora versions offer you several choices of tastefulness and shredditude, partly intended to provide artistic functionality and partly to encourage you to buy the commercial version which gives you a more flexible user interface for extensions like MIME. So buy it, or cope with it, or tell Eudora to use your RAMdisk for its attachments where they'll soon go away and not bother you. There's also another approach, typified by a vendor whose name will be omitted but they'd know who they were if they had a <perjorative deleted> clue.... 0) Downright hostile - Not only does it _pretend_ to be Intelligent, while only really doing the right thing with its own proprietary data formats*, though generally doing something reasonable with uuencoded documents with names that it understands, but it chokes and dies on messages that have even moderately large amounts of simple, basic, non-attachmentized _text_, and if you _do_ try to package text up to send to some poor sucker who's stuck with one of these <perjorative deleted> systems, it hands it to a brain-damaged user-friendly mouse-editor that _also_ chokes on more than 64KB of text.... [* where "the right thing" allows it to mindlessly run arbitrary code handed to it as macros in the proprietary data formats that the company encourages its users to use instead of real text....] #--- # Bill Stewart, Freelance Information Architect, stewarts(a)ix.netcom.com # Phone +1-510-247-0664 Pager/Voicemail 1-408-787-1281 #---

1 0

Re: NYT on Netscape Crack
by Bill Stewart 17 Dec '03

17 Dec '03

> The New York Times, September 19, 1995, pp. A1, D21. > ...... > "The good news and the bad news of the Internet is that > when you put something up there, many more people can test > it," said Mike Homer, the vice president of marketing at > Netscape. "You also give yourself the opportunity of having > people point things out which you can fix quickly." That's a good, and realistic, attitude. > Netscape officials said today that they would strengthen > the system, by making it significantly harder to determine > the random number at the heart of their coding system. They > said they would no longer disclose what data would be used > to generate the random numbers. I do hope this is just John Markoff's simplification of what Netscape's folks said and not an endorsement of security-by-obscurity. I realize that some data does need to be kept around on disk or in the program, since obtaining a lot of random bits at the beginning of every transaction either requires annoying user interactions or takes too long to get decent quality, and certainly this data ought to be kept private by the algorithms involved. One concern I've had about the popular "crunch some bits repeatedly through MD5" approach to random number generation is that knowing one sample from the stream (e.g. by doing a transaction with the victim) gives you the rest of the stream. There's a way to improve that. let X(0) be some number you keep around from a previous session, modified by whatever hardware randomness is available, and seeded by user input the first time. let X(i) = MD5(X(i-1)) let Y(i) = hash(X(i)), where hash is something like MD5(key,X(i)) use Y(i) as the output random number. This eliminates the ability to determine X(i) or Y(i+1) as a function of Y(i), since the search space of X(i) is presumably too large to reverse (unlike the number of bits you can cheaply get in one session). Keeping some of the bits of Y(i) around to use in addition to the other key for the hash, or to key the MD5(X(i-1)) with, may be useful as well. #--- # Bill Stewart, Freelance Information Architect, stewarts(a)ix.netcom.com # Phone +1-510-247-0664 Pager/Voicemail 1-408-787-1281 #---

1 0