[sldev] Cryptographic signing of UDP packets
Thomas Shikami
thomas.shikami at online.de
Tue Dec 16 23:50:11 PST 2008
Robin Cornelius wrote:
> On Tue, Dec 16, 2008 at 3:33 PM, Tateru Nino <tateru.nino at gmail.com> wrote:
>
>> The current protocol would mean that you couldn't rely on any cipher
>> block-chaining, mind. The packets can arrive out of order, and it is not
>> critical if some are missed, as currently specified - but the overhead
>> for a simple symmetrical cipher with a periodic key-exchange would be
>> quite low.
...
> I quite like Argent's suggestion of encrypting the whole packet as
> this would not increase bandwidth as a signature would and you get
> small increase in privacy as a side effect, unable to sniff UDP
> packets without knowing the current key, so for debugging purposes you
> could still use SLproxy if it was able to cache the keys retrieved by
> caps and do the decode on the UDP and I guess for wider spread test
> systems eg OpenSims etc could could always rig a know decode key if
> you needed to sniff packets from multiple systems.
>
Encrypting packets without signature is a common mistake done with
cryptography, it still allows changing packets and it would go unnoticed
as a signature is missing. A signature is mandatory for authenticating
packets. If you are going to sign UDP packets, please don't create
another home brewn crypto thing like those easy to crack simple MD5 sums
over double-colon separated string, but instead use a real keyed hash. I
recommend using HMAC-MD5 as it gives a 128bit signature and UDP packets
and connections are short living anyways, so as finding collisions for
MD5 still takes very long, it gives an average protection. To reduce the
overhead, this hash may be reduced to 64bit and is still secure against
quick injection. The hash key can be the secure session id and each
packet could have a unixtime added as a nonce, so there would be a small
time window in where packets are valid. This might give an overhead of
like 96bit or 12 additional bytes. And most probably only packets
involving modifying permissions, taking, deleting, L$ transfers, IMs and
everything else low frequent can be armored by it.
More information about the SLDev
mailing list