Other Directory Sites: SeekWonder | Directory Owners Forum
The following archive was created by hippie-mail 7.98617-22 on Sat Apr 10 1999 - 01:18:04
Adam Back (aba@dcs.ex.ac.uk)
Mon, 18 Jan 1999 22:26:17 GMT
Black Unicorn writes:
> coder and cypherpunks seem to get caught up in this pattern of
> playing definition games with the regulatory bodies. This is the
> wrong approach.
>
> If it is actually used to hook crypto in, it is a crypto hook. It
> doesn't matter that this means any old generic code structure can be
> used to hook crypto in. [...]
Governments don't feel an obligation to appear rational or logical
under scrutiny -- they have power, and are doing what they feel is in
their self-interest. Their behaviour if one looks at it from the
point of view of their self-interest is perfectly rational, the
excuses they use to achieve their goals (re-defining terms (love is
hate, peace is war), re-writing history etc) are just PR exercises,
and don't need to be logical, only to be not examined closely enough
to cause sufficient public outrage to effect change.
However given all that, we have a situation where useful software is
exported without crypto functions, or with weak crypto functions built
in. Where it is possible to add crypto functions to these
applications doing so increases availability of strong crypto.
Governments then sometimes choose to add restrictions to try and cover
the software with the holes (as has happened a few times -- with
Kerebos, NCSA Mosaic if I recall).
If the hole is very general (eg pipes, sockets, source code included
and OO java implementation), however, I don't believe there has been a
precedent of amending restrictions to allow the software to be export
controlled.
My understanding of the export controls is that they have so far said
that software which includes cryptography should be hard to amend
(which implies that source code is not allowed to be distributed).
As I said I think Java is a very good generalised hole, especially
where no crypto code is included in the US created code. Where crypto
code is included the 'crypto hole' clause and not-easy to modify
clause would prevent export, at least with source code.
A good example is the use of TCP/IP Sockets to build a local proxy
adding encryption. (As Enigma does with an SMTP and POP3 proxy based
approach to adding PGP encrypt/decrypt). Enigma was written in the
UK. It can be used with basically any SMTP and POP3 based email
client.
The result has not been to ban export of email software including
ability to specify POP3 and SMTP addresses of localhost.
I think this move would be politically unattainable. My suggestion
was that working in the areas where the controls required are
politically unattainable is a fruitful way to work around export
controls.
> It reminds me of one attorney who was arguing the point that a broom
> which was used to batter someone who later died did not fit the
> definition of a deadly weapon and therefore his client should have
> one of the underlying charges (assault with a deadly weapon)
> dismissed. Court: "Counselor, if it caused death, it's a deadly
> weapon. Period."
I think there are real limits on what the government can politically
achieve in the way of increasing export controls to cover eg. any
software using TCP/IP sockets.
A harder problem to deal with is that many companies are vulnerable to
extra-legal government pressure in the form of unofficial financial
pressures (removal of government contracts). Also both companies and
individuals are vulnerable to the unofficial TLA visits (eg. RSADSIs
Bidzos' complaints that NSA personnel threatened to kill him).
Adam
The following archive was created by hippie-mail 7.98617-22 on Sat Apr 10 1999 - 01:18:04