FW: [ale] SSH

[Chris Fowler]

Is this the way it works?

-----Original Message-----
 From: Chuck Huber 
Sent: Wednesday, December 29, 1999 10:12 AM
To: Chris Fowler
Cc: Louis Zamora
Subject: RE: [ale] SSH



> -----Original Message-----
> From: Chris Fowler 
> Sent: Wednesday, December 29, 1999 07:58
> To: Chuck Huber
> Subject: FW: [ale] SSH
> 
> 
> More information
> 
> -----Original Message-----
> From: Joe Knapka [mailto:jknapka at charter.net]
> Sent: Tuesday, December 28, 1999 7:47 PM
> To: Chris Fowler
> Cc: 'ale at ale.org'
> Subject: Re: [ale] SSH
> 
> 
> ssh-keygen generates both public and private RSA keys. As I
> understand it, the client and server exchange RSA public keys,
> and use RSA to authenticate one another and agree on a secret
> session key.

Pretty close.  I don't see a need for the client to have a public key.  It
just needs to know how to obtain the public key for the server.  I imagine
that this takes place in plain text. The protocol probably looks something
like:

Client:	Connect to server port 22.
Client:	Send in plain text "Give me your public key"
Server:	Send in plain text "Here's my public key: xyzzy.plugh"
Client:	Send in plain text "I can do Triple DES and Blowfish. What do you
want to use?"
Server:	Send in plain text "I can do DES and Triple DES.  Let's use Triple
DES."
Client:	Calculates Triple DES key.
Client:	Encrypt using server's public key: "Here's the 3DES key to use for
this session."
Client:	Sends encrypted 3DES key.
Server:	Decrypts packet using server's private key to acquire the 3DES key
sent by the client.

For the remainder of the session, the server and the client use the 3DES key
to encrypt and decrypt all traffic.  There is no longer a need for a
public/private key pair.

Why use a public/private key pair?  Because it is considered strong
encryption.  Typically, a public/private key pair will be 1024 bits long.
The down side of such security is that the encryption and decryption process
is very CPU intensive (i.e. slow) and thus not suitable for most
applications. Consider that one end might be an 8-bit CPU.

Using a symetric key like DES or 3DES is much faster, but less secure.
While some consider a 128-bit key to provide strong encryption (i.e. the
government), it falls closer to medium-strong.  The problem with using a
symetric key is 1) anyone who obtains a copy of the key can decrypt traffic
in both directions, and 2) the server and the client must somehow obtain the
same key.  This means that the server and the client (sender and recipient)
must use a secured path to communicate the key. Physically handing the key
to the recipient on diskette or paper is one way.  Sending it via postal
service or enunciating it over the phone are obviously unacceptable.

So the end solution is to use the more secure but slower asymetric
public/private encryption algorithms to communicate a less secure but faster
symetric key.  Once this has been done, all communication during the
remainder of the session uses the same symetric key.

When applied to a secured Web site, the session lasts one or two seconds at
the most.  With each new page a different symetric key is used.  This makes
it difficult for a third party to actually obtain the context of a
conversation since the context is contained in multiple sessions each
encrypted with a different key.

With something like SSH, a session could last much longer - on the order of
hours.  Considering that 128-bit encryption is not strong and could be
broken within a reasonably short period of time, it would be prudent to
establish a protocol by which the symetric key can be renegotiated in the
middle of a session.  The protocol might look something like this:

Server:	Send encrypted with the existing symetric key: "This symetric key
has expired."
Client:	Send in plain text "Give me your public key"
Server:	Send in plain text "Here's my public key"
Client:	Calculates new symetric key using same algorithm negotiated at the
beginning of the session.
Client:	Encrypt using server's public key: "Here's the 3DES key to use for
this session."
Client:	Sends encrypted 3DES key.
Server:	Decrypts packet using server's private key to acquire the 3DES key
sent by the client.

encrypted with the new symetric key.

Some folks refer to the asymetric key pair as RSA public and private keys
because RSA currently holds the patent on this technology.  The symetric key
is also known as a session key.

As long as the Department of Commerce considers 128-bit encryption to be a
munition, we'll have to consider export restrictions on this.  This is
another good reason to have production-line configuration.  Sales has been
wanting the ability to sell additional features. This would be a good one to
do.  We can ship the box with SSH disabled, and enable it with a feature-key
entered at the console by the user.  For shipments directly to customers who
want it (not via channels) we should be able to enable features on the
production line.

I hope this helps clear things up.  I also hope that your research will
prove me fairly accurate.

Enjoy,
	- Chuck
--
To unsubscribe: mail majordomo at ale.org with "unsubscribe ale" in message body.