SUDP - encrypting UDP traffic

Here is the sub forum used for talking about ideas, implementations and suggestions or typical guidelines.

Further info on extension or the protocol is found at our Wiki
andyhhp
Junior Member
Posts: 30
Joined: 18 Feb 2010, 17:44
Location: England

Re: SUDP - encrypting UDP traffic

Post by andyhhp » 23 Feb 2010, 16:07

You make some quite good points. Key handling should be left up to the clients in question.

About BLOM. I would think it wise to not make a protocol which assumes the presence of another optional feature. Either you should explicitly state that BLOM is a pre-requisite of SUDP, or designed the protocol assuming that BLOM is not present, even if the arguments for it assume BLOM.

Just as a possible alternative: have the key distribution as a feature broadcast. (using USK for Udp Security Key because i cant think of a better name at the moment, and its hard convaying this meaning an not having the commandname look like a profanity)
C -> H: FUSK <myCID> +SUDP <version?> <26bytes base32encoded data>

In the case where BLOM is not present, the feature broadcast will prevent the BINF strings getting any longer, and will prevent inflation of every BSCH command with the key data.

Having said this, it does open up the problem of a new node logging in after the key broadcast, and wishing to know the key with which to respond. This could be sorted by having a D-type key exchange which gets used if a client wants to respond to a BSCH but doesnt have the key.


Another thought which has only just come to mind. This UDP encryption should apply to all point-point UDP communication, rather than UDP/RES, as this could cover the forward compatability case (e.g. BigMuscles UDP DHT implementation) where you want ALL udp to be encrypted rather than just the RES packets

~Andrew

Quicksilver
Member
Posts: 56
Joined: 17 Aug 2009, 21:32

Re: SUDP - encrypting UDP traffic

Post by Quicksilver » 24 Feb 2010, 13:28

Thats not really working ... as any user that would join afterwards would not get the key...


If the BLOM feature is not in place SUDP will still work the same way.
Its just so that it profits from BLOM as BLOM reduces ammount of SCH sent below INF.

If you really want to spare some more traffic what you coudl do is
sending 2 SCH
like FSCH +SUDP with key
and FSCH -SUDP without key ... as as long as DC++ does not support SUDP its some traffic impact...
still its not that noticeable..
either the hub supports BLOM or its his own fault for having to handle a bit more traffic.
The feature works with BLOM present and without.. and It would be bad to add additional complexity by adding different modus operandi depending on other hubfeatures present if its not really needed.
SUDP is optimised like this for usage with BLOM and for faster joining to hubs versus less traffic without BLOM and more complexity in the clients.

klondike

Re: SUDP - encrypting UDP traffic

Post by klondike » 14 Aug 2010, 00:49

Hi,

A simple solution to the multiple key problem is adding the one-way hash of the key into the message. That way you can easily check into the client (with a simple lookup into a hash table or a trie) which is the correct key.

Now my question. As the main goal seems to be keeping the RES secure, why don't use the TOKEN as key?

Anyway to keep other UDP transfers safe you could also use a global key for other transfers (According to BASE, SCH and STA can also be sent through UDP). This may be sent by the hub to all the clients after a logout (and on login) being global for all the users or be sent by the user at login (being individual to each user). If the CID were safe then checking if a logged out user is sending the data would be trivial but as a client can spoof any CID sent to him on previous commands this won't work.

Also a thing which seems to have been forgotten is the fact that the CID was sent with U type messages but on these won't be sent. Finally it would be a good idea to be able to tell apart the encripted UDP messages from the non encrypted ones, also a integrity check is needed to avoid random messages. My suggestion would then be this:

For safe UDP packets:
0: 'S' (used to tell appart from U unencrypted messages) +
1..16: Hash of key ( key encrypted by itself using ECB) +
17..32: IV (encrypted by the key using ECB and without padding) +
32..(end-16): original U (once unencrypted it should then be decifered and parsed)+
(end-16)..end:key (which should be checked to ensure the message integrity).

From byte 32 to end the block should be padded using PKCS5Padding andinstead of ECB (which would allow block repetition and garbage addition by a third party) y suggest xoring the plaintext with the plaintext from the previous block (or the IV for the first) before encryption. Thus invalid blocks are propagated affecting the key (which is added at the end as a integrity mechanism).

This additions would only add 34 bytes to the messages but would make easy checking the integrity of the packages, being able to tell which are ciphered and which not, and allow the protocol being used with any kind of U message.

