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"
By Tim May, see README
HTML by Jonathan Rochkind