Practical security, Internet commercialization, etc.

[szabo@netcom.com (Nick Szabo)]

Paul Ferguson:
> The biggest threat to any security, on any basis, is the threat of
> human nature. The chances of someone factoring your PGP encoded
> message is somewhere in the range of slim-to-none, but the chances
> of someone (you) -physically- compromising their key is much, much
> higher.

I'd like to strongly second this, and add my own twist.
The problems of making & breaking ciphers are being hashed out, both 
in open literature and closed quarters (eg NSA), by many highly 
specialized minds far more focused on these problems 
than almost all of us on this list. The most important
cypherpunks issues are being almost completely ignored by these academics: 
practical implementation of remailers, most issues dealing with software-
based digital cash, reliable key handling, trustworhy key distribution,
construction of "webs of trust", implementation of these schemes with 
all of their pitfalls (legal, social, etc.), commercialization, etc.

In most of these cases, the protocols (ciphers, remailing mixes, 
digital cash, etc.) can theoretically be "broken" by a powerful
agent, but the real question is what practical, cheap steps can we take 
to make things more expensive for those with little respect for our
privacy or liberty.  Our design criterion should not be max(their expense) 
but min(our expense/their expense), where "our expense" includes the 
time needed to hack, test, deploy, and integrate these systems into the 
social net.fabric.  Furthermore, the antagonistic agent in almost all cases 
will have far less than the full computing power or crypto expertise
of the NSA at their disposal, and it's merely speculative fun to try to 
cover every possible attack at this time.  Romana Machado's "Stego" is 
a great example of useful steganography that address the simple practical 
issue of hiding data in Mac PICT files without worrying about the many
theoretical, statistical ways to detect encryption hidden in pattern-
containing pictures.  

Even if PGP could be broken by the NSA that's no reason not to use it, 
unless something significantly better comes along.  Real crypto-anarchy 
is quite imperfect, but vastly superior to no privacy at all,
the panoptic world to which the Internet sans cypherpunks 
seems to be heading.

Internet commercialization in itself is a _huge_ issue full of 
pitfall and  opportunity: Mom & Pop BBS's, commercial MUDs, 
data banks, for-profit pirate and porn boards, etc. are springing 
up everywhere like weeds, opening a vast array of both needs
of privacy and ways to abuse privacy.  Remailers, digital cash, etc. 
won't become part of this Internet commerce way of life unless they are
deployed soon, theoretical flaws and all, instead of waiting until 
The Perfect System comes along.  Crypto-anarchy in the real world
will be messy, "nature red in tooth and claw", not all nice
and clean like it says in the math books.  Most of the
debugging will be done not in any ivory tower, but by the 
bankruptcy of businesses who violate their customer's privacy, the 
confiscation of BBS operators who stray outside the laws of some 
jurisdication and screw up their privacy arrangements, etc.
Anybody who thinks they can flesh out a protocol in
secret and then deploy it, full-blown and working, is in for
a world of hurt.  For those who get their Pretty Good systems
out there and used, there is vast potential for business
growth -- think of the $trillions confiscated every year by 
governments around the world, for example.

At the last Bay Area meeting Tim May asked "what is the low-hanging 
fruit"?  A few pieces I see involve implementing _some_ of the discussed 
remailer function.  The non-SMTP socket solution looks attractive, even
if limited to TCP (which most if not all current remailers run
over anyway).  Non-SMTP sockets cut through the Gordion Knot of the
many attacks Hal Finney listed, making them far more expensive,
but not attempting to make them "theoretically impossible".  A
sockets solution seems much easier to implement, thus much
more likely to be implemented, than the huge piece of software needed 
to address address each of the 15-odd attacks in a theoretically 
strong way.

Nick Szabo				szabo@netcom.com