Quicksilver
Member
Posts: 56
Joined: 17 Aug 2009, 21:32

Re: SUDP - encrypting UDP traffic

Post by Quicksilver » 14 Aug 2010, 15:06

Hello klondike
Now my question. As the main goal seems to be keeping the RES secure, why don't use the TOKEN as key?

In the first version of the SUDP proposal that was done.. but we decided against that. Such multiple usage is more hackish and not good protocol design
If the CID were safe then checking if a logged out user is sending the data would be trivial but as a client can spoof any CID sent to him on previous commands this won't work.
No secure method was used to keep the protocol simple... CID/PID system is way simpler to implement than public key cryptography
I am not sure which clients support data other than RES being sent over UDP ..
Also a thing which seems to have been forgotten is the fact that the CID was sent with U type messages but on these won't be sent.
I don'T understand what you mean with that
Finally it would be a good idea to be able to tell apart the encripted UDP messages from the non encrypted ones,
No actually that would not be a good idea. Encrypted text should not be distinguishable from random data ... prefixing every Encrypted message with an "S" breaks this
also a integrity check is needed to avoid random messages.
PKCS5 padding is an integrity check for the message

1..16: Hash of key ( key encrypted by itself using ECB)
This is kind of close to a known plain text problem ... encrypting the key itself in a message encrypted with it is not a good thing to do.

(end-16)..end:key (which should be checked to ensure the message integrity).
As said PKCS5 padding does integrity check

andinstead of ECB (which would allow block repetition and garbage addition by a third party) y suggest xoring the plaintext with the plaintext from the previous block (or the IV for the first) before encryption. Thus invalid blocks are propagated affecting the key (which is added at the end as a integrity mechanism).
You basically described CBC block mode here, which is already used.


I hope this addresses all your concerns and no questions are left open. I do though currently not see any improvement by your recommendation.
One can only argue that the key encrpted in the message allows for cheaper checking if the right key is used, but trades of securty.
Though cheaper is here not really of concern as the used computing power is indeed negligible for decrypting the whole message.

klondike

Re: SUDP - encrypting UDP traffic

Post by klondike » 15 Aug 2010, 03:39

Hello Quicksilver,
Quicksilver wrote:
Now my question. As the main goal seems to be keeping the RES secure, why don't use the TOKEN as key?
In the first version of the SUDP proposal that was done.. but we decided against that. Such multiple usage is more hackish and not good protocol design
Looks reasonable to me, just wanted to know about that.
Quicksilver wrote:
If the CID were safe then checking if a logged out user is sending the data would be trivial but as a client can spoof any CID sent to him on previous commands this won't work.
No secure method was used to keep the protocol simple... CID/PID system is way simpler to implement than public key cryptography
I am not sure which clients support data other than RES being sent over UDP ..
As of now no one, though future extensions could. (In fact theorically search and status codes can be sent over UDP, though the use of UDP for searchs is not recommended).
Quicksilver wrote:
Also a thing which seems to have been forgotten is the fact that the CID was sent with U type messages but on these won't be sent.
I don'T understand what you mean with that
According to the spec any message of the UDP kind should have the CID appended before the command in the header.
Quicksilver wrote:
Finally it would be a good idea to be able to tell apart the encripted UDP messages from the non encrypted ones,
No actually that would not be a good idea. Encrypted text should not be distinguishable from random data ... prefixing every Encrypted message with an "S" breaks this
Then what about a non U? Anyway I don't see your point on non marking encrypted data as it. For the record, TLS, SSL do a part of the handshake not ciphered so any eavesdropper can tell a data channel is being opened. Also your udp packets will have some headers which make them distinguishable, so you should get the idea that any packet you send would be easily distinguishable from random data, the question is is distinguisable from other ciphered data? If you want protocol obfuscation that is enough.
Quicksilver wrote:
also a integrity check is needed to avoid random messages.
PKCS5 padding is an integrity check for the message
(end-16)..end:key (which should be checked to ensure the message integrity).
As said PKCS5 padding does integrity check
PKCS5 padding can be a weak integrity check for the message. In fact 1 out of 2^8 random messages would pass without being detected (any one whose last byte is 0x01). Adding either a hash or the own key will increase that probability to 1 out of 2^136 (or higher) which is reasonably harder.
Quicksilver wrote:
1..16: Hash of key ( key encrypted by itself using ECB)
This is kind of close to a known plain text problem ... encrypting the key itself in a message encrypted with it is not a good thing to do.
We could use some kind of hash or simply encrypt a preknown text. if I'm not proposing a real hash function here (instead of this) is because ADC seems to avoid specific hash algorithms as much as it can.
Quicksilver wrote:
andinstead of ECB (which would allow block repetition and garbage addition by a third party) y suggest xoring the plaintext with the plaintext from the previous block (or the IV for the first) before encryption. Thus invalid blocks are propagated affecting the key (which is added at the end as a integrity mechanism).
You basically described CBC block mode here, which is already used.
My fault change ECB to CBC (Just tripped there).

