FBI calls for mandatory key escrow; Denning on export ctrls

Thu Sep 4 15:17:24 UTC 1997

On Thu, 4 Sep 1997, Selina F. Priestley wrote:

> Let's turn this into a useful conversation:  If we do not believe that getting
> a backdoor to our keys is a useful way to insure security on the network, maybe
> isn't even addressing the root issues, then
> 
> What *are* the real issues with security on the network?  How should we work to 
> address these issues, both at the network and application layers?  How will this
> solve the 'child porn problem'?  What are the barriers involved in any proposed 
> solutions?

The real issues with security on my network have little to nothing to do
with Key Escrow.  Key Escrow is just a way for certain government agencies
to feel they are less threatened by strong encryption schemes.  Little to
nothing to do with network security (which kind of makes it off topic on
this mailing list), and everything to do with personal security and
privacy of my data.

So, to put it on topic...

SSH is an encrypted login facility that can use several different
encryption schemes, and generates keys on the fly (a 1024 big RSA key, and
a 768 bit RSA key for the server which are regenerated hourly, and then a
256 bit random session key), and provides a fairly secure way of transport
data over tcp/ip in a secure manner.  The details are below, and are
quoted from the F-Secure home page.

[Begin quote]
The server sends its public RSA host key and another public RSA key
"server key'' that changes every hour. The client compares the received
host key against its own database of known host keys. 

FSecure SSH Server will normally accept the key of an unknown host and
store it in its database for future reference (this makes use of SSH
practical in most environments). However, FSecure SSH Server can also be
configured to refuse access to any hosts whose key is not known. 

The client generates a 256 bit random number using a cryptographically
strong random number generator, and chooses an encryption algorithm from
those supported by the server, normally IDEA or three-key 3DES. The client
encrypts the random number (session key) with RSA using both the host key
and the server key, and sends the encrypted key to the server. 

The purpose of the host key is to bind the connection to the desired
server host (only the server can decrypt the encrypted session key). The
hourly changed second key, the server key, is used to make decrypting
recorded historic traffic impossible in the event that the host key
becomes compromised. The host key is normally a 1024 bit RSA key, and the
server key is 768 bits. Both keys are generated using a cryptographically
strong random number generator. 

The server decrypts the RSA encryption and recovers the session key. Both
parties start using the session key and the connection is now encrypted.
The server sends an encrypted confirmation to the client. Receipt of the
confirmation tells the client that the server was able to decrypt the key,
and thus holds the proper private keys. 

At this point, the server machine has been authenticated, and 
transport-level encryption and integrity protection are in use. 
[End quote from web page]

With that being said, when it regenerates these keys, how do I transport
them to the key escrow service?  I could do it in a way similar to the way
SSH works, but what's to stop a middle man attack from posing as the
keyserver?  Thanks but no thanks.  It just adds another point of
insecurity.

> How can we trace criminals/spam artists/hackers easily and hand them over to
> the feds w/o handing over our rights as well?  

By not allowing them to take away our encryption options.  You can't
selectively give and take away rights.  BTW, hackers aren't criminals...
Crackers are.  And, as someone who considers himself a hacker, I take
offense to the implication.

> If we don't have any answers to these questions, and plans for getting there,
> then we might as well quit our bitching.

I think the beauty of the situation is that they are using kiddy porn and
terrorism as a means to justify outlawing strong cryptography or to
encourage key escrow.  What I don't think they understand, is that if
someone doing something bad doesn't want to give in to key escrow, they
won't.  Not to mention the fact that there are cryptographicly strong
encryption methods available outside the US (most crypto people in the 
US have either moved out of the country or are thinking seriously about
it), and they rival American products.  So, the belief that we lead the
world in strong crypto production is not only egotistical, but absurd.
And I find it hard to believe that anyone who feels comfortable with
blowing up a building/plane/anything and taking innocent lives in the name
of some cause or religion would give a rat's behind about conforming to
the laws of any country in regards to strong encryption.  It's just
another risk to them if they get caught, and if they were that concerned
with getting caught, I'd think they wouldn't take such actions.  

Terrorism and kiddy porn hopefully have very little to do with my network.
Security has everything to do with my network, and I find most law
enforcement agencies to be abusive in their power, so why would I trust
them with part/all of my private key?  To be honest, I don't trust them.

And the real point is, until they can present an argument to me that shows
why I should trust Big Brother with my encryption keys, I'll keep them to
myself.  

> Selina

Joe Shaw - jshaw at insync.net
NetAdmin - Insync Internet Services
My words are mine, not my employer's.