13.4.1. "What are Cypherpunks projects?"
- Always a key part--perhaps _the_ key part--of Cypherpunks
activity. "Cypherpunks write code." From work on PGP to
remailers to crypto toolkits to FOIA requests, and a bunch
of other things, Cypherpunks hack the system in various
ways.
- Matt Blaze's LEAF blower, Phil Karn's "swIPe" system, Peter
Wayner's articles....all are examples. (Many Cypherpunks
projects are also done, or primarily done, for other
reasons, so we cannot in all cases claim credit for this
work.)
13.4.2. Extensions to PGP
13.4.3. Spread of PGP and crypto in general.
- education
- diskettes containing essays, programs
- ftp sites
- raves, conventions, gatherings
13.4.4. Remailers
+ ideal Chaumian mix has certain properties
- latency to foil traffic analysis
- encryption
- no records kept (hardware tamper-resistance, etc.)
- Cyperpunks remailers
- julf remailers
+ abuses
- flooding, because mail transmission costs are not borne
by sender
+ anonymity produces potential for abuses
- death threats, extortion
- Progress continues, with new features added. See the
discussion in the remailers section.
13.4.5. Steganography
- hiding the existence of a message, for at least some amount
of time
- security through obscurity
- invisible ink, microdots
+ Uses
- in case crypto is outawed, may be useful to avoid
authorities
- if enough people do it, increases the difficulty of
enforcing anti-crypto laws (all
+ Stego
- JSTEG:
soda.berkeley.edu:/pub/cypherpunks/applications/jsteg
- Stego: sumex-aim.stanford.edu
13.4.6. Anonymous Transaction Systems
13.4.7. Voice Encryption, Voice PGP
- Clipper, getting genie out of bottle
- CELP, compression, DSPs
- SoundBlaster approach...may not have enough processing
power
+ hardware vs. pure software
- newer Macs, including av Macs and System 7 Pro, have
interesting capabilities
+ Zimmermann's plans have been widely publicized, that he is
looking for donations, that he is seeking programming help,
etc.
- which does not bode well for seeing such a product from
him
- frankly, I expect it will come from someone else
- Eric Blossom is pursuing own hardware board, based on 2105
+ "Is anyone building encrypted telephones?"
-
+ Yes, several such projects are underway. Eric Blossom
even showed a
- PCB of one at a Cypherpunks meeting, using an
inexpensive DSP chip.
-
+ Software-only versions, with some compromises in speech
quality
- probably, are also underway. Phil Zimmermann
described his progress at
+ the last Cypherpunks meeting.
-
- ("Software-only" can mean using off-the-shelf, widely-
available DSP
+ boards like SoundBlasters.)
-
- And I know of at least two more such projects.
Whether any will
+ materialize is anyone's guess.
-
- And various hacks have already been done. NeXT users
have had
- voicemail for years, and certain Macs now offer
something similar.
+ Adding encryption is not a huge obstacle.
-
- A year ago, several Cypherpunks meeting sites around
the U.S. were
- linked over the Internet using DES encryption. The
sound quality was
- poor, for various reasons, and we turned off the DES
in a matter of
- minutes. Still, an encrypted audio conference call.
13.4.8. DC-Nets
- What it is, how it works
- Chaum's complete 1988 "Journal of Cryptology" article is
available at the Cypherpunks archive site,
ftp.soda.csua.edu, in /pub/cypherpunks
+ Dining Cryptographers Protocols, aka "DC Nets"
+ "What is the Dining Cryptographers Problem, and why is it
so important?"
+ This is dealt with in the main section, but here's
David Chaum's Abstract, from his 1988 paper"
- Abstract: "Keeping confidential who sends which
messages, in a world where any physical transmission
can be traced to its origin, seems impossible. The
solution presented here is unconditionally or
cryptographically secure, depending on whether it is
based on one-time-use keys or on public keys.
respectively. It can be adapted to address
efficiently a wide variety of practical
considerations." ["The Dining Cryptographers Problem:
Unconditional Sender and Recipient Untraceability,"
David Chaum, Journal of Cryptology, I, 1, 1988.]
-
- DC-nets have yet to be implemented, so far as I know,
but they represent a "purer" version of the physical
remailers we are all so familiar with now. Someday
they'll have have a major impact. (I'm a bigger fan of
this work than many seem to be, as there is little
discussion in sci.crypt and the like.)
+ "The Dining Cryptographers Problem: Unconditional Sender
and Recipient Untraceability," David Chaum, Journal of
Cryptology, I, 1, 1988.
- available courtesy of the Information Liberation Front
at the soda.csua.berkeley.edu site
- Abstract: "Keeping confidential who sends which
messages, in a world where any physical transmission
can be traced to its origin, seems impossible. The
solution presented here is unconditionally or
cryptographically secure, depending on whether it is
based on one-time-use keys or on public keys.
respectively. It can be adapted to address efficiently
a wide variety of practical considerations." ["The
Dining Cryptographers Problem: Unconditional Sender and
Recipient Untraceability," David Chaum, Journal of
Cryptology, I, 1, 1988.]
- Note that the initials "D.C." have several related
meanings: Dining Cryptographers, Digital Cash/DigiCash,
and David Chaum. Coincidence?
+ Informal Explanation
- Note: I've posted this explanation, and variants,
several times since I first wrote it in mid-1992. In
fact, I first posted it on the "Extropians" mailing
list, as "Cypherpunks" did not then exist.
- Three Cypherpunks are having dinner, perhaps in Palo
Alto. Their waiter tells them that their bill has
already been paid, either by the NSA or by one of them.
The waiter won't say more. The Cypherpunks wish to know
whether one of them paid, or the NSA paid. But they
don't want to be impolite and force the Cypherpunk
payer to 'fess up, so they carry out this protocol (or
procedure):
Each Cypherpunk flips a fair coin behind a menu placed
upright between himself and the Cypherpunk on his
right. The coin is visible to himself AND to the
Cypherpunk on his left. Each Cypherpunk can see his own
coin and the coin to his right. (STOP RIGHT HERE!
Please take the time to make a sketch of the situation
I've described. If you lost it here, all that follows
will be a blur. It's too bad the state of the Net today
cannot support figures and diagrams easily.)
Each Cypherpunk then states out loud whether the two
coins he can see are the SAME or are DIFFERENT, e.g.,
"Heads-Tails" means DIFFERENT, and so forth. For now,
assume the Cypherpunks are truthful. A little bit of
thinking shows that the total number of "DIFFERENCES"
must be either 0 (the coins all came up the same), or
2. Odd parity is impossible.
Now the Cypherpunks agree that if one of them paid, he
or she will SAY THE OPPOSITE of what they actually see.
Remember, they don't announce what their coin turned up
as, only whether it was the same or different as their
neighbor.
Suppose none of them paid, i.e., the NSA paid. Then
they all report the truth and the parity is even
(either 0 or 2 differences). They then know the NSA
paid.
Suppose one of them paid the bill. He reports the
opposite of what he actually sees, and the parity is
suddenly odd. That is, there is 1 difference reported.
The Cypherpunks now know that one of them paid. But can
they determine which one?
Suppose you are one of the Cypherpunks and you know you
didn't pay. One of the other two did. You either
reported SAME or DIFFERENT, based on what your neighbor
to the right (whose coin you can see) had. But you
can't tell which of the other two is lying! (You can
see you right-hand neighbor's coin, but you can't see
the coin he sees to his right!)
This all generalizes to any number of people. If none
of them paid, the parity is even. If one of them paid,
the parity is odd. But which one of them paid cannot be
deduced. And it should be clear that each round can
transmit a bit, e.g., "I paid" is a "1". The message
"Attack at dawn" could thus be "sent" untraceably with
multiple rounds of the protocol.
- The "Crypto Ouija Board": I explain this to people as a
kind of ouija board. A message, like "I paid" or a more
interesting "Transfer funds from.....," just "emerges"
out of the group, with no means of knowing where it
came from. Truly astounding.
+ Problems and Pitfalls
- In Chaum's paper, the explanation above is given
quickly, in a few pages. The _rest_ of the paper is
then devoted to dealing with the many "gotchas" and
attacks that come up and that must be dealt with before
the DC protocol is even remotely possible. I think all
those interested in protocol design should read this
paper, and the follow-on papers by Bos, Pfitzmann,
etc., as object lessons for dealing with complex crypto
protocols.
+ The Problems:
- 1. Collusion. Obviously the Cypherpunks can collude
to deduce the payer. This is best dealt with by
creating multiple subcircuits (groups doing the
protocol amongst themselves). Lots more stuff here.
Chaum devotes most of the paper to these kind of
issues and their solutions.
2. With each round of this protocol, a single bit is
transmitted. Sending a long message means many coin
flips. Instead of coins and menus, the neighbors
would exchange lists of random numbers (with the
right partners, as per the protocol above, of course.
Details are easy to figure out.)
3. Since the lists are essentially one-time pads, the
protocol is unconditionally secure, i.e., no
assumptions are made about the difficulty of
factoring large numbers or any other crypto
assumptions.
4. Participants in such a "DC-Net" (and here we are
coming to the heart of the "crypto anarchy" idea)
could exchange CD-ROMs or DATs, giving them enough
"coin flips" for zillions of messages, all
untraceable! The logistics are not simple, but one
can imagine personal devices, like smart card or
Apple "Newtons," that can handle these protocols
(early applications may be for untraceable
brainstorming comments, secure voting in corportate
settings, etc.)
5. The lists of random numbers (coin flips) can be
generated with standard cryptographic methods,
requiring only a key to be exchanged between the
appropriate participants. This eliminates the need
for the one-time pad, but means the method is now
only cryptographically secure, which is often
sufficient. (Don't think "only cryptographically
secure" means insecure....the messages may remain
encrypted for the next billion years)
6. Collisions occur when multiple messages are sent
at the same time. Various schemes can be devised to
handle this, like backing off when you detect another
sender (when even parity is seen instead of odd
parity). In large systems this is likely to be a
problem. Deliberate disruption, or spamming, is a
major problem--a disruptor can shut down the DC-net
by sending bits out. As with remailes, anonymity
means freedom from detection. (Anonymous payments to
send a message may help, but the details are murky to
me.)
+ Uses
- * Untraceable mail. Useful for avoiding censorship, for
avoiding lawsuits, and for all kinds of crypto anarchy
things.
- * Fully anonymous bulletin boards, with no traceability
of postings or responses. Illegal materials can be
offered for sale (my 1987 canonical example, which
freaked out a few people: "Stealth bomber blueprints
for sale. Post highest offer and include public key.").
Think for a few minutes about this and you'll see the
profound implications.
- * Decentralized nexus of activity. Since messages
"emerge" (a la the ouija board metaphor), there is no
central posting area. Nothing for the government to
shut down, complete deniability by the participants.
- * Only you know who your a partners are....in any given
circuit. And you can be in as many circuits as you
wish. (Payments can be made to others, to create a
profit motive. I won't deal with this issue, or with
the issue of how reputations are handled, here.)
- It should be clear that DC-nets offer some amazing
opportunities. They have not been implemented at all, and
have received almost no attention compared to ordinary
Cypherpunks remailers. Why is this? The programming
complexity (and the underlying cryptographic primitives
that are needed) seems to be the key. Several groups have
announced plans to imlement some form of DC-net, but
nothing has appeared.
- software vs. hardware,
- Yanek Martinson, Strick, Austin group, Rishab
- IMO, this is an ideal project for testing the efficacy of
software toolkits. The primitives needed, including bit
commitment, synchronization, and collusion handling, are
severe tests of crypto systems. On the downside, I doubt
that even the Pfaltzmans or Bos has pulled off a running
simulation...
13.4.9. D-H sockets, UNIX, swIPe
+ swIPe
- Matt Blaze, John I. (did coding), Phil Karn, Perry
Metzger, etc. are the main folks involved
- evolved from "mobile IP," with radio links, routing
- virtual networks
- putting encryption in at the IP level, transparently
- bypassing national borders
- Karn
- at soda site
+ swIPe system, for routing packets
- end to end, gateways, links, Mach, SunOS
13.4.10. Digital Money, Banks, Credit Unions
- Magic Money
- Digital Bank
- "Open Encrypted Books"
- not easy to do...laws, regulations, expertise in banking
- technical flaws, issues in digital money
+ several approaches
- clearing
- tokens, stamps, coupons
- anonymity-protected transactions
13.4.11. Data Havens
+ financial info, credit reports
- bypassing local jurisdictions, time limits, arcane rules
- reputations
- insider trading
- medical
- technical, scientific, patents
- crypto information (recursively enough)
- need not be any known location....distributed in
cyberspace
- One of the most commercially interesting applications.
13.4.12. Related Technologies
- Agorics
- Evolutionary Systems
- Virtual Reality and Cyberspace
- Agents
+ Computer Security
+ Kerberos, Gnu, passwords
- recent controversy
- demon installed to watch packets
- Cygnus will release it for free
- GuardWire
+ Van Eck, HERF, EMP
- Once Cypherpunk project proposed early on was the
duplication of certain NSA capabilities to monitor
electronic communications. This involves "van Eck"
radiation (RF) emitted by the CRTs and other electronics
of computers.
+ Probably for several reasons, this has not been pursued,
at least not publically.
- legality
- costs
- difficulty in finding targets of opportunity
- not a very CPish project!
13.4.13. Matt Blaze, AT&T, various projects
+ a different model of trust...multiple universes
- not heierarchical interfaces, but mistrust of interfaces
- heterogeneous
- where to put encryption, where to mistrust, etc.
+ wants crypto at lowest level that is possible
- almost everything should be mistrusted
- every mistrusted interface shoud be cryptographically
protected...authentication, encryption
+ "black pages"---support for cryptographic communication
- "pages of color"
- a collection of network services that identiy and deliver
security information as needed....keys, who he trusts,
protocols, etc.
+ front end: high-level API for security requirements
- like DNS? caching models?
- trusted local agent....
+ "people not even born yet" (backup tapes of Internet
communications)
- tapes stored in mountains, access by much more powerful
computers
+ "Crytptographic File System" (CFS)
- file encryption
- no single DES mode appears to be adequate...a mix of
modes
+ swIPe system, for routing packets
- end to end, gateways, links, Mach, SunOS
13.4.14. Software Toolkits
+ Henry Strickland's TCL-based toolkit for crypto
- other Cypherpunks, including Hal Finney and Marianne
Mueller, have expressed good opinions of TCL and TCL-TK
(toolkit)
- Pr0duct Cypher's toolkit
- C++ Class Libraries
- VMX, Visual Basic, Visual C++
- Smalltalk
By Tim May, see README
HTML by Jonathan Rochkind