CBC has a basic problem which is that as it use cyphertext to cypher the next part instead of plain text I can easily add some data if I can asume some garbage. This opens the system to some replay attacks as it does with hard disks. (Here, for example, you can see in more depth what I mean http://www.off.net/~jme/loopdev_vul.html ) Anyway you have some reason on you concerns as after some reading I have seen that my mode has also some problems. The problem still remains as and eavesdropper could still modify the data being sent. Of course, this won't be necessary at all if we could use a hash function over the message and attach the result to the end (and cipher it) but that's not the case.
Quicksilver wrote:I hope this addresses all your concerns and no questions are left open. I do though currently not see any improvement by your recommendation.
One can only argue that the key encrpted in the message allows for cheaper checking if the right key is used, but trades of securty.
Though cheaper is here not really of concern as the used computing power is indeed negligible for decrypting the whole message.
I think your concept of negligible is not the same as mine.
I use the DC network on LANs with Gigaethernet links and were users, as the hubs are seasonal, do their searches on specified periods. A simple attack would be sending random large UDP packets to the address used on the search so their DC clients start consuming large amount of CPU (decripting the data) and became unresponsive. Of course, this problem would be worse, the higher the number of available keys (hence the idea of adding some hash to make the decryption faster).

Again, the problem is that in the grounds of simplicity ADC tries to avoid the usage of specific hash algorithms so you have to look for alternate solutions based on what we have (a specific encryption function).

And yes, hashes can be easily done using a encription function, but as you said they are not safe. Anyway if you don't wan't to send the key in the message here is what i suggest:
0: 'S' (used to tell appart from U unencrypted messages) +
1..16: Hash of key ( know plain text encrypted by itself using ECB, it can be always the same or it can be chosen at random during the key exchange as long as both pairs use the same) +
17..32: IV (encrypted by the key using ECB and without padding) +
32..(end-16): original UDP message (once unencrypted it should then be decifered and parsed)+
(end-16)..end:hash (as things stand my propossed hash consists on encrypting the IV using each block as key).

IV
|
AES - block1
|
AES- block2
|
etc.

Pretorian
Site Admin
Posts: 214
Joined: 21 Jul 2009, 10:21

Re: SUDP - encrypting UDP traffic

Post by Pretorian » 15 Aug 2010, 10:10

klondike wrote:According to the spec any message of the UDP kind should have the CID appended before the command in the header.
After the command.

Quicksilver
Member
Posts: 56
Joined: 17 Aug 2009, 21:32

Re: SUDP - encrypting UDP traffic

Post by Quicksilver » 15 Aug 2010, 13:01

As of now no one, though future extensions could. (In fact theorically search and status codes can be sent over UDP, though the use of UDP for searchs is not recommended).
I am not sure if many communication will go directly... mostly for security reasons direct UDP is nearly never usable.

Then what about a non U? Anyway I don't see your point on non marking encrypted data as it. For the record, TLS, SSL do a part of the handshake not ciphered so any eavesdropper can tell a data channel is being opened. Also your udp packets will have some headers which make them distinguishable, so you should get the idea that any packet you send would be easily distinguishable from random data, the question is is distinguisable from other ciphered data? If you want protocol obfuscation that is enough.
random data = body ... the header is allways the same... but this "S" will also be in the body.
PKCS5 padding can be a weak integrity check for the message. In fact 1 out of 2^8 random messages would pass without being detected (any one whose last byte is 0x01). Adding either a hash or the own key will increase that probability to 1 out of 2^136 (or higher) which is reasonably harder.
It is indeed weak ... though you also can check after decryption for the first 5 bytes... if they are something you expect..
this already gets you up to nearly 2^-48 which seems okayish..

Though you have a point pkcs5 alone is not good enough. that should be improved.

Anyway you have some reason on you concerns as after some reading I have seen that my mode has also some problems. The problem still remains as and eavesdropper could still modify the data being sent. Of course, this won't be necessary at all if we could use a hash function over the message and attach the result to the end (and cipher it) but that's not the case.
ok an attacker can insert some random data with some 2^-8 probability in our situation. but be aware. Someone able to modify data can also break our TLS security as we don't use PKI ... modifying Data/MIDM is just not in our attacker model.

I use the DC network on LANs with Gigaethernet links and were users, as the hubs are seasonal, do their searches on specified periods. A simple attack would be sending random large UDP packets to the address used on the search so their DC clients start consuming large amount of CPU (decripting the data) and became unresponsive. Of course, this problem would be worse, the higher the number of available keys (hence the idea of adding some hash to make the decryption faster).
What is large ammounts? How many keys do you expect to be active at the same time?
I really do expect only a single key to be active, or at most 2 to 3 keys.
My CPU (core2 duo) can decrypt 150 MiB/s without problems ... so with 2 -3 keys even on GBit lan ... the CPU could keep up..
Though I would really think about building in some DoS protection to solve this.. as anyone who sends you a hundred thousands of UDP packets per second wants to DoS you... and this is not just problematic with encrypted UDP.

You could also try handling it smart.. i.e. decrypting and reading ... and discarding as soon as its invalid (not finding URES) before reaching the end.
DoS especially in a LAN shouldn't be a problem... usually people DoS-ing you there are close enough to smack them for doing so.. while with only a 100MBit or smaller connection the CPU can overcome the burden of decryption. In the end its a lousy DoS ... there are better ways to crush a DC client than like this.

--------------
Thank you for your recommendations.. I am still against adding a prefix to an encrypted packet... it doesn't win us anything..
But that pkcs5 padding is not sufficient for integrity check was indeed not thought of!

klondike

Re: SUDP - encrypting UDP traffic

Post by klondike » 15 Aug 2010, 16:55

Pretorian wrote:
klondike wrote:According to the spec any message of the UDP kind should have the CID appended before the command in the header.
After the command.
Thanks, I always use to confuse after and before, I'm sorry :(
Quicksilver wrote:
As of now no one, though future extensions could. (In fact theorically search and status codes can be sent over UDP, though the use of UDP for searchs is not recommended).
I am not sure if many communication will go directly... mostly for security reasons direct UDP is nearly never usable.
Well, that depends I see a reason to send status over UDP when you don't need to grant the arrival, also I read something about multicast and ADC, that would require UDP with some additions to address the security issues, though I know multicasting + ADC hasn't been well received :(.
Quicksilver wrote:
Then what about a non U? Anyway I don't see your point on non marking encrypted data as it. For the record, TLS, SSL do a part of the handshake not ciphered so any eavesdropper can tell a data channel is being opened. Also your udp packets will have some headers which make them distinguishable, so you should get the idea that any packet you send would be easily distinguishable from random data, the question is is distinguisable from other ciphered data? If you want protocol obfuscation that is enough.
random data = body ... the header is allways the same... but this "S" will also be in the body.
The why don't add a secondary port for SUDP as there is for TLS, that'd be better?
Quicksilver wrote:
PKCS5 padding can be a weak integrity check for the message. In fact 1 out of 2^8 random messages would pass without being detected (any one whose last byte is 0x01). Adding either a hash or the own key will increase that probability to 1 out of 2^136 (or higher) which is reasonably harder.
It is indeed weak ... though you also can check after decryption for the first 5 bytes... if they are something you expect..
this already gets you up to nearly 2^-48 which seems okayish..

Though you have a point pkcs5 alone is not good enough. that should be improved.
Now I see my supidity, for sending the CID some hash function has been used, you could state in the protocol that the hash function to be used here is the same as there.

Quicksilver wrote:
Anyway you have some reason on you concerns as after some reading I have seen that my mode has also some problems. The problem still remains as and eavesdropper could still modify the data being sent. Of course, this won't be necessary at all if we could use a hash function over the message and attach the result to the end (and cipher it) but that's not the case.
ok an attacker can insert some random data with some 2^-8 probability in our situation. but be aware. Someone able to modify data can also break our TLS security as we don't use PKI ... modifying Data/MIDM is just not in our attacker model.
Well, although we don't use PKI, certificate signatures can be checked by other ways (for example on an HTTP server with PKI :P), though not the integrity of this packets.

Quicksilver wrote:
I use the DC network on LANs with Gigaethernet links and were users, as the hubs are seasonal, do their searches on specified periods. A simple attack would be sending random large UDP packets to the address used on the search so their DC clients start consuming large amount of CPU (decripting the data) and became unresponsive. Of course, this problem would be worse, the higher the number of available keys (hence the idea of adding some hash to make the decryption faster).
What is large ammounts? How many keys do you expect to be active at the same time?
I really do expect only a single key to be active, or at most 2 to 3 keys.
My CPU (core2 duo) can decrypt 150 MiB/s without problems ... so with 2 -3 keys even on GBit lan ... the CPU could keep up..
Though I would really think about building in some DoS protection to solve this.. as anyone who sends you a hundred thousands of UDP packets per second wants to DoS you... and this is not just problematic with encrypted UDP.
knowing my users I'd expect them to be using around 10 simultaneous searches.
Quicksilver wrote:You could also try handling it smart.. i.e. decrypting and reading ... and discarding as soon as its invalid (not finding URES) before reaching the end.
Anyway I don't see why not hashing the key (with the same one way hash used for the CID) And adding that hash at the beggining of the packet. On one side data will still be undistinguisable from random, on the other you gain some DOS protection against attacks targetting the probability for various keys to be used at the same time.
Quicksilver wrote:DoS especially in a LAN shouldn't be a problem... usually people DoS-ing you there are close enough to smack them for doing so.. while with only a 100MBit or smaller connection the CPU can overcome the burden of decryption. In the end its a lousy DoS ... there are better ways to crush a DC client than like this.
Try to find the attacker between 500 people :P it may be near but you don't know him.
Quicksilver wrote:Thank you for your recommendations.. I am still against adding a prefix to an encrypted packet... it doesn't win us anything..
But that pkcs5 padding is not sufficient for integrity check was indeed not thought of!
That's what this forums are for, don't you think?

At the end, my proposal would be like this.
Listen for SUDP packets on a different port (that way the client can easily tell which packets have been ciphered and which don't).And send packets with this format:
0..(size of hash-1): Hash of key ( using the same algorithm as for CID) +
(size of hash)..(size of hash+15): IV (encrypted by the key using ECB and without padding) +
(size of hash+15)..(end-size of hash-1): original UDP message using CBC (once unencrypted and checked it should then be decifered and parsed)+
(end-size of hash)..end:hash (of the whole original UDP message ).

What do you think? I think that way you get all the issues solved and you just add 48 bytes to the message (for TTH, for other hashes it can be more).

Quicksilver
Member
Posts: 56
Joined: 17 Aug 2009, 21:32

Re: SUDP - encrypting UDP traffic

Post by Quicksilver » 16 Aug 2010, 16:53

Anyway I don't see why not hashing the key (with the same one way hash used for the CID)
No win in it.. if you want this to verify the validity just checking for message starts with "URES " is sufficinet...
Before your client dies from exhaustion of decrypting its really simpler to kill it by sending that many real RES ...
if the client wants them to be diesplayed in the UI ... it will die long before the first 50 MiB of RES...

There is just no point to DoS protect a thing that is the least of your worries in case of a DoS attack ... the encryption won't be the weakest link ... not even with 10, 20 or 100 searches running in parallel.

Well, although we don't use PKI, certificate signatures can be checked by other ways (for example on an HTTP server with PKI :P), though not the integrity of this packets.
We currently have KEYP ... so we really have something in place against the tinkering for TLS. Still I don'T see the gain for a possible adversary to tinker with RES ... possibly make them unreadable.


A different Port for UDP is a possibility... though it seemed overkill...
As in contrast to TLS we can decide here much simpler what is encrypted and what is not.
With SUDP we are not relying on some higher level construct as with TLS. This means we can, without much cost distinguish between encrypted and unencrypted packets. (instead if checking the first byte for == 'S' we check the first byte for not being "U")


--
Listen for SUDP packets on a different port (that way the client can easily tell which packets have been ciphered and which don't).And send packets with this format:
0..(size of hash-1): Hash of key ( using the same algorithm as for CID) +
(size of hash)..(size of hash+15): IV (encrypted by the key using ECB and without padding) +
(size of hash+15)..(end-size of hash-1): original UDP message using CBC (once unencrypted and checked it should then be decifered and parsed)+
(end-size of hash)..end:hash (of the whole original UDP message ).
1. Prepending the key like this is bad.. because all search results would have the same start... little information leak to the outside..

2. ECB+no padding(IV) = Enc(IV)
ENC(IV) + CBC(IV,DATA) is the same as CBC(0,IV+DATA) which is already done. Just a different view of the same thing. Before we wrote it also with ECB of IV and then CBC of data using IV.. but just using one time CBC with IV=0 and usign the first bytes for the real IV then is shorter.. and if people implement it like that also simpler.

klondike

Re: SUDP - encrypting UDP traffic

Post by klondike » 16 Aug 2010, 18:54

Quicksilver wrote:
Anyway I don't see why not hashing the key (with the same one way hash used for the CID)
No win in it.. if you want this to verify the validity just checking for message starts with "URES " is sufficinet...
Before your client dies from exhaustion of decrypting its really simpler to kill it by sending that many real RES ...
if the client wants them to be diesplayed in the UI ... it will die long before the first 50 MiB of RES...
Though a client could start dropping results coming from a CID which already sent some, the number of CIDs in the hubs is limited and the amount of result to be displayed can be limited to 10 per client as recommended by the protocol. So checks can be done to avoid this kind of attack :P
Quicksilver wrote:There is just no point to DoS protect a thing that is the least of your worries in case of a DoS attack ... the encryption won't be the weakest link ... not even with 10, 20 or 100 searches running in parallel.
I don't find that as a reason to justify that, a hole will be a hole no matter there are other bigger ones.


Quicksilver wrote:
Well, although we don't use PKI, certificate signatures can be checked by other ways (for example on an HTTP server with PKI :P), though not the integrity of this packets.
We currently have KEYP ... so we really have something in place against the tinkering for TLS. Still I don'T see the gain for a possible adversary to tinker with RES ... possibly make them unreadable.
The problem is that you are thinking only in RES when SUDP should cover any UDP message used with ADC. Anyway, the fact you don't see a potential win in thinkering with RES or other UDP messages doesn't mean there can't be one, you simply don't know it yet.
Quicksilver wrote:A different Port for UDP is a possibility... though it seemed overkill...
As in contrast to TLS we can decide here much simpler what is encrypted and what is not.
With SUDP we are not relying on some higher level construct as with TLS. This means we can, without much cost distinguish between encrypted and unencrypted packets. (instead if checking the first byte for == 'S' we check the first byte for not being "U")
And what happens if it's an U?

Quicksilver wrote:
Listen for SUDP packets on a different port (that way the client can easily tell which packets have been ciphered and which don't).And send packets with this format:
0..(size of hash-1): Hash of key ( using the same algorithm as for CID) +
(size of hash)..(size of hash+15): IV (encrypted by the key using ECB and without padding) +
(size of hash+15)..(end-size of hash-1): original UDP message using CBC (once unencrypted and checked it should then be decifered and parsed)+
(end-size of hash)..end:hash (of the whole original UDP message ).
1. Prepending the key like this is bad.. because all search results would have the same start... little information leak to the outside..
Hum, that can be easily solved using a random SALT and xoring it with the key hash. This would also ensure no packet can be confuse as we can use a random SALT except those beggining with U.

Quicksilver wrote:2. ECB+no padding(IV) = Enc(IV)
ENC(IV) + CBC(IV,DATA) is the same as CBC(0,IV+DATA) which is already done. Just a different view of the same thing. Before we wrote it also with ECB of IV and then CBC of data using IV.. but just using one time CBC with IV=0 and usign the first bytes for the real IV then is shorter.. and if people implement it like that also simpler.
True, I didn't think on it. Anyway to add the hash it'd be CBC(0,IV+DATA+hash(DATA)).

0..(size of hash-1): SALT (Random and not beggining with U) +
(size of hash)..(size of hash*2-1): SALT XOR Hash of key ( using the same algorithm as for CID) +
(size of hash*2)..(size of hash*2+15): IV (encrypted by the key using ECB and without padding) +
(size of hash*2+16)..(end): original UDP message concat hash of the message using CBC (once unencrypted and checked it should then be decifered and parsed)

(On the previous description I forgot to encrypt the hash too :( )

Locked