[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