Robin Cornelius wrote:
On Tue, Dec 16, 2008 at 3:33 PM, Tateru Nino <[email protected]> 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.
_______________________________________________
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/SLDev
Please read the policies before posting to keep unmoderated posting privileges
