[sldev] Cryptographic signing of UDP packets

Tateru Nino tateru.nino at gmail.com
Tue Dec 16 11:00:18 PST 2008


Actually, the way the current protocol is written, if you could capture
the packets off the wire, you could execute a known-plaintext attack
and... Probably determine the key in a minimum of five minutes or so,
assuming something like DES-56 and the sorts of usual data rates that we
see in the current viewer. There are a couple ways I can think of to
avoid that, but they require some slight tweaks to the format.

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.
>>     
>
> Yes of cause, each packet would have to be encrypted and decrypt-able
> with out any other packet dependencies due to the uncertain nature of
> UDP delivery.
>
> 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.
>
> Having some kind of assurance of the UDP packet source is also good
> for OGP/Hypergrid type situations as it makes sure the connection is
> authorized by at least what ever is providing the keys via caps.
>
> Robin
>
>   


More information about the SLDev mailing list