Re: 40bit Encryption : Adequate or sadly lacking ?

In article <3fh5m0$7tg@hdxu03.telecom.ptt.nl>, you write:
> In article <marca-1201952123120001@boulanger.mcom.com>, marca@mcom.com 
> says...
> >
> >There's no question that 40-bit is less than one would prefer.
> >This is why we are/will be supporting 128-bit RC4, for example,
> >in US-only products, honoring United States government export
> >restrictions.
> 
> Marc, isn't it possible (legally) to deliver products with a replaceble 
> encryption library (dll). Delivery with a 40-bit key DLL. The user has 
> the option to install a dll with a different keysize. Somewhat like 
> winsock...
> 
> Yes, I've seen the article suggesting a foreign office. I think an open 
> interface would do gooed for the whole field. I.e. ftp, telnet, etc. as 
> well.

Actually, it's probably worse than you think:

There are govt's out there that won't let you import code that is
"encryption ready". You must prove that your software is tamper proof
before it can be imported, and tamper proofing means that you can't
bolt on security. Also, I believe the export laws disallow "plug in"
security in the US...

The crypto legal world sucks.

>> Marc, isn't it possible (legally) to deliver products with a replaceble 
>> encryption library (dll). Delivery with a 40-bit key DLL. The user has 
>> the option to install a dll with a different keysize. Somewhat like 
>> winsock....
>
>
>Actually, it's probably worse than you think:
>
>There are govt's out there that won't let you import code that is
>"encryption ready". You must prove that your software is tamper proof
>before it can be imported, and tamper proofing means that you can't
>bolt on security. Also, I believe the export laws disallow "plug in"
>security in the US...
>
>The crypto legal world sucks.

Could you clarify the export restriction on "plug and play" encryption ready
products?  I am about to embark on a project that I want to be distributed
freely that would be designed around a generic encryption intereface that I
would wrap around a real encryption core such as PGP,etc.  I wanted to include a
BS encryption in the freely distributable package to prevent export woes.  The
project is in design stages now and I don't need this additional headache.

djw

-------------------------------------------------------------
Duncan J Watson                                    djw@io.com
"Sig Quote goes here"                              duncan@hasp.com

On Jan 18,  7:21am, Duncan wrote:
> Subject: Re: 40bit Encryption : Adequate or sadly lacking ?
>
> >> Marc, isn't it possible (legally) to deliver products with a replaceble
> >> encryption library (dll). Delivery with a 40-bit key DLL. The user has
> >> the option to install a dll with a different keysize. Somewhat like
> >> winsock....
> >
> >
> >Actually, it's probably worse than you think:
> >
> >There are govt's out there that won't let you import code that is
> >"encryption ready". You must prove that your software is tamper proof
> >before it can be imported, and tamper proofing means that you can't
> >bolt on security. Also, I believe the export laws disallow "plug in"
> >security in the US...
> >
> >The crypto legal world sucks.
>
> Could you clarify the export restriction on "plug and play" encryption ready
> products?  I am about to embark on a project that I want to be distributed
> freely that would be designed around a generic encryption intereface that I
> would wrap around a real encryption core such as PGP,etc.  I wanted to
include a
> BS encryption in the freely distributable package to prevent export woes.
 The
> project is in design stages now and I don't need this additional headache.

Contact a lawyer. It's *really* complicated, and I'm not a lawyer so anything I
tell you could be wrong in some important way, and then you would get really
angry if the govt started chewing you to pieces.


-- 
---------------------------------------------------------------------
Kipp E.B. Hickman          Netscape Communications Corp.
kipp@mcom.com              http://home.mcom.com/people/kipp/index.html

> There are govt's out there that won't let you import code that is
> "encryption ready". You must prove that your software is tamper proof
> before it can be imported, and tamper proofing means that you can't
> bolt on security. Also, I believe the export laws disallow "plug in"
> security in the US...

Central point software faced this problem.

So they made the encryption features of their product a free
add on, and posted it on bulleting boards with instructions
not to download unless you were an American citizen.

Needless to say these instructions were ignored, surprise 
surprise.

Of course this strategy only works if your product is
useful without encryption, and the add on is of limited
use without your product.

I believe that Kevin Welch decided on this strategy.

 ---------------------------------------------------------------------
We have the right to defend ourselves and our       
property, because of the kind of animals that we  
are.  True law derives from this right, not from    James A. Donald
the arbitrary power of the omnipotent state.        jamesd@netcom.com

               http://www.catalog.com/jamesd/