Re: Encryption keys

From: William Stacey [MVP] (staceywREMOVE_at_mvps.org)
Date: 02/04/05 

Date: Fri, 4 Feb 2005 02:27:00 -0500

> True, salting the key on both ends will help, but the value that you salt
it
> with has to be easily calculated by both ends independently of one
another.

True. You could, however, just add 10 bytes (or more) of random salt and
just remove 10 bytes at the other end. This servers more as a canary and to
make it harder as it is 80 bits larger.

> Signing with the private key doesn't provide security, it provides
> non-repudiation. In other words, since the public key is public, anyone
can
> decrypt something encrypted with a public key. However, only the owner of
> the private key could have signed it (hence the name).

Agree.

> The way that SSL does it is to add one more step: the private key is used
to
> encrypt a known phrase (I believe it is the server name from the public
key
> cert plus the time stamp on the server), signed. The client decrypts with
> the private key and then verifies the signature. That way, the client
knows
> that the server knows the key and knows that only the server could have
> signed the response.

That was kinda what I was going for. The server hashes the shared key
(which is not included in the msg reply) plus all other elements included in
the reply. It then signs the digest with its' private key as normal. Now
the client can prove the server knows the same key the client sent and the
server does not have to send back the plain hash of the key. Basically this
adds a lot more data to the hash so it is not just the key itself that is
being hashed as that would expose the key to a brute force hash attack.
That said, if all the other information is contained in the response, you
could still brute force the signature because the only thing unknown is
still the key itself (as the rest is on the wire). So he gens a hash with
all the other elements plus the "key guess" and tries to verify the
signature, and keeps going with new key guesses until he finds a match.
Sending an extra long key (say 64 bytes) to begin with will mitigate against
that (because it is twice as long). Both sides will know the long key, but
use only 16 (or 32) bytes for the AES encryption. (uggg...)
Thanks for the reply Nick. Have a good weekend. 

-- 
William Stacey, MVP
http://mvp.support.microsoft.com

Relevant Pages

  • Re: Explanation of SSH
    ... I am still unclear on how SSH works exactly. ... Client issues SSH command and names server ... "Shopper" says "server sends back its public host and server keys ... Surely there is only one public key it sends ...
    (comp.security.ssh)
  • [NT] Dark Age of Camelot Man-In-The-Middle
    ... use of RSA public key cryptography and an RC4 based symmetric algorithm. ... Seeing the imminent release of code for cracking the game client (which ... At the beginning of each TCP session, the server sends a 1536 bit RSA ... void bytes_out(unsigned char *data, int len) ...
    (Securiteam)
  • Re: Debian SSH server configuration
    ... I would like to configure a Debian server to only allow clients to ssh ... I don't want any client computers to be able to ssh into ... It sounds like what you are asking for is host based authentication, ... where the server check to make sure that it has the host public key ...
    (Debian-User)
  • Re: public key vs passwd authentication?
    ... > original salt and the sequence number. ... the client might possibly want to keep a log of all server "salts" ... if any client hash value leaks that is for an iteration less than ... currently be used by a server. ...
    (comp.security.ssh)
  • Re: Basics of key authentication
    ... The public key gets copied to the server, ... and the client decrypts it with its private key to prove he is who he ... and the digital signature to the server. ...
    (comp.security.ssh)
Loading