[1061] in cryptography@c2.net mail archive
Arguments against mandatory GAK
daemon@ATHENA.MIT.EDU (John Kelsey)
Mon Jun 23 13:14:33 1997
To: cryptography <cryptography@c2.net>
From: John Kelsey <kelsey@plnet.net>
Date: Sun, 22 Jun 97 16:23:45 CDT
-----BEGIN PGP SIGNED MESSAGE-----
[ To: Cryptography List ## Date: 6/22/97 ##
Subject: Arguments against mandatory GAK ]
>Subject: Re: (Fwd) New crypto bill clears committee
>Cc: cryptography@c2.net
>From: Adam Shostack <adam@homeport.org>
>Date: Fri, 20 Jun 1997 07:56:25 -0400 (EDT)
>I plan to spend a substaintial portion of my day explaining to the
>large companies I consult with that this is a very bad thing, and they
>should be opposing its advance.
>I intend to take the 11 cryptographers paper as my primary tack, and
>am wondering if anyone has any other good "upper management"
type
>arguments that I should use.
1. Most managers who have ever had to deal with software
development
costs will understand this: GAK is a very complicated new feature,
whose requirements are subject to be changed by law from time to time
with little or no warning. Every software product you develop with
cryptography in it will, if GAK is required, have to have this
complicated new feature added in. This will add significantly to
development time and costs, while making the product *less* valuable
for users.
2. If there is a law requiring GAK, there will have to be enforcement
mechanisms. Most likely, this will mean applying to someone
(Commerce?)
for a crypto development licence, and then waiting for them to review
your product and decide that it's okay. I'd expect this to work just
about as well as the current export licence requests--simple things get
approval fairly quickly, but more complicated things can take much
longer--especially when the first proposal or two get rejected for some
reason. This means adding a lot of unpredictability to the time to
market.
3. Another way for the enforcement to work will be to fine companies
whose GAK mechanisms turn out to be buggy. (That is, if some GAKed
keys can't be recovered, presumably there will be fines or even jail
terms for someone--for violating the mandatory GAK laws.)
4. GAK mechanisms (that is, mechanisms for mandatory government
access) are far harder to build than generic key-recovery mechanisms
for users, because GAK mechanisms must resist users' attempts to
bypass them. GAK mechanisms will tend to make users' software less
reliable, since there is another complicated mechanism attached, and
since, if the GAK doesn't work for any reason (such as network
problems,
low storage space, etc.), the rest of the software should refuse
to work.
5. Mandatory GAK mechanisms will drive cryptography away from the
lowest end applications. (Consider a system to encrypt files with
a passphrase of mine on a palmtop. A reasonable GAK system might
require that I split the key with a 3/5 threshhold scheme, and
public-key encrypt each share, and might require that I verify that
this has been done before allowing reading or writing from/to any
encrypted file. The system is now too slow to use.) This is especially
true if there is a single, nationwide key-escrow mechanism set up,
which must work for everyone.
6. In general, software (especially networking software, and
especially security-relevant networking software) is already hard
enough to develop on a reasonable timetable and budget. Protocols,
user requirements, user hardware, operating system software, tools,
etc., change rapidly. This is a really bad place to have arbitrary,
inflexible government regulations dictating parts of your design.
7. Look at the export restrictions--virtually nobody really knows
exactly what is covered under them, and that is probably intentional
on the part of the regulators--who benefit from their ambiguity. Now,
try to imagine what the GAK regulations--drafted by and for the same
people--will look like. We won't get a clear-cut set of standards
which we can follow out of these people.
8. This is an awful precedent. What other areas of software and
communications protocol development do you suppose the Congress
will
be wanting to micromanage, once we have set the precedent with this
GAK nonsense?
In short, what GAK offers the software developer is a more expensive,
less reliable, harder-to-develop, harder-to-support product than he
would
otherwise have produced, which also has the side benefit of being less
valuable to his customer.
>Adam
- --John Kelsey, kelsey@counterpane.com
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBM62W1UHx57Ag8goBAQFvIgQAzSCUMG6DJsBa4TFcN1
D3cSK0YHU/o7+L
xpZEZbH/O3m8TLkaV95TE/5773LdTjYJpp2+geXVpVJcnuGeK2Oxk
TwKM8eaTfQh
8Rz3XgXc7/yiTiMOvHs/5KMfQiHwXcNSvwmEZwgLH1twDeyl/occkF
74xBSRc9Wm
qa7eeY98aJQ=
=LLZq
-----END PGP SIGNATURE-----
