[MUD-Dev] TECH: Securing Symetric Encryption.

[T. Alexander Popiel]

William Leader <leader at k2wrpg.org> wrote:

> I was brainstorming about this and I was hoping someone could
> check my logic. I want to be able to secure the connection between
> a client and server using encryption.

Reasonable.

> Now from a technical perspective I know that an Asymetric system
> is best because you don't have to worry about sending keys over
> the network in plain text

There's symmetric systems that don't require keys in plan text on
the wire, too.  What the asymmetric systems give you that symmetric
systems do not is intrinsic authentication without a shared secret.
Since your (uniform) client is going to be in the hands of the
enemy, nothing you share is going to be secret.

> but lets assume for the discussion that Asymetric encryption is
> not an option (mainly because I don't want the hassle of managing
> key pairs).

I'd suggest that you _do_ want asymmetric encryption to prevent
man-in-the-middle attacks.  For that, you'd only need a single
key-pair: the pair that authenticates your server.  It would then be
up to the client to detect a man-in-the-middle attack and abort, but
since you have no prior _secret_ knowledge shared with the client
(you already pointed out the vulnerability of the shared password
communicated through insecure means), that's the best you can do.

> My first thought was lets only encrypt messages that have
> sensitive data like login messages that contain the password.

Reasonable.  This reduces the amount of crypt-text available to
analyze in a session.

[snip]

> What I needed was a way to make the login message different every
> time. The following is what I came up with and I hope to get help
> on.

[snip]

What you propose is still vulnerable to eavesdropper attacks,
because the randomness is only injected from one side.  As a first
step to avoid that, look up 'Diffie-Hellman Key Exchange'.  This
involves each side randomly coming up with half of a key,
communicating derived values from those, and then merging to yield a
shared secret key.  Unfortunately, since D-H is anonymous, it is
still vulnerable to man-in-the-middle attack.  To prevent that, then
have the server sign the generated key with your (single) asymmetric
private key, send that over the wire, and the client can verify
(with the public key) that the sender-signed D-H key is the same one
that the client is using for the session.

Having established a connection that is sniff-proof and known to
connect the server and something, you can then use whatever means
you like to authenticate the client (be it password or something
else).

> Any encryption experts out there willing to point out a weakness
> that I don't already know about or comment on the severity of the
> weaknesses I do know about?

I'm far from an expert, but the main weakness you had was randomness
inserted from only one side.  Unfortunately, that is enough to pull
down the entire house.

Wikipedia (http://en.wikipedia.org/wiki/Key_agreement) is useful for
finding the names of what exists, though it generally doesn't
provide algorithm specifics.

- Alex
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://kanga.nu/lists/listinfo/mud-dev