Cyphernomicon Top
Cyphernomicon 17.7

The Future:
New Software Tools and Programming Frameworks


   17.7.1. Needed software
           - Drop-in crypto modules are a needed development. As V.
              Bontchev says, "it would be nice if disk encryption
              software allowed the user to plug in their own modules.
              This way everybody could use whatever they trust - MDC/SHA,
              MDC/MD5, DES, IDEA, whatever." [V.B., sci.crypt, 1994-07-
              01]
           + Robustness
             - Security and robustness are often at odds
             - Files that are wiped at the first hint of intrusion
                (digital flash paper), remailer sites that go down at the
                first signs of trouble, and file transmission systems
                that split files into multiple pieces--any one of which
                can be lost, thus destroying the whole transmission--are
                not exactly models of robustness.
             - Error correction usually works by decreasing entropy
                through redundancy, which is bad for crypto.
             - The military uses elaborate (and expensive) systems to
                ensure that systems do not go down, keys are not lost,
                etc. Most casual users of crypto are unwilling to take
                these steps.
             - And so keys are lost, passphrases are forgotten (or are
                written down on Post-It Notes and taped to terminals),
                and remailers are taken down when operators go on
                vacation. All very flaky and non-robust.
             - Look at how flaky mail delivery is!
             + A challenge is to create systems which are:
               - robust
               - not too complicated and labor-intensive to use
               - where redundancy does not compromise security
           + Crypto workbench
             - An overused term, perhaps, but one that captures the
                metaphor of a large set of tools, templates, programming
                aids, etc.
             + QKS and "Agents Construction Kit" (under development)
               - along with Dylan, DylanAgents, Telescript, and probably
                  several other attempts to develop agent toolkits
             - Henry Strickland is using "tcl" (sort of a scripting
                language, like "perl") as a basis.
           + Software crisis
             - tools, languages, frameworks, environments, objects,
                class libraries, methods, agents, correctness,
                robustness, evolution, prototyping
             + Connections between the software crisis and cryptography
               - complex systems, complicated protocols
               - price of being "wrong" can be very high, whether it's
                  an airport that can't open on time (Denver) or a
                  digital bank that has its assets drained in seconds
               - agents, objects are hoped to be the "silver bullets"
             + The need for better software methodologies
               - "silver bullets"
               - failures, errors, flaws, methods
               - provably correct designs? (a la Viper)
               - It is often said that much better methodologies are
                  needed for _real time programming_, due to the time-
                  criticality and (probably) the difficulty of doing
                  realistic testing. But surely the same should be said
                  of _financial programming_, a la the banking and
                  digicash schemes that interest us so much.
               - "the one aspect of software that most makes it the
                  flaky industry it is is that it is unusual for
                  practitioners to study the work of others.  Programmers
                  don't read great programs.  Designers don't study
                  outstanding designs. The consequences ... no, just look
                  for yourself. [Cameron Laird, comp.software-eng, 1994-
                  08-30]
             + Large Software Constructs
               - The software crisis becomes particularly acute when
                  large systems are built, such as--to apply this to
                  Cypherpunks issues--when digital money systems and
                  economies are built.
   17.7.2. Object-oriented tools
           + While tres trendy, some very real gains are being reported;
              more than just a buzzword, especially when combined with
              other tools:
             - frameworks, toolkits
             + dynamic languages
               - greater flexibility than with static, strongly-typed
                  langueages (but also less safety, usually)
           - OpenStep, Visual Age, Visual Basic, Dylan, Telescript (more
              agent-oriented), Lisp, Smalltalk, etc
   17.7.3. Protocol Ecologies
           - Behavioral simulations of agents, digital money, spoofing,
              etc.
           - the world in which Alice and Bob and their crypto friends
              live
           - defense, attack, spoofing, impersonation, theft
           - elements that are cryptographically strong (like D-H key
              exchanges), but combined in complex ways that almost have
              to be simulated to find weaknesses
           - "middle-out" instead of "top-down" (conventional, formal)
              or "bottom-up" (emergent, A-LIFE)
           - like Eurisko (Lenat), except oriented toward the domain of
              financial agents
   17.7.4. Use of autonomous agents (slaves?)
           - "An advanced telecommunications environment offers a number
              of ways to protect yourself against the problems involved
              in dealing with anonymous entities in a situation in which
              there is no monopoly Government.....When one's PBX finds
              that one's call is not going through via a particular long
              distance carrier, it automatically switches to another one.
              It is easy to imagine one's intelligent agents testing
              various sorts of transaction completions and switching
              vendors when one fails. Professional checkers can supply
              information on vendor status for a fee. After all, we don't
              care if a company we are dealing with changes if its
              service is unaffected."  [Duncan Frissell, 1994-08-30]
   17.7.5. Tools
           + "Languages within languages" is a standard way to go to
              implement abstractions
             - "Intermediate Design Languages" (IDLs)
             - abstract concepts: such as "engines" and "futures"
             - Lisp and Scheme have been favored languages for this
             - other languages as well: Smalltalk, Dylan
           + For crypto, this seems to be the case: abstractions
              represented as classes or objects
             - with programming then the selective subclassing
             - and sometimes gener
           + "type checking" of crypto objects is needed
             - to ensure compliance with protocols, with forms expected,
                etc.
             - check messages for form, removal of sigs, etc. (analogous
                to checking a letter before mailing for proper
                addressing, for stamp, sealing, etc.)
             - much of the nonrobustness of mail and crypto comes from
                the problems with exception handling--things that a human
                involved might be able to resolve, in conventional mail
                systems
             - "dead letter department"?
             - Note: In the "Crypto Anarchy Game" we played in
                September, 1992, many sealed messages were discarded for
                being in the wrong form, lacking the remailer fee that
                the remailer required, etc. Granted, human beings make
                fairly poor maintainers of complex constraints....a lot
                of people just kept forgetting to do what was needed. A
                great time was had by all.
   17.7.6. "What programming framework features are needed?"
           - What follows are definitely my opnions, even more my own
              opinions than most of what I've written. Many people will
              disagree.
           + Needed:
             - Flexibility over speed
             - Rapid prototyping, to add new features
             - Evolutionary approaches
             - Robustness (provably correct would be nice, but...)
   17.7.7. Frameworks, Tools, Capabilities
           - Nearly all the cutting-edge work in operating systems, from
              "mutually suspicious cooperating processes" to "deadlock"
              to "persistence," show up in the crypto areas we are
              considering.
           + Software of the Net vs. Software to Access the Net
             - The Net--is current form adequate?
             - Software for Accessing the Net
           + OpenDoc and OLE
             - components working together, on top of various operating
                systems, on top of various hardware platforms
           + Persistent Object Stores
             - likely to be needed for the systems we envision
             - robust, so that one's "money" doesn't evaporate when a
                system is rebooted!
             - interesting issues here...
             - CORBA. OpenDoc, OLE II, SOM, DOE, Gemstone, etc.
           + Programming Frameworks
             - Dynamic languages may be very useful when details are
                fuzzy, when the ideas need exploration (this is not a
                call for nondeterminism, for random futzing around, but a
                recognition that the precise, strongly-typed approach of
                some languages may be less useful than a rich,
                exploratory environment. This fits with the "ecology"
                point of view.
             -
           + Connectivity
             - needs to be more robust, not flaky the way current e-mail
                is
             - handshakes, agents, robust connections
             - ATM, SONET, agents, etc....the "Net of the Future"
 

Next Page: 17.8 Complexity
Previous Page: 17.6 The Effects of Strong Crypto on Society

By Tim May, see README

HTML by Jonathan Rochkind