Re: [Algorithms] Message signature in token ring

[Space N. E. P. <SPA...@ho...>]

Well, I had originally thought I would need a 16 byte GUID and a 16 byte
(128 bit) public key in each message, for a total of 256 bits, but now I
realize/believe that the public key can BE the GUID, therefore a public key
of 256 bits MAY be acceptable.  I just don't know. But you can explain more
what you meant by "RSA's minimum message length is the length of the
modulus"?

I've considered that kind of direct key exchange followed by symmetric
encryption, but I would like to avoid requiring peers to directly connect to
each other. I guess though that these keys can be cached up and I would only
need to do it when I meet a totally new peer, though. So it's a possibility.
(And given the payload overhead of PGP, sounds like this route may be
inevitable.) I think it would prevent two firewalled peers from ever being
able to talk, however.

snx

----- Original Message -----
From: "Dave Moore" <dm...@od...>
To: <gda...@li...>
Sent: Tuesday, April 15, 2003 10:16 AM
Subject: Re: [Algorithms] Message signature in token ring


> 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
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=6188
>