From: Black Unicorn <unicorn@schloss.li>
Date: Thu, 4 Jul 1996 13:25:16 +0800
To: cypherpunks@toad.com
Subject: What remains to be done.
Message-ID: <Pine.SUN.3.94.960703055812.13232A-100000@polaris>
MIME-Version: 1.0
Content-Type: text/plain



Because I am not myself much of a programer, and because I have to find
excuses to feel useful, I thought I would annoy everyone with my ideas
about where c'punks might want to direct their efforts at encryption
development.

Of course any suggestion at direction tends to require a disclosure of the
assumptions one is working from.  The following are mine:

1.  The most interesting crypto uses and implementations seem to come from
grassroots programers, not large organizations.

Remailers, PGP, Curve Encrypt, Private Idaho, mixmaster, premail, and
magic money all were the results of "grassroots" efforts.  None of these
have been produced from massive corporate R and D programs, and most have
been the result of predominately a single programmer's efforts.

2.  The most useful crypto applications out there have tended to survive
by using crypto that looks forward, not to the past, or the present.  This
is generally manifest in the inclusion or easy use of multiple methods.

Zimmerman's selection of IDEA over DES, PGP's multiple key sizes, Curve
Encrypt's 3DES/IDEA option, are all examples of an effort to design
systems which will be useful tommorow, not just today.  PGPlib seems to
pick up this trend where PGP 2.x went awry.

3.  In so far as proliferation is important, the impact of crypto
applications and implementations is directly tied to ease of use.

If PGP has failings, one must be that it can be immensely intimidating to
the novice.  

4.  Increasingly cryptography is defying attempts at conventional
regulation.

5.  #4 will eventually spur sovereigns to rather drastic methods to defy
#4.

6.  Secure Communications, and transparent crypto are a Good Thing.


Assuming the above, I think it is apparent that crypto development should
be focused on a few general points and a few key areas.

As to general points, I think the clear concentrations include:


A.  Increasing the ease of use.

Perhaps I should have put this as #1, because really among those things
which I suggest in this post, I think this is of primary importance.  It
cannot be stressed enough that encryption must be transparent, easy to
use, but at the same time make its presence just apparent enough to
encourage its use, and to make users note its absence.

Crypto will have its most significant impact, its most liberating results,
and be self assuring only to the extent that it is not a novelty, but an
assumption.

Please, authors, coderpunks, make crypto easy to use, but flexible enough
so that adept and expert users can modify functional aspects.  (Key
generation, key size, exponent size, algorithm selection, level of
verbosity and suchlike should find their way into an expert menu
somewhere).

B.  Multiple encryption method support/larger key sizes.

While I may be more paranoid than some, or even most, I think it is
crucial to provide for the possibility that strong encryption may one day
face a total ban in more countries.  To avoid the chilling effect that
this would certainly have on development, it is of key importance to
permit applications and implementations to nexus with several methods, and
to allow what may today seem like extrodinarily large key sizes.  (256
bits would not be unreasonable in my view, particularly so where the user
was given the option of selecting a ~128 or so bit method like IDEA or
3DES at their option (consistent with A. above).

C.  Anonymous communication.

I'm not sure this needs much explanation.

D.  True stego.

Today it is a simple matter to identify encrypted traffic.  This is the
key flaw in what I will call (at risk of sounding like a white paper) the
NEI (National Encryption Infrastructure).  It subjects users to very
effective and easy to implement traffic analysis.  While I understand the
temptation to use checksum like methods to speed the key checking process,
at some point I am of the view that this convenience will come back to
haunt crypto.


Given these areas, what specific applications might be the best to look
into for the grassroots crypto advocate/coder?

A.  Methods to run secure websites on insecure servers.

A thread on 'punks last month, I am of the view that local decryption of
web pages is essential to the development of coercion free web pages.
Estlablishing a truely secure web page today requires the server to be
extra-terratorial, in a secure physical location, and requires such
lengths to defeat traffic analysis (which lengths must be applied to the
actual network logistics, rather than the software logistics) so as to be
impractical to all but institutional resources.  The best effort I have
seen is in European Union Bank (www.eub.com) or (www.eub.net) [neither of
which I recommend you use for deposits] and it still falls quite short.

A software solution which permits local decryption makes traffic analysis
less useful, presents the opportunity to use front end and disposable www
pages on domestic ISPs while imposing no liability on the ISP itself, and
opens several more effective traffic analysis deterants.

Ideally, both web proxies (for servers as well as clients) and local
decryption will be written allowing both server and user a degree of
double blind operation as well as easy disposability of front ends.

A Netscape plugin for local decryption of web pages and proxy forwarding
of WWW form submissions to the server is a MUST.

Is anyone considering work on these?


B. More effective message pools.

Really this is the only practical and most effective method to defeat
traffic analysis of e-mail communications.  Why do you think it is that
informants always communicate with the FBI in the classified ads?

This has been discussed again and again, yet I am aware of no serious
effort to construct an effective server or client to implement it more
effectively than USENET (which seems to be hopelessly slow and prone to
drop postings regularly)

I am encouraged by the new mixmaster model, but I have yet to read the
entire abstract carefully.


If the goal is, as I believe it should be, to make encryption accessible
and understood by, if not everyman and joe sixpack, joe digitalsixpack,
then it strikes me that the focus should be on WWW browsers and servers,
(Netscape like material), popular mailing programs (Eudora), and the
building blocks of the network, the point of origin, and the point of
final destination.

Point to point, grassroots plug ins to existing de facto standards, and
ease of use, ease of use, ease of use.

cypherpunks write code.

Call me "half a cypherpunk"

--
I hate lightning.  (unicorn@schloss.li)