I need exportable crypto revisited.

Greetings;

	Thank you all for your amazingly quick responses!  However, I
should have noted in my original message that this encryption is to meet
a contractual point for a commercial product to be delivered soon.  The
product can have one and one only version to be boxed and shipped and
will be sold internationally.  The encryption portion will be dynamically
linked, so real encryption will be available on the net just not in the box.

	Thanks,
	Darrell Perko
	dperko@efn.org

Darrell Perko writes:
> 	Thank you all for your amazingly quick responses!  However, I
> should have noted in my original message that this encryption is to meet
> a contractual point for a commercial product to be delivered soon.  The
> product can have one and one only version to be boxed and shipped and
> will be sold internationally.  The encryption portion will be dynamically
> linked, so real encryption will be available on the net just not in the box.

If you have hooks for arbitrary encryption, you will find it to be
virtually impossible to export the product.

The only way to do this whole thing is to export the product to an
offshore development site without the crypto, have the crypto added,
and import the software into the US, never export it from the US. You
have no other real choice.

Welcome to hell. If you don't like it, complain to the NSA, and to the
Clinton administration, experts in being buggered by the NSA and
buggering us too.

Perry

> "Perry E. Metzger" <perry@piermont.com> writes:
> If you have hooks for arbitrary encryption, you will find it to be
> virtually impossible to export the product.

That's my understanding also (as I told him in e-mail) but I haven't found
any legal justification for it.  I spent a while poring over the ITARs,
section XIII.b (ftp://ftp.cygnus.com/pub/export/itar.in.full), and I
didn't see anything that looked likely.  Maybe "ancillary equipment" in
XIII.b.5, but that seems a stretch and is not at all specific.

I note that hash algorithms for message authentication are specifically
excluded from control in XIII.b.1.vi, which conflicts with what I was told
by somebody who'd gotten a nastygram from Commerce.  Sort of a relief,
since I've been giving my SHA implementation away freely
(rand.org:pub/jim/sha.tar.gz).

Has anybody who's been impaled on the stinky end of this stick been told the
chapter and verse?

	Jim Gillogly
	Sterday, 26 Wedmath S.R. 1995, 00:21

> 
> 
> > "Perry E. Metzger" <perry@piermont.com> writes:
> > If you have hooks for arbitrary encryption, you will find it to be
> > virtually impossible to export the product.

...

> Has anybody who's been impaled on the stinky end of this stick been told the
> chapter and verse?

I had the experience about 5 years ago - it's not really a big deal.

I submitted a product (Integrity Toolkit - still detecting and limiting
the spread of all current viruses after 5+ years of not being updated)
for release in source form to my European distributors (who are now the
sole global source - I got out of that business).  In order to assure
that it could detect alteration (as part of its integrity shell), it
used a pretty strong cryptographic checksum - actually a message digest
that's faster than MD5 on a PC architecture, combined with an RSA system
I implemented in MuLisp (pretty fast long arithmetic for a high-level
language implementation).

To add fuel to the fire, the system came with an encryption capability
that included the ability to use an external encryption scheme of the
user's own design.  It even included source for a simplistic encryption
program that could be replaced with real encryption by simply adding the
code for the real encryption into the C source provided, recompiling,
and running.

I submitted it to state who sent it to the NSA who called me a few
weeks later (pretty fast by government standards to be honest) and
asked me some questions.  I answered as honestly as I could ...

***	The RSA was built into the system and, although it could be
extracted and used for encryption, as shipped, it was only used for
authentication.  It literally throws away one of the keys during key
generation so that it is truly a one-way trap door.  It would take a
substantial effort by a knowledgeable programmer to convert it into a
workable RSA for encrypting large files, and as implemented, it is only
good for authentication.

***	The inbuilt encryption schemes are relatively easily broken and
are designed only to prevent automated attack by viruses that try to forge
checksums and other such things.

***	The message digest facility is pretty good, but it can only be
used for the authentication process, so it is useless as an encryption
system.

***	The external encryption hook includes no worthwhile encryption
scheme, but it can easily be converted for this use if you have your own
encryption technology.

They responded that as far as they were concerned, I could go ahead and
ship it oversees, sent me a letter to that effect (which I have in the
files somewhere just in case), and off it went.  All further development
of the encryption side was done oversees from that point forward to keep
me from having to go through ITAR again.

-- 
-> See: Info-Sec Heaven at URL http://all.net
Management Analytics - 216-686-0090 - PO Box 1480, Hudson, OH 44236