Martin Packer wrote: >I don't know when restrictions on encryption were lifted but when I first >was involved with encryption in the late 1980's it was pretty restrictive >who could have it. >So the point is - because of the restricted availability - it's possible >the injection of encryption into sites and applications might be less than >desirable.
U.S. export restrictions on encryption were never mainframe-specific, and they involved export, not the U.S. market. When they existed, the restrictions affected practically every system. Former President Clinton lifted most of the export restrictions in 1996 (with Executive Order 13026). But (as many observers pointed out at the time, and exploited) the U.S. government never could legally block original source code published in an exported, paper book, including source code that could be scanned (or re-keyed), compiled, and run on a MVS (or OS/390) system of that era. Nor could the U.S. government legally block anything manufactured outside the United States by a non-U.S. entity. The "fancy" stuff, e.g. secure key cryptography, was more tightly controlled and is still controlled to some extent. (And not only by the U.S. government.) Also not unique to mainframes, although mainframes do the fancy stuff exceptionally well when they're allowed. Most systems don't do the fancy stuff at all, which is a great reason to buy a couple IBM mainframes (with CryptoExpress and, preferably but optionally, the TKE workstation). Mainframe application changes are rarely required to implement effective encryption, and they will be even less often required over time if encryption is the only requirement. I can't really say the same thing about other platforms, not to that extent. Encryption always has *some* cost. It's computational math, after all, plus a bit of work (labor) to implement and to maintain. Not much cost, especially nowadays with competent implementation, but nonzero. Security breaches also have costs. If somebody wants to make a programming language-centered argument about security vulnerabilities, you'd find quite a bit of agreement that C and C+ + are comparatively weak foundations from a security point of view, for a variety of reasons that have proven persistently difficult to fix well. C and C++ are not unknown among mainframe applications, middleware, and operating systems -- far from it -- but they're somewhat less common on mainframes than in the IT world at large, in percentage terms. If you hold that viewpoint -- and you probably are correct in that viewpoint -- then, ceteris paribus, a more mainframe-oriented computing environment would be inherently more secure. Hard core, mission critical, mixed workload, time sharing environments -- the z/OS mainframe being the preeminent example -- also get some security help from the fact that they have to defend well against "accidental invasions." These are not reasons to rest easy, though. Healthy paranoia has merit. -------------------------------------------------------------------------------------------------------- Timothy Sipples IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA E-Mail: [email protected] ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
