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.
_______________________________________________
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/SLDev
Please read the policies before posting to keep unmoderated posting privileges
