From: Anonymous <nobody@replay.com>
Date: Fri, 18 Dec 1998 13:16:19 +0800
To: cypherpunks@Algebra.COM
Subject: .....
Message-ID: <199812180438.FAA15935@replay.com>
MIME-Version: 1.0
Content-Type: text/plain



 * Intel's new chipset -> death of open source security?
 [ http://www.techweb.com/wire/story/TWB19981214S0008 ]

 * "[T]he Clinton administration announced further relaxation of U.S. export
 limits on encryption technologies."
 [ Mobile Computing and Communications (Jan. 99 issue, pp. 26+) ]

-------------------------------------------------------------------------------
Intel plans to include security features in upcoming chipsets, including copy
protection, certificate management, and -- get this -- random number
generation. This will be implemented in firmware, and, given that it is
supposed to perform copy protection functions, there is a significant
possibility that the code would be inaccessible, maybe (heaven forbid) within a
tamper-resistant shell.

Suggested response: Make negative noise about it -- of course -- and, upon the
release of the specs, write software which interoperates with it, allowing
software written to use the chips to use open-source routines. In the best
case, you would be able to correct everything but the copy protection; in the
worst case, software-inaccessible key material would be necessary to
impersonate any function of the security chips -- possibly for the stated
purpose of preventing hostile code from overriding the security functions --
and it's necessary to either get trusted keys out of the chip or patch the
chip-using software, assuming that isn't made impossible, too.

Although I have no idea how one would go about lobbying Intel to make a
software-extensible design, it would be a Good Thing if they allowed a
mechanism for software to override the chip without risking losing the security
to a virus. It could be as simple as tweaking the relevant specs so that
developers would "naturally" make a program which would use a non-Intel-trusted
software fill-in for security functions when one is available, but know that
software was being used and who has signed it. That is, the protocols not only
make it possible for software to fill in for hardware but let programs that
work with the hardware work with the software fill-ins without modification.
Wouldn't affect the (deeply misguided) copy protection features, because
software seeking copy protection could refuse to accept an answer that wasn't
authenticated as being from the trusted hardware.
-------------------------------------------------------------------------------
Pretty much self-explanatory: those opposing crypto regs present examples
demonstrating why crypto should be deregulated; the examples are deregulated
and the point is ignored. Far too many people are complacent.

A specific example: Mobile Computing and Communications (Jan. 99 issue, pp.
26+). It's an article saying that the Clinton administration has loosened
regulations and, denying those who oppose the administration's position the
fair shake given to even the most patently useless palmtop, states in the fifth
sentence that "[t]he main issues are privacy and security, and with this policy
it seems a delicate balance has been met."

The same magazine (in fact, the same author in the same issue) referenced
single-DES as "advanced encryption" with no mention of the fact that it had
repeatedly been broken or that most cryptographers agreed that use of DES was
to be avoided.

Rather than simply whine or rant about it, I suggest that at least some attempt
to respond be made. A letter to the editor may seem like a trite way to respond
to these non-crypto-savvy articles, but unless there are plans to hold
demonstrations outside the offices or just ignore it all...

[Begin sample letter to MC&C] 
A recent report in Mobile Computing and Communications applauded the Clinton
administration's loosening of cryptography when used in electronic commerce and
certain other applications. I loved the article, but it gave little attention
to what is probably, in the long term, the more important facet of
cryptography: everything else -- that is, the applications of cryptography that
are still regulated. Because intelligence agencies and some law enforcement
organizations are afraid that unregulated cryptography will lead to a
privacy-powered wave of terror, most of the vast potential of this technology
is being squandered. For example, a worldwide network of computers running
"anonymous remailer" software (which is powered by strong cryptography) could
use mathematics to provide something which lawyers and legislators have worked
to provide for hundreds of years: a virtual guarantee of freedom of speech. The
construction of such a network, though, is adversely affected by the controls
placed on the cryptographic software involved.

It's obvious that this particular application is not highly relevant to
businesses, but it's equally obvious to any professional cryptographer that
there is a myriad of other potential applications -- for companies and
individuals -- using software and hardware that is restricted by the current
set of regulations.

But the solution is not to follow the current trend, which has been to loosen
regulations where there are complaints -- first banking, then medicine and
insurance, and maybe anonymity in the future -- while tightening them in other
fields through political maneuvers such as the Wassenar Arrangement. The
solution I support, and the one supported by many others inside and outside the
field of cryptography, is to keep our fears about cryptography reined in by our
hopes for it, and to deregulate it so that this growing technology's full
potential can be realised.
[End sample letter to MC&C]
-------------------------------------------------------------------------------