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.
Argent Stonecutter wrote: > On 2008-12-16, at 05:35, Robin Cornelius wrote: >> Is this going to be ALL UDP packets or just certain ones that are >> certainly more sensitive than others? Not applying to all still leaves >> a potential attack point but wastes bandwidth. This is also related to >> the size of the signature. If the signature is too small a brute force >> attack may be possible by just trying combinations of packets and >> getting a reply from the server, too large a signature and we have >> massive UDP packets so more bandwidth and lag? > > If you instead encrypt the UDP packets you won't need to add a > signature to the packet itself, you can just encrypt the packet with a > key passed through HTTPS CAPS at login. The computational overhead > should be similar for encryption or signing at equivalent levels of > security, and encryption would add privacy. > > Since you have a secure channel via HTTPS, you don't need to use a > separate key exchange protocol, and you don't need the computational > overhead of private keys. > > In fact just periodically exchanging a UUID over HTTPS to use in some > fast short-period encryption technique would probably be enough. Don't > serialize the packets, just keep updating the key. > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/SLDev Please read the policies before posting to keep unmoderated posting privileges
