5.11.1. This is not a main Cypherpunks concern, for a variety of
reasons (lots of work, special expertise, big machines, not a
core area, ciphers always win in the long run). Breaking
ciphers is something to consider, hence this brief section.
5.11.2. "What are the possible consequences of weaknesses in crypto
systems?"
- maybe reading messages
- maybe forging messages
- maybe faking timestamped documents
- maybe draining a bank account in seconds
- maybe winning in a crypto gambling system
- maybe matters of life and death
5.11.3. "What are the weakest places in ciphers, practically
speaking?"
- Key management, without a doubt. People leave their keys
lying around , write down their passphrases. etc.
5.11.4. Birthday attacks
5.11.5. For example, at Crypto '94 it was reported in a rump session
(by Michael Wiener with Paul van Oorschot) that a machine to
break the MD5 ciphers could be built for about $10 M (in 1994
dollars, of course) and could break MD5 in about 20 days.
(This follows the 1993 paper on a similar machine to break
DES.)
- Hal Finney did some calculations and reported to us:
- "I mentioned a few days ago that one of the "rump session"
papers at the crypto conference claimed that a machine
could be built which would find MD5 collisions for $10M in
about 20 days.....The net result is that we have taken
virtually no more time (the 2^64 creations of MD5 will
dominate) and virtually no space (compared to 2^64 stored
values) and we get the effect of a birthday attack. This
is another cautionary data point about the risks of relying
on space costs for security rather than time costs." [Hal
Finney, 1994-09-09]
5.11.6. pkzip reported broken
- "I finally found time to take a closer look at the
encryption algorithm by Roger Schlafly that is used in
PKZIP and have developed a practical known plaintext attack
that can find the entire 96-bit internal state." [Paul Carl
Kocher, comp.risks, 1994-09-04]
5.11.7. Gaming attacks, where loopholes in a system are exploited
- contests that are defeated by automated attacks
- the entire legal system can be viewed this way, with
competing teams of lawyers looking for legal attacks (and
the more complex the legal code, the more attacks can be
mounted)
- ecologies, where weaknesses are exploited ruthlessly,
forcing most species into extinction
- economies, ditto, except must faster
- the hazards for crypto schemes are clear
+ And there are important links to the issue of overly formal
systems, or systems in which ordinary "discretion" and
"choice" is overridden by rules from outside
- as with rules telling employers in great detail when and
how they can discharge employees (cf. the discussion of
"reasonable rules made mandatory," elsewhere)
- such rules get exploited by employees, who follow the
"letter of the law" but are performing in a way
unacceptable to the employer
- related to "locality of reference" points, in that
problem should be resolved locally, not with intervention
from afar.
- things will never be perfect, from the perspetive of all
parties, but meddling from outside makes things into a
game, the whole point of this section
+ Implications for digital money: overly complex legal
systems, without the local advantages of true cash (settled
locally)
+ may need to inject some supra-legal enforcement
mechanisms into the system, to make it converge
- offshore credit databases, beyond reach of U.S. and
other laws
+ physical violence (one reason people don't "play games"
with Mafia, Triads, etc., is that they know the
implications)
- it's not unethical, as I see it, for contracts in
which the parties understand that a possible or even
likely consequence of their failure to perform is
death
5.11.8. Diffie-Hellman key exchange vulnerabilities
- "man-in-the-midle" attack
+ phone systems use voice readback of LCD indicated number
- as computer power increases, even _this_ may be
insufficient
5.11.9. Reverse engineering of ciphers
- A5 code used in GSM phones was reverse engineered from a
hardware description
- Graham Toal reports (1994-07-12) that GCHQ blocked a public
lectures on this
By Tim May, see README
HTML by Jonathan Rochkind