1.Rijndael is harder to implement than, say Serpent, in my opinion.
I don't understand why you would say this: The Rijndael algorithm (Just call it "rain-doll") is probably the second simplest AES algorithm to implement[1]. True, the paper can be a little bit confusing for an implementer (since it begins with the mathematical motivation), the algorithm itself is incredably easy: The S-box is a table lookup. The key addition is XOR. The row shift is just a byte manipulation. And the column mixing is simply 4 table lookups and XORs.
Compare this to Serpent, which requires a rather arcane set of sbox optimizations to run well, or the very complicated structures of Twofish or, glod forbid, MARS.
[1] The only easier one is RC6, which has been described as something you can specify on a cocktail napkin.
The NSA tinkered with DES in two manners: Changing the S-boxes and reducing the key length. Both of these actually were done to strengthen the algorithm.
The S-box changes were rather mysterious, and were the origin of major speculation on the NSAs motives. However, when differential cryptoanalysis was discovered (about 15-20 years later), it was discovered that the S-box tweaks were specifically to strengthen DES against differential attacks. The NSA specifically modified the cypher to defend against a then publically unknown attack.
The second, reducing the key size, happened to also coincide to the differential behavior of DES. The core of the algorithm itself is really only about 2^56, not 2^64 in terms of work to cryptoanalyze. The key length was reduced to accuratly reflect the other cost of breaking the algorithm.
Remember, the NSA has a STRONG interest in insuring that the AES winner is a quality algorithm, since it will be used for secure but unclassified US government communications.[1] Also, while at the AES conference, talking with one of the NSA representatives, he was very happy with the security of all 5 algorithms and the process, that all the algorithms the NSA didn't like were eliminated in the first round.
[1] For classified systems, the NSA will still probably use their own algorithms, although this isn't suprising since the entire systems tend to be much more sophisticated in terms of system security. COTS solutions don't work for that market.
For those who are interested in technical analysis, the NIST Report is online.
The basic gist of the report is that all algorithms are secure to NIST's comfort, with a large number of various details. The main reason for selecting Rinjdael over the other algorithms came down to performance.
Whereas the other algorithms either ran well or poorly depending on the platform (Serpent poor in register-poor software and a large initial requirement for hardware, Twofish being very slow for software subkey generation, MARS requiring 32 bit multiply and having awful subkey generation, and RC6 also requiring 32 bit multiply and poor subkey generation), Rijndael runs well regardless of platform, be it hardware or software, smartcard microcontroller or IA64.
I also seriously doubt that the Hitachi patent claim had anything to do with the selection. IT was not even mentioned in the report on the IP section, and was incredably vague (Hitachi was claiming a patent on rotation in encryption. The Caesar cypher could probably be claimed as 2000 year old prior art).
Because secure cryptosystems are in the best interest of all but a few parties in the US government (*cough* 1/2 of the NSA *cough* CIA *cough*). The Federal Reserve, for example, depends on a secure banksystem, and DES and 3DES isn't cutting it.
Also, part of the point of this algorithm is that custom (read NSA designed) cryptographic hardware is expensive to make. Since the AES winner will be blessed by the NSA for secure governmental transactions in nonclassified systems, it is expected/hoped that the US government will be able to get secure cryptosystems for much lower costs.
Remember that 1/2 of the NSA is in charge of insuring that US Government communications ARE secure, they are greatly interested in AES being a success.
Correct, the formal winner is requried to give up all patent rights. It was not stated what would be the case with multiple winners (dear God NO, that would be worse than selecting Mars), but I would imagine that if NIST selected multiple winners, they would be from the set of Rijndael, serpent, and Twofish which are all unencumbered by patent restrictons.
Bruce Schneier put it well during the panel presentation: "Take Rijndael with extra rounds [1], Serpent, and Twofish, and flip a three sided coin, and you will have a good AES algorithm". All of the 3 have good subkey generation properties, are fast in hardware (although serpent is bigger), have good software properties, etc.
Also, serpent seems to be getting faster and faster in software, as the s-boxes are tweaked for specific architectures.
Both Mars and RC6 have some VERY bad properties: They rely on 32 bit multiplication, and run very poorly on any other device (including the IA64 when/if it gets built) and require way too much in hardware. The both have very poor subkey generation mechanisms. And MARS has the most baroque structure: I don't think anyone has actually succeded in doing subkey generation independenty of the reference code.
As for power attacks on smartcards, those should be solved at the system, not the circuit level, making the algorithm moot.
Note: I am not completely independant. I had a paper at the 3rd aes conference, where I advocated rijndael, serpent, or twofish. Although having an office down the hall from David Wagner's old office does make me a little biased.
The real limit is not on the processing, or the interface, but on the general input/output.
Where the limits of the integration comes in, however, are on the I/O side of the equasion.
Pop apart a digital camera, and no matter what device you attach it to, you will still require the lense and CCD for the camera to operate, those are the basic I/O requirements for that application.
Similarly, if you take apart a cellphone, about half of the circuits and parts you see are for the analog broadcasting side of the functionality. If you attempt to integrate a PDA with the cellphone, you will still need all these components, which can't be shared with just the PDA.
The key is on integration is to perform integration where and when there is, or can be, some overlap of the I/O requirements. EG, integrating a cell phone and a digital camera is silly, as they require two disjoint sets of I/O. But integrating a PDA and a cellphone makes sense, IF the wireless communications can be used for data (to the PDA) as well as voice.
If you do NOT allow the PDA to use the wireless network as a network fabric, there is very little point in integrating the two, since you still need all the cellphone wireless I/O, and all the PDA user I/O (screen, stylus, which are probably not needed for a cellphone), which makes for a very bulky device.
Also, two devices of half the size may be preferable to a single integrated device. I use a Palm Portable Keyboard with my pilot. Together, they take up a fair amount of space, but if I don't need the keyboard, it gets left at home, and, even if it was combined into the same unit of twice the volume, it would probably not be nearly so useful, as it is often harder to toss one large object in ones pocket, when compared to two smaller objects.
One project which I believe would be useful (and would be useful in the college curriculum as well) is that a useful skill is the ability to quickly learn a new and different programming language.
One such project would be the following, phrased in the following manner. "Here are some copies of the Adobe blue book (Postscript Language Tutorial and Cookbook) and red book (Postscript language reference). And here is a shape with a set of parameters. Write a postscript function which will draw the shape, given the parameters"
The point of the project is that the skill of learning a new language, with the use of the reference books, is a useful and (imo) necessary skill. The instructor should give assistance, but not teach the language. The exercise is in how to be self taught using the language reference materials.
Unfortunatly, the semantics of C do not allow easy general bounds checking, since arrays are semantically defined as pointer arithmatic, eg foo[i] is equivelent to *(foo + i). There is no actual array type in C!
A C-compiler can attempt to funge things to try some bounds-checking like operations, or hacks like stackguard which detect a class of misoperations or purify which does the same thing in a different manner, but the language itself semantically doesn't allow bounds-checking in general, due to how arrays and pointers are typed, without going through serious hacks like what Purify does. Of course, Purify ends up costing more then the bounds checking in a proper language would cost.
Except that if one is caring about security, one is using the bounds-checking versions of all the functions anyway, a proper compiler should be hoisting the checks outside of inner loops when possible, and other such factors means the overhead is far less than you would expect.
And finally, if you wish to build a reasonably secure system, you just have to accept the penalty. Which would you rather have: A web server which loses 10% of its performance to bounds-checking (be it automatic or programmer-derived), or a web server with lord-knows-what security holes in it?
Buffer overflows are the fault of the LANGUAGE. Important system utilities need to be written in bounds-checked languages. Some compilers, no matter the architecture, will write executable code on the stack: "trampolines". Unfortunatly, this is common enough that the OS can't blindly turn off the executable bit on the stack pages. And non-executable stack pages don't stop all buffer overflow attacks, they just require a 2 part attack: A heap buffer to write the code, and a stack buffer to overwrite the return address. The heap buffer doesn't necessarily even need to be overflown, the attacker just needs to be able to deduce the address. And one can't set heap-addresses to be nonexecutable, simply because there are MANY language environments which do create code at runtime, such as interpreters, JITs, etc etc etc.
This is a reprint of an article I wrote for MP3.com over a year ago, on why the SMDI (the record company's proposals for copy protection on computer music files) is massively insecure and can not meet its requirements. The same observations apply verbatum to the intertrust modifications to WinAmp.
April 27, 1999
The music industry appears to want a secure music transmission and storage scheme that performs the impossible: acts a mechanism for preventing or at least tracking the copying of audio data which is played on a user's personal computer. At most, any mechanism they provide will fail once a determined individual or group manages to circumvent the mechanisms used. Most of the possible mechanisms are relatively easy to circumvent.
I hope that this and other critiques of SDMI and similar initiatives will provoke the music industry into more productive directions that are more consumer-friendly and better thought through with respect to economic issues, rather than misusing technology in a vain attempt to solve intractable problems by the creation of baroque copy-protection mechanisms.
Such mechanisms will be bypassed. Even hardware copy-protection mechanisms (like those on the PlayStation) are routinely bypassed. The more such mechanisms inconvenience the user, with restrictions such as location codes or limited playings, the more likely they will be disabled by a large number of individuals.
The probable failure of SDMI to achieve it goals relates to one of the primary design requirements of the system: it must run on user's computers, and the user, not the SDMI player, has control of the hardware and operating system. This makes it nearly trivial for the various mechanisms to be bypassed and allows the simple distribution of bypass programs through the internet. Once one individual creates and publishes a crack, the djinn is out of the bottle and SDMI has failed to accomplish it's goal.
Any SDMI software player must interface with the user's sound card through the operating system. The operating system needs to communicate with the hardware itself through a device driver, a piece of code provided by the hardware vendor. The interface for creating device drivers on any particular operating system is well-documented and published in order to allow hardware manufacturers to develop new hardware that will work with the existing operating systems.
All that needs to be written to bypass all encryption, play limits, and similar mechanisms on a software player is a simple dummy device driver that takes the sound information provided by the program and records it to a file instead of playing it. Such a dummy driver can save the audio stream without loss of fidelity, since it receives the same information that would otherwise be sent to the sound card. Furthermore, since to a program this appears like any other sound device, there is no possible means for detecting this subterfuge without bypassing the operating system.
There is no practical way for an SDMI player to counter such an attack. It would be ridiculous to expect the SDMI player to write to the hardware directly, since that would require the player to include its own device drivers for all conceivable sound cards. Additionally, reasonably designed operating systems like Windows NT or all unix flavors do not allow a program to directly access hardware devices in order to prevent a user's program from performing illegal or inappropriate operations. Also, since the device driver appears to the operating system just like any other soundcard, there is no means for the SDMI player to determine whether it is writing to a real or fake device.
The only option preventing this problem is to have the SDMI player exist as a separate, physical device that takes the encrypted music stream and plays it out directly. Yet how many individuals will accept a separate music output on their computer when most computer speakers only have a single input? How many would be willing to switch cables when they want to stop listening to music and start playing games, or buy "SDMI compatible" soundcards that may be inferior to the one they already own?
Thus, the only goal remaining is the tracking and identifying the source of illegally copied music. This can be done by "digital watermarking," the selective insertion of noise that--although indistinguishable to a listener-- contains embeded data such as the proper owner of a song copyright. If each authorized download includes a different watermark, it would be possible to track the source of illegally copied material.
The problem with watermarks is that they are a security through obscurity scheme. Since they only exist in the noise and, by necessity, have no effect on the audio quality, they can be removed or changed without affecting the quality of the soundfile once the watermark format is understood. As soon as the music industry attempts to seriously track pirates through such a system, the pirates will quickly learn how to circumvent the watermarking. Once a single individual reverse engineers the watermark format, it becomes useless to halt organized pirates. Only the small, casual copiers would be consistently traceable by watermarking, and actually going after them through legal means would be impractical, akin to smashing ants with a sledgehammer.
My belief is that the SDMI initiative is incapable of meeting its goals through technical means. The recording industry's effort would be better spent trying to understand the economics of electronic distribution and focusing on how to create a new and different revenue stream out of electronic distribution, instead of trying to impose technical solutions to an intractable problem.
One question to ask is how much randomness do you really need? Depending on the application, you either really have no choice but to sit down and let the system's mix of pseudo random number generation and physcial system measurements generate enough bits. IIRC, linux systems use a mix of measurements (disk timing, keystrokes, mouse behavior) and a pseudo random number generator to create these bits. This makes them pretty GOOD random bits, but slow to gather.
But often you can get away with a GOOD pseudo random number generator, that is well seeded, to generate the mass of bits you need. You only actually need, say, 256 truely random bits to get the job done.
In which case, the easiest thing to do is grab a bunch of 8 sided dice, and roll them a bunch of times to seed your favorite cryptographically secure PRNG, and then use that to get all the pseudorandom bits you want. (8 sided dice are nice, because each roll generates 3 bits of entropy).
For information on PRNGs, go look through Applied Cryptography or a similar text.
All of these protocols involve direct peer to peer file transfering, without going through some sort of trusted intermediary or anonymous network. Thus, if you find someone has the item you are interested in, it is trivial to get the information: Just start the transfer, see the sucker's IP, and disconnect before you waste any more of your bandwidth. From there, you can go through whatever routines are necessary to associate an IP address with an individual.
Similarly, there is no means of authenticating files before downloading, so it is easy to make a tarbaby server: Just put up a bunch of bogus content, but interestingly named files. When someone tries to download it from you, you get the sucker's IP address.
Finally, under copyright law, the copyright holders do need to be rather active in defending their rites. Although I believe that Lars Ulrich and company are being rather ham-handed about how they go about it, they really have no choice but to at least make reasonable attempts. Otherwise, a copyright lapses if undefended, and someone could start manufacturing CDs of Metallica and the band could do nothing.
Is Napster really different from a company who's business model is "We want to make money by software piracy?"
The Indrema console has the same COTS-design related problems that also affect the X-Box (you can see this for my mildly paranoid discussion and speculation on the X-Box for more details on the X-Box's design problems).
The basic problem is the COTS (commercial, off the shelf) design ends up costing an extra $50-100 (in the extra memory, the hard drive, and the slightly higher cost for the CPU) more to produce then the Playstation 2 or whatever Nintendo is going to come out with, without providing significantly more capability as a game console. This is a huge handicap in the console market, where things are already sold at a loss to begin with.
Additionally, the proposal to make the GPU upgradeable defeats much of the purpose of a console: To provide a standard platform. The beauty of developing for a console is that all instances are identical, you don't need to worry about somebody having a less or more powerful machine.
However, unlike the X-Box, Indrema can't take the major economic losses Microsoft can on selling the console, in an attempt to get the platform established (and then gain revenue from the games and applications). Although annoying, Microsoft could tolerate an initial $100 loss on each console, if it allows the X-Box to become a viable platform. Indrema can not.
I suspect one of two scenarios: a) This is a company trying to get as much mileage out of the current Linux hype as possible, to get money from investors and (hopefully) an IPO, or b) these people actually believe in the snake oil they are selling, in which case someone should go to their headquarters, sit down with a calculator, and shoot down their financial projections before they cost their investors a lot of money.
In the deep past, it was DES. Everyone knew it, the code was readily available, the algorithm very heavily analyzed, and it was a near universal standard. In the future, it will be the AES winner, as the code will be readily available, the algorithm very heavily analyzed, and a near universal standard.
Currently, it has been more difficult. There was no clear standard when it became clear that DES's useful lifetime was over. People tended to use algorithms that were generally available and out for a while (therefore heavily analyzed), or which they have IP rights for. IDEA, 3DES, Blowfish, RC4, RC5, etc. 3DES and Blowfish being the most popular for open source and free projects, as they are both free of IP entanglements.
The AES process is relatively new. The five finalists have only been out there for a couple of years, and only been finalists for about a year and a half. Fortunatly, with the third AES conference behind us, and the winner due to be selected and announced within a couple of months, we will be returning to the days of DES, a common standard which everyone is free to use, with lots of implementations available.
Also, with the AES finalists, the IP entanglements weren't entirely clear. TwoFish and Rijndael were unentangled from the start, but Serpent had an initial patent filed, but then let the process lapse (so it is now unentangled). MARS and RC6 still have significant entanglements. The winner, of course, will become entanglement free (barring the IP attack scenario), but until then, chosing an AES candidate wasn't any better or worse then picking an older, available algorithm from an IP viewpoint or even from a security viewpoint (as they weren't very heavily analyzed by those other than the developers during the first round, as there were some 30 odd first round candidates).
Fortunatly, the AES winner will probably return us to the DES world: A trusted, entanglement free, well understood, secure algorithm.
One of the biggest "gotchas" which is incredably common (essentially universal) is the disclaimer of all liability for damage resulting from poor software.
One minor but good example: Microsoft should be liable for damage caused by the Melissa worm, they have known about the problem of word macro vicruses for years (one of the first wild word macro viruses was on a Microsoft CD!).
Yet there is no class action lawsuit aganst Microsoft, due to negligent design of the software, which they KNOW was asking for trouble and providing an incredible breeding ground for viruses.
Sony, yes, they are selling the PS2 at a loss. The consideration is, however, that the microsoft based design, by requiring more memory, a hard drive, and a more expensive processor/FLOP means that the X-box costs more to produce, and therefore Microsoft would have to lose considerably more money (and therefore either extract more/game in liscencing costs or sell more games/console) to break even, when compared to Sony.
In terms of raw, single precision floating point processing power, the PS2 handily beats anything else you can purchase today, or tomorrow, (short of a cray supercomputer or similar machine) because of its custom CPU design. I can consider some large applications where the cheapest solution would be to rackmount a large number of PS2s, connected together with ethernet. (The PS2 doesn't include ethernet, but does have USB, firewire, and PCMCIA)
The graphics chip, although not nearly as generally powerful as the current 3D cards for doing high resolution and high framerates, doesn't need to do as much because the geometry setup is generally handled in the very powerful FP vector units (where the flexibility is MUCH higher then the custom pipelines on current cards), and the IRAM nature of the graphics processor means it has incredable memory bandwidth. And remember, no matter WHAT happens, the graphics chip only needs to produce 30 FPS at TV resolution.
The key abilities for a game console is the ability to quickly process physics models and graphics models, to produce as near photorealistic effects as possible but at TV resolution. For that particular tast, the custom hardware of the PS2 beats the COTS solution of the X-box.
Also, development systems for the PS2 are not that expensive, some $20k/each, NOT $250k. And they are selling them for significantly less than the probable cost of production (considering that they are essentially a semicustom PC, produced in small volumes), but at a high enough price that only semiserious developers would purchase them.
It is considerably easier for Microsoft to make the X-box nearly bug-free when compared to most of their other products, for the simple reason that the hardware is under their control and the OS is much simpler. Even though Microsoft is going to produce it based on one of their existing OSs (probably NT), the act of cutting out huge volumes of unused and unneeded material and the necessity of supporting only a small amount of hardware, should make this a stable platform.
The problem with the X-box, however, is the heavily COTS (Commercial, Off the Shelf) design. Using a standard CPU, a standard OS, and what will undoubtedly be a modified version of a standard 3D graphics chip, all save on design cost and would save on production cost if only a small number are produced.
Yet game consoles sell by the millions, so the design cost is spread over so many devices and the cost savings of using COTS parts largely diminishes, since by the time someone fabricates one million custom CPUs, they don't cost any more than buying 1M comparable CPUs.
And the performance hit of using a COTS design is substantial. The Playstation 2's CPU is custom designed to the task at hand, able to perform a massive number of floating point calculations/clock cycle. It does not need to run SPEC, it is not an attractive compiler target for high performance code, and it is really 3 CPUs in one.
Thus, Toshiba's silicon (made for Sony) for the Playstation 2 drastically outperforms what Intel can possibly provide, for the specific tasks involved in driving an effective game console.
The additional problem with the X-box, again introduced by the COTS nature of the system, is the burden which even a stripped-down Microsoft OS places on the device. The cost of a hard disk and additional memory are potential killers when designing a device which should retail for less than $300.
A COTS design by Microsoft was undoubtedly chosen so they could hurry it out into the marketplace, but the result will probably be less then spectacular, since Sony's offering will probably significantly outperform the X-box once applications are written which can take advantage of the available computational power.
I think the article made this clear: MySQL is not set up to act as a distributed system, and would take considerable work to do so (work which, out of enlightened self interest, andover is funding).
So currently, the solution of "buy a big beefy machine" is the only one which works.
Asynchronous logic appears, every once in a while, as a "new" hot topic within VLSI and computer architecture research. Yet it has consistantly failed to offer the benefits it promises. Why?
It is true that clocks in synchronous design consume a great deal of power, but when low power designs are required, it is well understood how to gate and conditionalize clocks so they don't use power when the associated logic is not operating.
And asynchronous design has to be much more conservative than a synchronous design. With a synchronous design, a chip can be designed to operate at the maximum frequency, and then binned down if it fails to meet its target.
However, an asynchronous design requires that the delay lines be very conservatively designed, as if the delay line was a little faster, and the logic a little slower, on the worst case critical path, the chip would fail completly, which results in a slower processor by design.
Finally, the design methodology for building pipelined, synchronous devices is well understood, as a purely digital system. While asynchronous logic relies on building delay lines, essentially analog operations, which is a great disadvantage.
The lawsuit is undoubtedly based on copyright law, similar to the look & feel lawsuit of apple v microsoft. And the "look & feel" of the game clones is so close to that of the origional games in these cases, it is very hard to tell the difference. Even the NAMES are almost identical, such as "Mac-Man" or "Patriot Command".
Also, this is simply an out of court settlement. GT interactive and one other just agreed to stop and pay an "undisclosed sum", probably a token amount. The companies acted in their best self interest, since it is not like these atari clones are making any significant money, and fighting it out in court would cost more than capitulation.
It is unclear whether this lawsuit could really win, it would undoubtedly come down to a case by case, game by game basis in court.
Even if Hasbro won some of the counts against some of the companies, it would not have the chilling effect that the prophets of doom may cite. You can't copyright concepts, and there are no patents on gameplay (yet). Under copyright or look & feel suits, Unreal Tournament and Wolfenstein 3D are so vastly different, you won't mistake one for another.
Yet how do you tell the difference between MacMan and PacMan?
The ONLY problem with this box is the lack of ethernet. A USB ethernet adaptor is only 2 Mbps, which is simply too small for a modern processor on current LANs. If it had 10/100 ethernet or a PCMCIA card slot (for an ethernet card or other option), it would become the perfect little "brick".
With ethernet, it would make an excellent, low cost workstation when desk space is at a premium (such as our office), a GREAT low cost, high density server (you could probably fit 4 or 5 in a 1U rackmount, at least, for only $5,000 or so. Try to beat that compute/volume, storage/volume and cost/performance with any other device), and a wonderful mini server to shove in a desk drawer next to the ethernet hub.
If it had ethernet, we would have bought at least one for our office immediately, I would suggest my sister buy one instead of a laptop (she wants a mobile machine to transport between her office and home, but not general mobility), and might have bought one for myself to replace the noisy and large services machine taking up space in my kitchen.
But the lack of a high bandwidth networking option turns this from an effective machine into nothing more than a cute toy.
The Iopener hack has shown what has been wanted by members of the community for a long time: a low cost, fanless, computer suitable for use as a terminal or other device, but with a reasonable degree of processing power. The Iopener was the first such device to come along in recent memory, and the first with a decent amount of processing power.
However, it is quite clear that Netpliance can't make a profit at $99, or even $199 for these machines: they are loss leaders for their internet service. As such, it is perfectly understandable that they make it difficult/impossible to use for other than their intended tasks.
But the demand for this box suggests that a slight revision would prove useful: A standard IDE conector, the heatsink changed to include a disk mounting bracket, for a $299-$350 price point. Call it the "Opened I".
The "standard" device shipped as the Iopener could be identical, but without the bracket and without populating (soldering onto the motherboard) the IDE connector, so the $99/199 loss leader device can't be modified without a lot of effort, but the same design can be sold for those who would desire a lightweight full machine, just by populating the connector and adding the mounting bracket.
Especially when ethernet is added (undoubtedly coming soon, so the Iopener can take advantage of corporate networks, DSL, and cable modems), an "Opened I" variant ($299 diskless, but with IDE connector and network booting capabilities) could easily become a very popular hobbiest and corporate terminal, to be plopped down wherever and whenever a small, cheap, low footprint, low noise machine is needed. I know I would buy one in a hot second.
Slashdot Mirror
Square was the predecesor to Rijndael: It had some vulnerabilities which Rijndael was designed to correct.
Nicholas C Weaver
nweaver@cs.berkeley.edu
1.Rijndael is harder to implement than, say Serpent, in my opinion.
I don't understand why you would say this: The Rijndael algorithm (Just call it "rain-doll") is probably the second simplest AES algorithm to implement[1]. True, the paper can be a little bit confusing for an implementer (since it begins with the mathematical motivation), the algorithm itself is incredably easy: The S-box is a table lookup. The key addition is XOR. The row shift is just a byte manipulation. And the column mixing is simply 4 table lookups and XORs.
Compare this to Serpent, which requires a rather arcane set of sbox optimizations to run well, or the very complicated structures of Twofish or, glod forbid, MARS.
[1] The only easier one is RC6, which has been described as something you can specify on a cocktail napkin.
Nicholas C Weaver
nweaver@cs.berkeley.edu
The NSA tinkered with DES in two manners: Changing the S-boxes and reducing the key length. Both of these actually were done to strengthen the algorithm.
The S-box changes were rather mysterious, and were the origin of major speculation on the NSAs motives. However, when differential cryptoanalysis was discovered (about 15-20 years later), it was discovered that the S-box tweaks were specifically to strengthen DES against differential attacks. The NSA specifically modified the cypher to defend against a then publically unknown attack.
The second, reducing the key size, happened to also coincide to the differential behavior of DES. The core of the algorithm itself is really only about 2^56, not 2^64 in terms of work to cryptoanalyze. The key length was reduced to accuratly reflect the other cost of breaking the algorithm.
Remember, the NSA has a STRONG interest in insuring that the AES winner is a quality algorithm, since it will be used for secure but unclassified US government communications.[1] Also, while at the AES conference, talking with one of the NSA representatives, he was very happy with the security of all 5 algorithms and the process, that all the algorithms the NSA didn't like were eliminated in the first round.
[1] For classified systems, the NSA will still probably use their own algorithms, although this isn't suprising since the entire systems tend to be much more sophisticated in terms of system security. COTS solutions don't work for that market.
Nicholas C Weaver
nweaver@cs.berkeley.edu
For those who are interested in technical analysis, the NIST Report is online.
The basic gist of the report is that all algorithms are secure to NIST's comfort, with a large number of various details. The main reason for selecting Rinjdael over the other algorithms came down to performance.
Whereas the other algorithms either ran well or poorly depending on the platform (Serpent poor in register-poor software and a large initial requirement for hardware, Twofish being very slow for software subkey generation, MARS requiring 32 bit multiply and having awful subkey generation, and RC6 also requiring 32 bit multiply and poor subkey generation), Rijndael runs well regardless of platform, be it hardware or software, smartcard microcontroller or IA64.
I also seriously doubt that the Hitachi patent claim had anything to do with the selection. IT was not even mentioned in the report on the IP section, and was incredably vague (Hitachi was claiming a patent on rotation in encryption. The Caesar cypher could probably be claimed as 2000 year old prior art).
Nicholas C Weaver
nweaver@cs.berkeley.edu
Because secure cryptosystems are in the best interest of all but a few parties in the US government (*cough* 1/2 of the NSA *cough* CIA *cough*). The Federal Reserve, for example, depends on a secure banksystem, and DES and 3DES isn't cutting it.
Also, part of the point of this algorithm is that custom (read NSA designed) cryptographic hardware is expensive to make. Since the AES winner will be blessed by the NSA for secure governmental transactions in nonclassified systems, it is expected/hoped that the US government will be able to get secure cryptosystems for much lower costs.
Remember that 1/2 of the NSA is in charge of insuring that US Government communications ARE secure, they are greatly interested in AES being a success.
Nicholas C Weaver
nweaver@cs.berkeley.edu
Correct, the formal winner is requried to give up all patent rights. It was not stated what would be the case with multiple winners (dear God NO, that would be worse than selecting Mars), but I would imagine that if NIST selected multiple winners, they would be from the set of Rijndael, serpent, and Twofish which are all unencumbered by patent restrictons. Bruce Schneier put it well during the panel presentation: "Take Rijndael with extra rounds [1], Serpent, and Twofish, and flip a three sided coin, and you will have a good AES algorithm". All of the 3 have good subkey generation properties, are fast in hardware (although serpent is bigger), have good software properties, etc. Also, serpent seems to be getting faster and faster in software, as the s-boxes are tweaked for specific architectures. Both Mars and RC6 have some VERY bad properties: They rely on 32 bit multiplication, and run very poorly on any other device (including the IA64 when/if it gets built) and require way too much in hardware. The both have very poor subkey generation mechanisms. And MARS has the most baroque structure: I don't think anyone has actually succeded in doing subkey generation independenty of the reference code. As for power attacks on smartcards, those should be solved at the system, not the circuit level, making the algorithm moot. Note: I am not completely independant. I had a paper at the 3rd aes conference, where I advocated rijndael, serpent, or twofish. Although having an office down the hall from David Wagner's old office does make me a little biased.
Nicholas C Weaver
nweaver@cs.berkeley.edu
The real limit is not on the processing, or the interface, but on the general input/output.
Where the limits of the integration comes in, however, are on the I/O side of the equasion.
Pop apart a digital camera, and no matter what device you attach it to, you will still require the lense and CCD for the camera to operate, those are the basic I/O requirements for that application.
Similarly, if you take apart a cellphone, about half of the circuits and parts you see are for the analog broadcasting side of the functionality. If you attempt to integrate a PDA with the cellphone, you will still need all these components, which can't be shared with just the PDA.
The key is on integration is to perform integration where and when there is, or can be, some overlap of the I/O requirements. EG, integrating a cell phone and a digital camera is silly, as they require two disjoint sets of I/O. But integrating a PDA and a cellphone makes sense, IF the wireless communications can be used for data (to the PDA) as well as voice.
If you do NOT allow the PDA to use the wireless network as a network fabric, there is very little point in integrating the two, since you still need all the cellphone wireless I/O, and all the PDA user I/O (screen, stylus, which are probably not needed for a cellphone), which makes for a very bulky device.
Also, two devices of half the size may be preferable to a single integrated device. I use a Palm Portable Keyboard with my pilot. Together, they take up a fair amount of space, but if I don't need the keyboard, it gets left at home, and, even if it was combined into the same unit of twice the volume, it would probably not be nearly so useful, as it is often harder to toss one large object in ones pocket, when compared to two smaller objects.
Nicholas C Weaver
nweaver@cs.berkeley.edu
One project which I believe would be useful (and would be useful in the college curriculum as well) is that a useful skill is the ability to quickly learn a new and different programming language.
One such project would be the following, phrased in the following manner. "Here are some copies of the Adobe blue book (Postscript Language Tutorial and Cookbook) and red book (Postscript language reference). And here is a shape with a set of parameters. Write a postscript function which will draw the shape, given the parameters"
The point of the project is that the skill of learning a new language, with the use of the reference books, is a useful and (imo) necessary skill. The instructor should give assistance, but not teach the language. The exercise is in how to be self taught using the language reference materials.
Nicholas C Weaver
nweaver@cs.berkeley.edu
Unfortunatly, the semantics of C do not allow easy general bounds checking, since arrays are semantically defined as pointer arithmatic, eg foo[i] is equivelent to *(foo + i). There is no actual array type in C!
A C-compiler can attempt to funge things to try some bounds-checking like operations, or hacks like stackguard which detect a class of misoperations or purify which does the same thing in a different manner, but the language itself semantically doesn't allow bounds-checking in general, due to how arrays and pointers are typed, without going through serious hacks like what Purify does. Of course, Purify ends up costing more then the bounds checking in a proper language would cost.
Nicholas C Weaver
nweaver@cs.berkeley.edu
Except that if one is caring about security, one is using the bounds-checking versions of all the functions anyway, a proper compiler should be hoisting the checks outside of inner loops when possible, and other such factors means the overhead is far less than you would expect.
And finally, if you wish to build a reasonably secure system, you just have to accept the penalty. Which would you rather have: A web server which loses 10% of its performance to bounds-checking (be it automatic or programmer-derived), or a web server with lord-knows-what security holes in it?
Nicholas C Weaver
nweaver@cs.berkeley.edu
Buffer overflows are the fault of the LANGUAGE. Important system utilities need to be written in bounds-checked languages. Some compilers, no matter the architecture, will write executable code on the stack: "trampolines". Unfortunatly, this is common enough that the OS can't blindly turn off the executable bit on the stack pages. And non-executable stack pages don't stop all buffer overflow attacks, they just require a 2 part attack: A heap buffer to write the code, and a stack buffer to overwrite the return address. The heap buffer doesn't necessarily even need to be overflown, the attacker just needs to be able to deduce the address. And one can't set heap-addresses to be nonexecutable, simply because there are MANY language environments which do create code at runtime, such as interpreters, JITs, etc etc etc.
Nicholas C Weaver
nweaver@cs.berkeley.edu
(Second attempt, forgot to have cookies active)
This is a reprint of an article I wrote for MP3.com over a year ago, on why the SMDI (the record company's proposals for copy protection on computer music files) is massively insecure and can not meet its requirements. The same observations apply verbatum to the intertrust modifications to WinAmp.
April 27, 1999
The music industry appears to want a secure music transmission and storage scheme that performs the impossible: acts a mechanism for preventing or at least tracking the copying of audio data which is played on a user's personal computer. At most, any mechanism they provide will fail once a determined individual or group manages to circumvent the mechanisms used. Most of the possible mechanisms are relatively easy to circumvent.
I hope that this and other critiques of SDMI and similar initiatives will provoke the music industry into more productive directions that are more consumer-friendly and better thought through with respect to economic issues, rather than misusing technology in a vain attempt to solve intractable problems by the creation of baroque copy-protection mechanisms.
Such mechanisms will be bypassed. Even hardware copy-protection mechanisms (like those on the PlayStation) are routinely bypassed. The more such mechanisms inconvenience the user, with restrictions such as location codes or limited playings, the more likely they will be disabled by a large number of individuals.
The probable failure of SDMI to achieve it goals relates to one of the primary design requirements of the system: it must run on user's computers, and the user, not the SDMI player, has control of the hardware and operating system. This makes it nearly trivial for the various mechanisms to be bypassed and allows the simple distribution of bypass programs through the internet. Once one individual creates and publishes a crack, the djinn is out of the bottle and SDMI has failed to accomplish it's goal.
Any SDMI software player must interface with the user's sound card through the operating system. The operating system needs to communicate with the hardware itself through a device driver, a piece of code provided by the hardware vendor. The interface for creating device drivers on any particular operating system is well-documented and published in order to allow hardware manufacturers to develop new hardware that will work with the existing operating systems.
All that needs to be written to bypass all encryption, play limits, and similar mechanisms on a software player is a simple dummy device driver that takes the sound information provided by the program and records it to a file instead of playing it. Such a dummy driver can save the audio stream without loss of fidelity, since it receives the same information that would otherwise be sent to the sound card. Furthermore, since to a program this appears like any other sound device, there is no possible means for detecting this subterfuge without bypassing the operating system.
There is no practical way for an SDMI player to counter such an attack. It would be ridiculous to expect the SDMI player to write to the hardware directly, since that would require the player to include its own device drivers for all conceivable sound cards. Additionally, reasonably designed operating systems like Windows NT or all unix flavors do not allow a program to directly access hardware devices in order to prevent a user's program from performing illegal or inappropriate operations. Also, since the device driver appears to the operating system just like any other soundcard, there is no means for the SDMI player to determine whether it is writing to a real or fake device.
The only option preventing this problem is to have the SDMI player exist as a separate, physical device that takes the encrypted music stream and plays it out directly. Yet how many individuals will accept a separate music output on their computer when most computer speakers only have a single input? How many would be willing to switch cables when they want to stop listening to music and start playing games, or buy "SDMI compatible" soundcards that may be inferior to the one they already own?
Thus, the only goal remaining is the tracking and identifying the source of illegally copied music. This can be done by "digital watermarking," the selective insertion of noise that--although indistinguishable to a listener-- contains embeded data such as the proper owner of a song copyright. If each authorized download includes a different watermark, it would be possible to track the source of illegally copied material.
The problem with watermarks is that they are a security through obscurity scheme. Since they only exist in the noise and, by necessity, have no effect on the audio quality, they can be removed or changed without affecting the quality of the soundfile once the watermark format is understood. As soon as the music industry attempts to seriously track pirates through such a system, the pirates will quickly learn how to circumvent the watermarking. Once a single individual reverse engineers the watermark format, it becomes useless to halt organized pirates. Only the small, casual copiers would be consistently traceable by watermarking, and actually going after them through legal means would be impractical, akin to smashing ants with a sledgehammer.
My belief is that the SDMI initiative is incapable of meeting its goals through technical means. The recording industry's effort would be better spent trying to understand the economics of electronic distribution and focusing on how to create a new and different revenue stream out of electronic distribution, instead of trying to impose technical solutions to an intractable problem.
Nicholas C Weaver
nweaver@cs.berkeley.edu
One question to ask is how much randomness do you really need? Depending on the application, you either really have no choice but to sit down and let the system's mix of pseudo random number generation and physcial system measurements generate enough bits. IIRC, linux systems use a mix of measurements (disk timing, keystrokes, mouse behavior) and a pseudo random number generator to create these bits. This makes them pretty GOOD random bits, but slow to gather.
But often you can get away with a GOOD pseudo random number generator, that is well seeded, to generate the mass of bits you need. You only actually need, say, 256 truely random bits to get the job done.
In which case, the easiest thing to do is grab a bunch of 8 sided dice, and roll them a bunch of times to seed your favorite cryptographically secure PRNG, and then use that to get all the pseudorandom bits you want. (8 sided dice are nice, because each roll generates 3 bits of entropy).
For information on PRNGs, go look through Applied Cryptography or a similar text.
Nicholas C Weaver
nweaver@cs.berkeley.edu
All of these protocols involve direct peer to peer file transfering, without going through some sort of trusted intermediary or anonymous network. Thus, if you find someone has the item you are interested in, it is trivial to get the information: Just start the transfer, see the sucker's IP, and disconnect before you waste any more of your bandwidth. From there, you can go through whatever routines are necessary to associate an IP address with an individual.
Similarly, there is no means of authenticating files before downloading, so it is easy to make a tarbaby server: Just put up a bunch of bogus content, but interestingly named files. When someone tries to download it from you, you get the sucker's IP address.
Finally, under copyright law, the copyright holders do need to be rather active in defending their rites. Although I believe that Lars Ulrich and company are being rather ham-handed about how they go about it, they really have no choice but to at least make reasonable attempts. Otherwise, a copyright lapses if undefended, and someone could start manufacturing CDs of Metallica and the band could do nothing.
Is Napster really different from a company who's business model is "We want to make money by software piracy?"
Nicholas C Weaver
nweaver@cs.berkeley.edu
The Indrema console has the same COTS-design related problems that also affect the X-Box (you can see this for my mildly paranoid discussion and speculation on the X-Box for more details on the X-Box's design problems).
The basic problem is the COTS (commercial, off the shelf) design ends up costing an extra $50-100 (in the extra memory, the hard drive, and the slightly higher cost for the CPU) more to produce then the Playstation 2 or whatever Nintendo is going to come out with, without providing significantly more capability as a game console. This is a huge handicap in the console market, where things are already sold at a loss to begin with.
Additionally, the proposal to make the GPU upgradeable defeats much of the purpose of a console: To provide a standard platform. The beauty of developing for a console is that all instances are identical, you don't need to worry about somebody having a less or more powerful machine.
However, unlike the X-Box, Indrema can't take the major economic losses Microsoft can on selling the console, in an attempt to get the platform established (and then gain revenue from the games and applications). Although annoying, Microsoft could tolerate an initial $100 loss on each console, if it allows the X-Box to become a viable platform. Indrema can not.
I suspect one of two scenarios: a) This is a company trying to get as much mileage out of the current Linux hype as possible, to get money from investors and (hopefully) an IPO, or b) these people actually believe in the snake oil they are selling, in which case someone should go to their headquarters, sit down with a calculator, and shoot down their financial projections before they cost their investors a lot of money.
Nicholas C Weaver
nweaver@cs.berkeley.edu
In the deep past, it was DES. Everyone knew it, the code was readily available, the algorithm very heavily analyzed, and it was a near universal standard. In the future, it will be the AES winner, as the code will be readily available, the algorithm very heavily analyzed, and a near universal standard.
Currently, it has been more difficult. There was no clear standard when it became clear that DES's useful lifetime was over. People tended to use algorithms that were generally available and out for a while (therefore heavily analyzed), or which they have IP rights for. IDEA, 3DES, Blowfish, RC4, RC5, etc. 3DES and Blowfish being the most popular for open source and free projects, as they are both free of IP entanglements.
The AES process is relatively new. The five finalists have only been out there for a couple of years, and only been finalists for about a year and a half. Fortunatly, with the third AES conference behind us, and the winner due to be selected and announced within a couple of months, we will be returning to the days of DES, a common standard which everyone is free to use, with lots of implementations available.
Also, with the AES finalists, the IP entanglements weren't entirely clear. TwoFish and Rijndael were unentangled from the start, but Serpent had an initial patent filed, but then let the process lapse (so it is now unentangled). MARS and RC6 still have significant entanglements. The winner, of course, will become entanglement free (barring the IP attack scenario), but until then, chosing an AES candidate wasn't any better or worse then picking an older, available algorithm from an IP viewpoint or even from a security viewpoint (as they weren't very heavily analyzed by those other than the developers during the first round, as there were some 30 odd first round candidates).
Fortunatly, the AES winner will probably return us to the DES world: A trusted, entanglement free, well understood, secure algorithm.
Nicholas C Weaver
nweaver@cs.berkeley.edu
One of the biggest "gotchas" which is incredably common (essentially universal) is the disclaimer of all liability for damage resulting from poor software.
One minor but good example: Microsoft should be liable for damage caused by the Melissa worm, they have known about the problem of word macro vicruses for years (one of the first wild word macro viruses was on a Microsoft CD!).
Yet there is no class action lawsuit aganst Microsoft, due to negligent design of the software, which they KNOW was asking for trouble and providing an incredible breeding ground for viruses.
Nicholas C Weaver
nweaver@cs.berkeley.edu
Sony, yes, they are selling the PS2 at a loss. The consideration is, however, that the microsoft based design, by requiring more memory, a hard drive, and a more expensive processor/FLOP means that the X-box costs more to produce, and therefore Microsoft would have to lose considerably more money (and therefore either extract more/game in liscencing costs or sell more games/console) to break even, when compared to Sony.
In terms of raw, single precision floating point processing power, the PS2 handily beats anything else you can purchase today, or tomorrow, (short of a cray supercomputer or similar machine) because of its custom CPU design. I can consider some large applications where the cheapest solution would be to rackmount a large number of PS2s, connected together with ethernet. (The PS2 doesn't include ethernet, but does have USB, firewire, and PCMCIA)
The graphics chip, although not nearly as generally powerful as the current 3D cards for doing high resolution and high framerates, doesn't need to do as much because the geometry setup is generally handled in the very powerful FP vector units (where the flexibility is MUCH higher then the custom pipelines on current cards), and the IRAM nature of the graphics processor means it has incredable memory bandwidth. And remember, no matter WHAT happens, the graphics chip only needs to produce 30 FPS at TV resolution.
The key abilities for a game console is the ability to quickly process physics models and graphics models, to produce as near photorealistic effects as possible but at TV resolution. For that particular tast, the custom hardware of the PS2 beats the COTS solution of the X-box.
Also, development systems for the PS2 are not that expensive, some $20k/each, NOT $250k. And they are selling them for significantly less than the probable cost of production (considering that they are essentially a semicustom PC, produced in small volumes), but at a high enough price that only semiserious developers would purchase them.
It is considerably easier for Microsoft to make the X-box nearly bug-free when compared to most of their other products, for the simple reason that the hardware is under their control and the OS is much simpler. Even though Microsoft is going to produce it based on one of their existing OSs (probably NT), the act of cutting out huge volumes of unused and unneeded material and the necessity of supporting only a small amount of hardware, should make this a stable platform.
The problem with the X-box, however, is the heavily COTS (Commercial, Off the Shelf) design. Using a standard CPU, a standard OS, and what will undoubtedly be a modified version of a standard 3D graphics chip, all save on design cost and would save on production cost if only a small number are produced.
Yet game consoles sell by the millions, so the design cost is spread over so many devices and the cost savings of using COTS parts largely diminishes, since by the time someone fabricates one million custom CPUs, they don't cost any more than buying 1M comparable CPUs.
And the performance hit of using a COTS design is substantial. The Playstation 2's CPU is custom designed to the task at hand, able to perform a massive number of floating point calculations/clock cycle. It does not need to run SPEC, it is not an attractive compiler target for high performance code, and it is really 3 CPUs in one.
Thus, Toshiba's silicon (made for Sony) for the Playstation 2 drastically outperforms what Intel can possibly provide, for the specific tasks involved in driving an effective game console.
The additional problem with the X-box, again introduced by the COTS nature of the system, is the burden which even a stripped-down Microsoft OS places on the device. The cost of a hard disk and additional memory are potential killers when designing a device which should retail for less than $300.
A COTS design by Microsoft was undoubtedly chosen so they could hurry it out into the marketplace, but the result will probably be less then spectacular, since Sony's offering will probably significantly outperform the X-box once applications are written which can take advantage of the available computational power.
I think the article made this clear: MySQL is not set up to act as a distributed system, and would take considerable work to do so (work which, out of enlightened self interest, andover is funding).
So currently, the solution of "buy a big beefy machine" is the only one which works.
Asynchronous logic appears, every once in a while, as a "new" hot topic within VLSI and computer architecture research. Yet it has consistantly failed to offer the benefits it promises. Why?
It is true that clocks in synchronous design consume a great deal of power, but when low power designs are required, it is well understood how to gate and conditionalize clocks so they don't use power when the associated logic is not operating.
And asynchronous design has to be much more conservative than a synchronous design. With a synchronous design, a chip can be designed to operate at the maximum frequency, and then binned down if it fails to meet its target.
However, an asynchronous design requires that the delay lines be very conservatively designed, as if the delay line was a little faster, and the logic a little slower, on the worst case critical path, the chip would fail completly, which results in a slower processor by design.
Finally, the design methodology for building pipelined, synchronous devices is well understood, as a purely digital system. While asynchronous logic relies on building delay lines, essentially analog operations, which is a great disadvantage.
The lawsuit is undoubtedly based on copyright law, similar to the look & feel lawsuit of apple v microsoft. And the "look & feel" of the game clones is so close to that of the origional games in these cases, it is very hard to tell the difference. Even the NAMES are almost identical, such as "Mac-Man" or "Patriot Command".
Also, this is simply an out of court settlement. GT interactive and one other just agreed to stop and pay an "undisclosed sum", probably a token amount. The companies acted in their best self interest, since it is not like these atari clones are making any significant money, and fighting it out in court would cost more than capitulation.
It is unclear whether this lawsuit could really win, it would undoubtedly come down to a case by case, game by game basis in court.
Even if Hasbro won some of the counts against some of the companies, it would not have the chilling effect that the prophets of doom may cite. You can't copyright concepts, and there are no patents on gameplay (yet). Under copyright or look & feel suits, Unreal Tournament and Wolfenstein 3D are so vastly different, you won't mistake one for another.
Yet how do you tell the difference between MacMan and PacMan?
The ONLY problem with this box is the lack of ethernet. A USB ethernet adaptor is only 2 Mbps, which is simply too small for a modern processor on current LANs. If it had 10/100 ethernet or a PCMCIA card slot (for an ethernet card or other option), it would become the perfect little "brick".
With ethernet, it would make an excellent, low cost workstation when desk space is at a premium (such as our office), a GREAT low cost, high density server (you could probably fit 4 or 5 in a 1U rackmount, at least, for only $5,000 or so. Try to beat that compute/volume, storage/volume and cost/performance with any other device), and a wonderful mini server to shove in a desk drawer next to the ethernet hub.
If it had ethernet, we would have bought at least one for our office immediately, I would suggest my sister buy one instead of a laptop (she wants a mobile machine to transport between her office and home, but not general mobility), and might have bought one for myself to replace the noisy and large services machine taking up space in my kitchen.
But the lack of a high bandwidth networking option turns this from an effective machine into nothing more than a cute toy.
The Iopener hack has shown what has been wanted by members of the community for a long time: a low cost, fanless, computer suitable for use as a terminal or other device, but with a reasonable degree of processing power. The Iopener was the first such device to come along in recent memory, and the first with a decent amount of processing power.
However, it is quite clear that Netpliance can't make a profit at $99, or even $199 for these machines: they are loss leaders for their internet service. As such, it is perfectly understandable that they make it difficult/impossible to use for other than their intended tasks.
But the demand for this box suggests that a slight revision would prove useful: A standard IDE conector, the heatsink changed to include a disk mounting bracket, for a $299-$350 price point. Call it the "Opened I".
The "standard" device shipped as the Iopener could be identical, but without the bracket and without populating (soldering onto the motherboard) the IDE connector, so the $99/199 loss leader device can't be modified without a lot of effort, but the same design can be sold for those who would desire a lightweight full machine, just by populating the connector and adding the mounting bracket.
Especially when ethernet is added (undoubtedly coming soon, so the Iopener can take advantage of corporate networks, DSL, and cable modems), an "Opened I" variant ($299 diskless, but with IDE connector and network booting capabilities) could easily become a very popular hobbiest and corporate terminal, to be plopped down wherever and whenever a small, cheap, low footprint, low noise machine is needed. I know I would buy one in a hot second.
In order to keep the internet extra-spiffy-clean, you should keep your terminal disconnected for at least 10 days, 30 days if you are an AOL user.