[sldev] Cryptographic signing of UDP packets

[Thomas Shikami]

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.
I just wanna add, this method has it's own flaws that I just noticed. By 
using a unixtime it's possible to salt collision attacks, but someone 
who's sniffing packets has the abilities to just replay for example a L$ 
or inventory transaction to get as many as he can do within the time 
window. To forge replay attacks a sequence number and a backlog window 
of sequence numbers seems mandatory to forge replay attacks. As a side 
effect, we'd get rid of double messages and other nuisances then.

An additional note to encrypting packets, they add a package size 
penalty as well. As you'd need a cipher that is either driven in CBC 
mode or which is a stream cipher. Both need an initialization vector 
(IV) to initialize them for each packet, which adds an overhead of as 
much as the key size of most algorithms as well. So if you want AES-128 
encryption of packets, you'd have an additional of 128bit for the IV 
alone and this isn't helping to stop replay attacks. You could also just 
guess what packet is for a L$ transaction (due to size of the packet) 
and change some bits with a guess. If you're lucky (only needs about 
16bit or so changed) you can have any 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.