[sldev] Cryptographic signing of UDP packets

[Robin Cornelius]

On Thu, Dec 18, 2008 at 8:49 AM, Thomas Shikami
<thomas.shikami at online.de> wrote:
> Thomas Shikami wrote:
>>
>> 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.
>

For low frequency and high risk packets such as pay or even an
inventory transaction surely the answer must be put it on https caps,
that immediately solves those issues then for those we can also use a
reliable transport system TCP, although i believe those packets do use
the "reliable" UDP handshake so that the viewer/serker ack's packets
to confirm receipt and could resend if lost.

> other arbitrary but high amount payed to you. This is another reason, that
> we need signatures for each packet and encryption alone isn't helping. For
> the reader who doesn't believe. There is enough on wikipedia already giving
> valid information about encryption and what all can go wrong.

Well the original goal of this, from what i understand, is
authentication not encryption. Its the authentication that is most
important here to ensure that a packet came from a given viewer or
server and is not an injected or modified packet.

Robin