SUDP - encrypting UDP traffic
-
- Junior Member
- Posts: 30
- Joined: 18 Feb 2010, 17:44
- Location: England
Re: SUDP - encrypting UDP traffic
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
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
-
- Member
- Posts: 56
- Joined: 17 Aug 2009, 21:32
Re: SUDP - encrypting UDP traffic
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.
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.
Re: SUDP - encrypting UDP traffic
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.
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.
-
- Member
- Posts: 56
- Joined: 17 Aug 2009, 21:32
Re: SUDP - encrypting UDP traffic
Hello klondike
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
I am not sure which clients support data other than RES being sent over UDP ..
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.
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
No secure method was used to keep the protocol simple... CID/PID system is way simpler to implement than public key cryptographyIf 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.
I am not sure which clients support data other than RES being sent over UDP ..
I don'T understand what you mean with thatAlso 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.
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 thisFinally it would be a good idea to be able to tell apart the encripted UDP messages from the non encrypted ones,
PKCS5 padding is an integrity check for the messagealso a integrity check is needed to avoid random messages.
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.1..16: Hash of key ( key encrypted by itself using ECB)
As said PKCS5 padding does integrity check(end-16)..end:key (which should be checked to ensure the message integrity).
You basically described CBC block mode here, which is already used.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).
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.
Re: SUDP - encrypting UDP traffic
Hello Quicksilver,
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.
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.
Looks reasonable to me, just wanted to know about that.Quicksilver wrote: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 designNow my question. As the main goal seems to be keeping the RES secure, why don't use the TOKEN as key?
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:No secure method was used to keep the protocol simple... CID/PID system is way simpler to implement than public key cryptographyIf 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.
I am not sure which clients support data other than RES being sent over UDP ..
According to the spec any message of the UDP kind should have the CID appended before the command in the header.Quicksilver wrote:I don'T understand what you mean with thatAlso 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.
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: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 thisFinally it would be a good idea to be able to tell apart the encripted UDP messages from the non encrypted ones,
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:PKCS5 padding is an integrity check for the messagealso a integrity check is needed to avoid random messages.
As said PKCS5 padding does integrity check(end-16)..end:key (which should be checked to ensure the message integrity).
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: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.1..16: Hash of key ( key encrypted by itself using ECB)
My fault change ECB to CBC (Just tripped there).Quicksilver wrote:You basically described CBC block mode here, which is already used.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).
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.
I think your concept of negligible is not the same as mine.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 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.
-
- Site Admin
- Posts: 214
- Joined: 21 Jul 2009, 10:21
Re: SUDP - encrypting UDP traffic
After the command.klondike wrote:According to the spec any message of the UDP kind should have the CID appended before the command in the header.
-
- Member
- Posts: 56
- Joined: 17 Aug 2009, 21:32
Re: SUDP - encrypting UDP traffic
I am not sure if many communication will go directly... mostly for security reasons direct UDP is nearly never usable.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).
random data = body ... the header is allways the same... but this "S" will also be in the body.
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.
It is indeed weak ... though you also can check after decryption for the first 5 bytes... if they are something you expect..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.
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.
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.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.
What is large ammounts? How many keys do you expect to be active at the same time?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).
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!
Re: SUDP - encrypting UDP traffic
Thanks, I always use to confuse after and before, I'm sorryPretorian wrote:After the command.klondike wrote:According to the spec any message of the UDP kind should have the CID appended before the command in the header.
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:I am not sure if many communication will go directly... mostly for security reasons direct UDP is nearly never usable.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).
The why don't add a secondary port for SUDP as there is for TLS, that'd be better?Quicksilver wrote:random data = body ... the header is allways the same... but this "S" will also be in the body.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.
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:It is indeed weak ... though you also can check after decryption for the first 5 bytes... if they are something you expect..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.
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.
Well, although we don't use PKI, certificate signatures can be checked by other ways (for example on an HTTP server with PKI ), though not the integrity of this packets.Quicksilver wrote: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.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.
knowing my users I'd expect them to be using around 10 simultaneous searches.Quicksilver wrote:What is large ammounts? How many keys do you expect to be active at the same time?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).
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.
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: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.
Try to find the attacker between 500 people it may be near but you don't know him.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.
That's what this forums are for, don't you think?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!
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).
-
- Member
- Posts: 56
- Joined: 17 Aug 2009, 21:32
Re: SUDP - encrypting UDP traffic
No win in it.. if you want this to verify the validity just checking for message starts with "URES " is sufficinet...Anyway I don't see why not hashing the key (with the same one way hash used for the CID)
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.
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.Well, although we don't use PKI, certificate signatures can be checked by other ways (for example on an HTTP server with PKI ), though not the integrity of this packets.
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")
--
1. Prepending the key like this is bad.. because all search results would have the same start... little information leak to the outside..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 ).
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.
Re: SUDP - encrypting UDP traffic
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 attackQuicksilver wrote:No win in it.. if you want this to verify the validity just checking for message starts with "URES " is sufficinet...Anyway I don't see why not hashing the key (with the same one way hash used for the CID)
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...
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: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.
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: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.Well, although we don't use PKI, certificate signatures can be checked by other ways (for example on an HTTP server with PKI ), though not the integrity of this packets.
And what happens if it's an U?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")
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:1. Prepending the key like this is bad.. because all search results would have the same start... little information leak to the outside..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 ).
True, I didn't think on it. Anyway to add the hash it'd be CBC(0,IV+DATA+hash(DATA)).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.
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 )