[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Crypto software that *is* exportable from the USA



> It supports strong encryption but is exportable from
> the US because it does not have encryption compiled in by default. Instead
> it downloads the scripts it needs from South Africa when it runs for the
> first time.

This is *extremely* risky behavior. 

FTP and HTTP sites *are* compromised.  Software packages *are* 
compromised.  Look no further than "TCP Wrappers"...

A major part of the security process is having a human involved 
who knows what software was downloaded.  A human may later see
a pertinent news report and act on it; scripts will not.

A *mandatory* part of a site's security process is having a
human who has the final authority to approve the use of a package.
A human who can be held accountable, and thus is motivated to
pay attention to what's going on.  A script blows off this part 
of the process.

> South Africa has no export restrictions on cryptography. It
> supports file transfer and secure logins shells.

It can offer secure file transfers and multiple cryptographic 
checksums, and the end result is just as unacceptable.  *We must
start with the assumption that the server might be compromised.*

If the server is compromised, secure login shells and FTP won't
help.

If the server is compromised, checksums (even MD5 checksums)
won't help.

The only thing resilient to compromised servers are cryptographically 
signed cryptographic checksums.  Which requires PGP.  Which is not 
exportable.  And which requires a "chain of trust" to evaluate
whether to trust the key used to sign the checksum.

What's the answer?  Download *PGP* to verify the checksums on
that PGP file,... ?

As an aside, why would a mirror program even want strong 
encryption?  Encryption != authentication, although the implementatons
have significant overlap.

Bear Giles
bgiles@coyotesong.com


Reply to: