Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…
As a courtesy to all of you whose mailers break at 32K or 64K, or whose mailboxes are already overflowing with RISKS issues, we are breaking precedent and not distributing the end-volume issue (RISKS-17.97) as a regular issue. It will remain available on the ftp site as risks-17.00 in the main directory, and will eventually appear in the new subdirectory 17 as both risks-17.00 and risks-17.97 — along with the rest of volume 17.
From: simons@peti.rhein.de (Cryptography Today) Newsgroups: sci.crypt,alt.security.pgp,talk.politics.crypto Subject: Breakthrough in cryptographics: ROT n+1 new algorithm discovered Followup-To: sci.crypt Organization: Institute of slowly and painfully working out the surprisingly obvious Xref: csl.sri.com sci.crypt:40328 alt.security.pgp:16271 talk.politics.crypto:10509 Unbreakable encryption algorithm discovered: ###### ####### ####### # # # # # # # # # ## # # # # # ## # # # # ###### # # # # # # ##### # # # # # # # # # # # # # # # # # ## # # # # ####### # # # ##### Another milestone has been added to the exciting history of research in cryptography. For several decades, the one-time pad had the reputation of being the most secure algorithm in existence. Not anymore. In the sleepy city of Bonn, Germany, the new ROT n+1 algorithm was invented by Peter Simons, a 22 year old student of Computer Science. ``I had the idea for the algorithm in 1993, when I was reading Douglas Adams' famous book "Hitchhiker's Guide to the Galaxy". In one chapter Adams was talking about bistromatics, a newly discovered branch of mathematics. He furthermore wrote, that the phenomenon of numbers behaving differently in a restaurant was well known to the common people, just, nobody took the time to really research the behavior. ``Then the idea of the n+1 phenomenon struck me. It happens every day. You have carefully planned your trip to the airport to reach your plane in time. You absolutely have to be there at 7:00 AM, not a minute later. Though you can be sure that due to mystical events, you'll reach the airport exactly at 7:01 AM. Or take the case of ordering a pizza. You have exactly $20 in your wallet and you order a pizza and drinks for just that amount. And when the delivery service arrives, you notice the $1 fee for orders after 4PM. ``I thought about using this law of nature for cryptographical purposes and ROT n+1 was almost invented. I was still missing the tools to device this effect, though. It took me three years of research to come up with a method to control the n+1 effect: Reverse Temporal Engineering.'' Unfortunately the details of Reverse Temporal Engineering are patented by Peter Simons and must not be described in detail here. To summarize it: You make up a random number. Then you take the ASCII-representation of your plaintext and add the number to each byte. If the result lies beyond the 'z' character, you'll simply start over with an 'a' again. Just like it has been done by Caesar a two-thousand years ago. Formally, the algorithm is described as follows (readers who are not mathematically oriented might want to skip this paragraph): f() is the function which yields the numerical-representation of a character. f'() on the other hand, yields the character represented by the number, it receives as parameter: (1) f'(f(x)) = x Given the magical number n and the pool of available characters Z, the encryption works as follows: (2) f'((f(x)+n) mod |Z|) Decryption is done just the other way round: (3) f'((f(x)-n) mod |Z|) If both, the sender and the recipient, use the same character set and the same key n, the system works. So far so good. Of course anybody can attack use brute force to attack the encrypted message, simply by trying all possible 'n's. Due to the modulo operation, n is actually limited to the number of characters available, usually less than 60 or 70 characters. A brute force attack can be done by anybody fortunate enough to own a piece of paper and a pencil, not even to mention todays high-power computers. Here comes the Temporal Reverse Engineering into play. The message is not really encrypted with n, but with n+1. Not literally n+1, but the "n+1 effect" Peter described above. n is not a fixed constant, it is a flowing number always escaping your attempts to catch it. When you attack the message with "1", the real n will be "2". But when you try "2", n will already be "3". There's no way to catch it unless someone proves that the natural number do have a upper limit. Only the indented recipient is able to use the real n — for reasons, nobody but Peter Simons quite understands. One even more obscure thing is, that you are able to choose zero (0) as encryptor, which does not encipher the message at all. Nonetheless, nobody but the recipient will be able to read it! It isn't astonishing at all, that the infamous three letter agencies are not very fond of this invention. For decades, they fought their battle against encryption algorithms invented by the so called "opponent". But here comes an opponent they will not be able to beat. ROTn+1 gives unbreakable encryption to the masses. And unlike, say, RSA, it doesn't require much computer power to utilize it. The encryption itself is very straightforward and the determination of n can be done by a three year old child. Peter Simons has been quoted saying that ``the Temporal Reverse Engineering is so damned easy, you wouldn't even believe it if I told you how it works''. Furthermore he said: ``My ROTn+1 algorithm renders all cryptographic software in existence useless. Throw it away. PGP? Forget about it. Clipper? An April fools day joke — not more.'' [Speculation on whether the above-cited newsgroup postings violate any U.S. export-controls restrictions is left as an exercise to the reader. PGN]
A recent posting in comp.firewalls describes a new kind of PC virus. This one zaps the flash BIOS of Pentium motherboards. What makes it more interesting is that on the Endeavour EV-2 motherboards this behaviour is a killer, it renders it unusable; see: http://www.mrbios.com/ftp/big_risk.txt As it seems, this particular motherboard features: "(1) Its flash ROM does NOT implement a write-protected failsafe recovery "boot-block". (2) The flash ROM is soldered directly onto the system board. If anything at all happens to the flash that causes it to be inoperable, no practical method exists to restore it. No "recovery" utility can be run if the system won't boot." I can't but wonder what kind of demential design gave birth to such a sensitive piece of hardware: the BIOS ROM in a PC is a fundamental part of it: without it the machine is totally unusable. A FlashROM is by definition writable, and as such one can expect that a variety of circumstances may erase or rewrite it with bad data. And there are many! Not having a protected recovery block is bad enough. But soldering it so it can't be replaced is something I can't but qualify as "evil" (or "greedy" at least). The RISKs? Just let your imagination run wild: viruses like the 'Flash_killed' one, programming errors (yes, I've zapped the BIOS config of a PC this way a couple of times), power failures, using the wrong BIOS image or loader for an update, etc... Any of them (and many more) will render the machine totally worthless.
Treasury Secretary Robert Rubin has admitted to a congressional committee that his department doesn't have an overall master plan or blueprint for the multibillion modernization effort intended to replace the Sixties-era mainframes now in operation at the Internal Revenue Service and to link IRS offices across the nation. Congressman Jim Lightfoot characterized the project as "a $4-billion fiasco that is floundering because of inadequate planning." Secretary Rubin says the only plan that exists (and which he has not read) is a highly technical 6,000-page document that "is not what we need." (*Los Angeles Times*, 29 Mar 1996, D1)
Our immoderate moderator said >email e-mail Electronic mail [Distinguishing itself from every > other term on this list, the unhyphenated version > has no natural meaning whatever ...] I conclude the meanings of Email (German) and e'mail (French) are unnatural. Our moderator may consider himself lacquered. Es ist aber mir.. NO- YES- Interpretation egal e-gal It bothers me a whole lot electronically. Peter Ladkin [Peter, I am glad you are enameled with German and French (sorry; that is a Chinese pun). You must belong to the e-galite' sororite'? PGN] [The French was also noted by Bertrand Meyer <bertrand@eiffel.com>. The German is of course borrowed from the French. I knew that, but was carefully distinguishing Email and e'mail from email in noting the lack of (strict) misinterpretations for ``email''. PGN]
I think PGN has a very good proposal, and there's an addendum I'd like to make. In English, we have a little used stress mark that denotes precisely what you mention, although in the general case. This stress mark is called the diaeresis, and it looks like (and is commonly confused with) the umlaut that German has. The purpose of a diaeresis is to note that a vowel is supposed to be pronounced when ordinarily it would not be. For example, the word "co=F6perate" has a diaeresis on the second "o" so we can tell the difference between "working with" (co - operate) and "the process of becoming someone who makes barrels" (cooper-ate). Similarly, the word "na=EFf" is spelled with a diaeresis on the "i" so we know it is pronounced "nigh-EEF" and not "nay-f." It is also used on a final vowel that would ordinarily not be pronounced, like in the name "Bront=EB." In the past in RISKS we've talked about the hazards that have come from losing punctuation marks — for example, the people who refused to stop spelling their name with an umlaut. While these problems are less wide-spread in English than some other languages, they still exist. Computer scientists have only recently admitted that there are lower case letters, and only the howling of Europeans got accented characters into ISO Latin-1. Anglophones had to put up with na=EFve people who thought there were no accents in English, or were used only by people putting on some sort of a r=F4le. Even today, the Unicode folk still refuse to admit that there is such a thing as lower case numerals (yes, there are, and no they are NOT simply a display style), and I strongly suspect that the diaereses I put here (and shock horror, a circumflex) will get eaten somewhere along the way, most likely because early computer people could not count past seven unaided. Nonetheless, I don't think we should be daunted. We should use good old English, and spell "e-mail" "=EBmail". It looks cool (why do you think you see them liberally slathered on heavy-metal albums?), and best of all, it's correct usage. The diaeresis means to pronounce the e, so when some tin-horn techno-pedant complains, you can put them in their place and show them how us real technos do things. Jon Callas [Not a bad idea for folks who can deal with diaeresis, but there are still lots of problems that does not handle. PGN]
See http:/www.health.gov.bc.ca/newsrel/nrdate.html How does this relate to computers, since the root issues are generic? Well, for one thing having the data in machine readable form makes it much easier to merge and relate data and perform this kind of data mining. For another thing, the Single Payer system assigns unique province wide Practitioner ID numbers that makes it easier to relate data from separate points of sale. The same applies to Personal Health Numbers, but that doesn't seem to be at issue in this matter. Finally, when systems interact, it doesn't seem to be enough to ensure that Privacy/Confidentiality is protected on just one system. While Pharmanet wasn't the source of this information it defines a province wide standard that could simplify the task of combining information from different points of sale. For background the URL above has a couple of press releases about Minister's statements about regulation of Pharmaceutical company prices and profits. See Feb 26 and Feb 13. This has been getting a lot of news coverage since the Mulroney government ended "compulsory licencing" about a decade ago.
The subject of asynchronous, real-time, HMI design has been addressed (although almost certainly not yet "infallibly") by the literature in our field. As implied by Lauren Weinstein, however, in 'Technology "deterioration" ' earlier in the same issue of RISKS, the difficulty in keeping up with the literature is obviously a problem that contributes to risks. For those who are interested, the end of section 15.4.5 of Nancy Leveson's book "Safeware: System Safety and Computers," Addison-Wesley, contains an extract of a fuller discussion found in "Implications of the man-machine interface for software requirements completeness in real-time, safety-critical software systems," Proceedings of IFAC/IFIP SAFECOMP '89, Dec, 1989. The original IFAC article, addresses (among other topics) exactly the situation that Dick Mills described above and presents a design principle to prevent such situations --- disclaimer: Leveson and I wrote that article so mine is not an unbiased recommendation. It is also true that our solution, intended for safety critical systems, seems too elaborate for a simple, non-critical device such as a car radio. But, for safety-critical systems, some principles are known --- there might not need to be quite so much cause for despair. ...Matt mjaffe@msmail3.hac.com
That is not to say that NO bad effects are possible; even in _verite'_ systems, combining two devices can have unpleasant side effects. My new 1996 Chevy Lumina (generally an excellent specimen) exhibits such an effect. It has a radio with a built-in cassette player, just like my old 1990 Chevy Lumina (they're kinda habit-forming...). Well, not *just* like the 1990 model - the 1996 model has added a feature called a "cut tape detector". This device somehow (tension? optics?) continuously monitors the deck to insure that there is really tape running through the play heads. If it determines that there's no tape, it assumes that instead of running through the heads, the tape is snarling up inside the deck, and it ejects the cassette. This is a nice feature from some points of view, but from my perspective it's a dead loss. Why? Because I almost never use the cassette player to play tapes; in the 1990 Lumina I use it, with a Radio Shack adaptor, to play CDs on a portable CD player. But on the 1996 Lumina, I can't do this, because the CD-cassette adaptor has no tape! It just has a magnetic head which mates with the read head in the tape deck and "pretends to be a tape" from the point of view of the read head. No one has yet produced a CD-cassette adaptor which *also* pretends to be a tape from the point of view of the cut-tape detector, so I can't listen to CDs in the new car. (Naturally, I didn't know about this "feature" when I decided against the CD player option in the 1996 model...) Bob Blakley, IBM Austin, 11400 Burnet Rd. Bldg 903 Rm 7b-01 blakley@vnet.ibm.com FON 512 838-8133 t/l 678, FAX 823-8805 t/l 793
I've found a number of `technologically deficient' `features' in cellular telephone equipment, having had various phones over the last eight years (right now I'm on my fourth, a handheld with a booster in the car). Brand X telephone uses only a three-digit lock-code, and the lock code is not changeable by the user. This same Brand X telephone displays the phone number at power-up. Given that the initial lock code put in by the cellular vendor is the last X digits of the phone number, this isn't very secure. You have to take the phone back to the vendor to change the lock code. Brand Y telephone has a four-digit lock code and a five-digit security code. The lock code is used to lock/unlock the phone and set a few security parameters, and is resettable by the user. The security code is used to validate other parameters (including the lock code), and may not be reset by the user. The default settings are very easy. It is entirely possible, using the security code, to reset the lock code on a locked Brand Y phone, rendering the locking useless. I proved it to myself yesterday. Doug Sewell (doug@cc.ysu.edu) (http://cc.ysu.edu/~doug/) Youngstown Ohio is now area code 330.
[Note: the URLs of items in this article are posted in HTML format so that if you are reading this article via a browser, you can automatically reference the items mentioned. A plain-text list of all URLs used in this article will appear at the bottom.] One of IBM's World Wide Web sites contains an interesting summary of issues relating to the use of 6-digit dates and 2-digit years where the century was not included and thus are now and will cause problems in the future as calculations and other manipulations of dates will erroneously consider Saturday, January 1, 2000, to be 01/01/00 and thus an earlier date than Friday, December 31, 1999, being 12/31/99. There is a fairly well thought out article for people to consider on dealing with programs to correctly handle 4-digit dates. It also mentions the fact that the upgrading of old software is going to be expensive in people, resource and money terms. It includes URL references to other documents including an FAQ on the year 2000 problem, an article from CNN Interactive about the issue of two-digit years failing at 01/01/00. They also have a 500K+ white paper in that can be retrieved in several formats or in printed form by an E-mail request about the subject and what to do whether you use IBM hardware/software or not. The paper can be obtained from the article reference I indicated above. From what I read, it sounded interesting, neither an attempt to minimize the problem, nor an attempt to overhype it. It also points out that IBM was just as much responsible as everyone else was in developing software using 2-digit years. URL's used in this article: IBM Article: http://www.s390.ibm.com/stories/tran2000.html CNN Story: http://www.cnn.com/TECH/9601/2000/index.html Paul Robinson, General Manager, Tansin A. Darcos & Company/TDR, Inc.
I am a bit concerned seeing how many articles in RISKS quote external document through the use of URLs. Most of the time it is great how this makes information easier to get to, but what can we do to protect these links over time? RISKS is archived (Thanks!) so important information is preserved. However, many recent articles have had key information excluded and replaced with a URL (a recent article by Fred Cohen <fc@all.net> in 17.94 about the incident at all.net comas to mind, but there are others). URLs do a great job of handling some of the copyright and ownership issues as well as reducing clutter and expanding coverage. But--until we have Ted Nelsons (possibly utopian) Xanadu Hypertext docuverse with guarantee persistence of information--URL's will simply decay and destroy information. I think great care should be taken in such an important archived journal as RISKS to use URLs with care. They are great for off-loading long and boring conference announcement details where there is a built-in time limit for relevance anyway, but let us all make sure we preserve what is important. Johan Strandberg 1444 Jeffery Avenue (408) 723 5462 Clear Blue Software San Jose CA 95118-1134 johan@acm.org
Association For Computing Machinery Office of US Public Policy 666 Pennsylvania Avenue SE Suite 301 Washington, DC 20003 USA (tel) 202/298-0842 (fax) 202/547-5482 Institute of Electronics and Electrical Engineers United States Activities 1828 L Street NW Suite 1202 Washington, DC 20036-5104 USA (tel) 202/785-0017 (fax) 202/785-0835 2 April 1996 Honorable Conrad Burns Chairman, Subcommittee on Science, Technology and Space Senate Commerce, Science and Transportation Committee US Senate SD-508 Washington, DC 20510 Dear Chairman Burns: On behalf of the nation's two leading computing and engineering associations, we are writing to support your efforts, and the efforts of the other cosponsors of the Encrypted Communications Privacy Act, to remove unnecessarily restrictive controls on the export of encryption technology. The Encrypted Communications Privacy Act sets out the minimum changes that are necessary to the current export controls on encryption technology. However, we believe that the inclusion of issues that are tangential to export, such as key escrow and encryption in domestic criminal activities, is not necessary. The relaxation of export controls is of great economic importance to industry and users, and should not become entangled in more controversial matters. Current restrictions on the export of encryption technology harm the interests of the United States in three ways: they handicap American producers of software & hardware, prevent the development of a secure information infrastructure, and limit the ability of Americans using new online services to protect their privacy. The proposed legislation will help mitigate all of these problems, though more will need to be done to assure continued US leadership in this important hi-tech sector. Technological progress has moved encryption from the realm of national security into the commercial sphere. Current policies, as well as the policy-making processes, should reflect this new reality. The legislation takes a necessary first step in shifting authority to the Commerce Department and removing restrictions on certain encryption products. Future liberalization of export controls will allow Americans to excel in this market. The removal of out-dated restrictions on exports will also enable the creation of a Global Information Infrastructure sufficiently secure to provide seamless connectivity to customers previously unreachable by American companies. The United States is a leader in Internet commerce. However, Internet commerce requires cryptography. Thus American systems have been hindered by cold-war restraints on the necessary cryptography as these systems have moved from the laboratory to the marketplace. This legislation would open the market to secure, private, ubiquitous electronic commerce. The cost of not opening the market may include the loss of leadership in computer security technologies, just at the time when Internet users around the world will need good security to launch commercial applications. For this legislation to fulfill its promise the final approval of export regulations must be based on analysis of financial and commercial requirements and opportunities, not simply on the views of experts in national security cryptography. Therefore, we urge you to look at ways to further relax restrictive barriers. Finally, the legislation will serve all users of electronic information systems by supporting the development of a truly global market for secure desktop communications. This will help establish private and secure spaces for the work of users, which is of particular interest to the members of the IEEE/USA and the USACM. On behalf of the both the USACM and the IEEE/USA we look forward to working with you on this important legislation to relax export controls and promote the development of a robust, secure, and reliable communications infrastructure for the twenty-first century. Please contact Deborah Rudolph in the IEEE Washington Office at (202) 785-0017 or Lauren Gelman in the ACM Public Policy Office at (202) 298-0842 for any additional information. Sincerely, Barbara Simons, Ph.D.3 Chair, U.S. Public Policy Committee of ACM Joel B. Snyder, P.E. Vice President, Professional Activities and Chair, United States Activities Board cc: Members of the Subcommittee on Science, Technology and Space
Please report problems with the web pages to the maintainer