[sldev] Cryptographic signing of UDP packets

[Tateru Nino]

Thomas Shikami wrote:
> 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.
Wouldn't that have an extraordinarily high overhead computationally?
We're potentially talking about thousands of packets per minute. Cycles
spent generating and checking signatures can't be spent on anything
else. The cycle cost of handling SL client-server communications is
already fairly high. Is there a cheaper solution that fits the bill, or
do only computationally intensive solutions clear the cryptographic bar?

-- 
Tateru Nino
http://www.massively.com/