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
participants (4)
-
Darrell Perko -
fc＠all.net -
Jim Gillogly -
Perry E. Metzger