[3708] in cryptography@c2.net mail archive
Re: Wassenaar vs. CipherSaber
daemon@ATHENA.MIT.EDU (Raph Levien)
Sat Dec 5 10:39:09 1998
Date: Fri, 04 Dec 1998 17:41:27 -0800
From: Raph Levien <raph@acm.org>
To: Steve Bellovin <smb@research.att.com>
CC: jim@acm.org, cryptography@c2.net
Steve Bellovin wrote:
> I'm glad the site is up, but for many purposes it solves the wrong problem.
> Encryption algorithms are easy to write, or even to type in or scan from
> printed programs. But what's interesting is easy-to-use crypto, or
> crypto that can interoperate. Remember that most of PGP is *not*
> crypto algorithms.
Indeed, people who assert that "the cat is out of the bag" regarding the
widespread international availability of crypto algorithms are missing
the point of why export restrictions work.
I'm spending more and more of my time these days in the free software
community (not all that big a leap for a cypherpunk). I'm seeing the
"crypto integration" problem all over the place. One example: PRCS is a
from-the-ground-up replacement for CVS (i.e. a source code repository
system). Strong authentication is clearly very important, and encryption
can be in some cases. The principle author (Josh MacDonald) is no dummy.
He's in the office next to mine at Berkeley, and is taking the security
class offered this semester by Ian Goldberg and Dave Wagner. Yet, it's a
pain for him to integrate strong crypto because of the export laws.
Putting IPSEC in the Linux kernel distribution faces the same problem.
It just can't be done given the way development is done. I've heard
OpenBSD tries to get around the problem by localizing the
crypto-sensitive development in Canada, but that ain't gonna work if
Wassenaar gets encoded into legislation there.
The Gnome desktop project uses CORBA as the basis for component
software. Again, there's another place were strong authentication is
important, and encryption desirable in many cases.
I think CipherSaber is on to something here. What about the possibility
of designing crypto standards so simple that they can be reimplemented
over and over again, instead of being the core focus of an app. Each
country could have its own parallel development. This sounds horrible
for an app of the complexity of PGP, but what if it were a protocol that
any competent programmer could do in a couple of days? What if the
interfaces were so solid, well understood, and documented that it didn't
really matter that there were a few dozen implementations? Something to
think about.
Unfortunately, projects like 3-line perl rsa and CipherSaber fall short
of something that could be used in a real system. But perhaps there's a
middle ground. Certainly, if you look over the PGP protocol suite
carefully, you see a lot that can be eliminated or radically simplified.
Here's one way to slice it:
1. Eliminate algorithm negotiation. This is something of a pet peeve for
me. Either you've got secure algorithms or you don't. At worst,
algorithm negotiation is just another potential security hole -- if the
attacker can force the choice of a known-weak algorithm, you lose.
Earlier versions of S-MIME suffered horribly from this problem (replay
attacks), and for all I know might still. Pick one public key algorithm
(RSA would be my first pick, but ElGamal has a short term intellectual
property advantage), one hash (SHA-1), and one symmetric algorithm (3DES
would be my first pick, although the AES process looks like it will pick
a winner).
2. Use the simplest possible binary data formats. PGP has lots of "hand
Huffman coding", and the ASN1-based formats are about as bad. Go, 32-bit
bigendian integers, go!
3. Key management. Key management basically doesn't work (or, at the
very least, nobody really knows whether it works or not). Just use
secure hashes of the public keys, and let people deal with 40 hex digit
strings.
The last piece is to try to figure out exactly where the plug-in piece
should go. A fair amount of software (RPM package authentication comes
to mind) uses PGP as an executable, and that seems reasonable to me.
Other software (rsync comes to mind) can communicate over an
ssh-encrypted channel. However, for some stuff, you're just going to
have to link dynamically. A dynamic library interface for CORBA services
sounds perfectly reasonable.
Of course, maybe we can just outsource all the software we need to
Mexico, India, Israel, and Iceland. Hola, namaste, boker tov, hei!
Just some thoughts.
Raph
