Re: [Algorithms] Message signature in token ring

[Dave M. <dm...@od...>]

Tom Forsyth wrote:
> 
> >Does such an encryption algorithm ("encrypt with private key, decrypt
> > with public key") exist?
> > [...]
> > If it involves sending some kind of key/signature in every message, it would
> > be nice to keep that <= 128 bits. The protection doesn't have to be super
> > strong, since there is no incentive to crack, other than creating mischief.
> 
> Certainly - PGP for example. But they're very slow.

  Not too mention that there's not a one that meets his requirements for
< 128 bits of overhead.  RSA's minimum message length is the length of
the modulus, which, given that we're doing games on this list rather
than sending state secrets could be in the 256-384 bit range, but this
is still a lot of overhead to go through.  (El Gamal's message length is
2x the modulus, which is even worse.)

> Best way to do this is to securely (e.g. with public/private key stuff) send
> a client ID to each client at start of day - just a fairly big random
[...]
> The server recieves the message, appends the client's key, hashes it, and
> checks the hashes agree.
> Another user can't spoof because they don't know the key, and so can't
> generate a valid hash.

  He specified peer connections here though, so I don't think this one
is appropriate.  (Though it's definitely plenty secure for cli/ser
games.)  Probably the best thing to try in this situation is have the
client, using Diffie-Hellman or another key exchange protocol, negotiate
keys with every other peer in the ring.  DH is fairly straightforward,
and has been unencumbered by patents in the US for several years now. 
  Negotiate a 56-bit DES key, and either encrypt your payload (0 space
overhead, higher CPU overhead), or encrypt a hash at the end (small
space overhead, small CPU overhead).  DES works on 64 bit blocks, so
appending an encrypted hash is pretty low overhead.  It's not totally
secure, but it'll do for a game.

> But really, you need a proper crypto book - this has all been solved before,
> with a lot more rigour.

  Amen.  I highly recommend Bruce Schneier's "Applied Cryptography" if
you're really interested.

				...dave