SUDP - encrypting UDP traffic

As a part for moving towards ADCS … besides ADC0 and KEYP this might be the last part needed to get everything secure.

I already did a first proposal in another thread that was a bit insecure (to easily allowing for known plaintext attacks) and did not feel that well (using token to convey encryption data/ needing Tiger as hashfunction, nameclash with ADCS[using ADC1 as signal] ). Here is now a more secure and cleaner/better proposal:


Currently UDP encryptiuon is not supported by clients so the only way to get a secure ADCS hub is to enforce searches to be passive.
This is a proposal to help with this unneeded strain to the hub. While Asymetric encryption may be optimal in sense of security.
A symmetric cipher will protect perfectly against outside adversaries given the hub-client connections is also running ADCS.
New is that senders now create a random IV for their searches and send it along the searchresult.

To signal support for this ADCS enhancements proposal clients should add “SUD0” in their SU field.

If a client signals support for SUD0 in an ADCS hub. It may extends SCH command with a KY-flag with 16-byte AES-key encoded in Base32.
RES messages over UDP to the client may then be encrypted by:
Byte 0…31 AES/ECB/PKCS5Padding encrypted 16 bytes random Initialisation Vector
Byte 32…END AES/CBC/PKCS5Padding encrypted RES packet using the IV from the first 32 Bytes.

(notation for encryption is: Cipher/Blockmode/Padding)

Little correction … Padding of the IV actually lessens security of the scheme … (and gives us 16 bytes of unneded messagesize) -> IV is now encoded in a single Block. (incremented version number to SUD1)


Currently UDP encryptiuon is not supported by clients so the only way to get a secure ADCS hub is to enforce searches to be passive.
This is a proposal to help with this unneeded strain to the hub. While Asymetric encryption may be optimal in sense of security.
A symmetric cipher will protect perfectly against outside adversaries given the hub-client connections is also running ADCS.
New is that senders now create a random IV for their searches and send it along the searchresult.

To signal support for this ADCS enhancements proposal clients should add “SUD1” in their SU field.

If a client signals support for SUD0 in an ADCS hub. It may extends SCH command with a KY-flag with 16-byte AES-key encoded in Base32.
RES messages over UDP to the client may then be encrypted by:
Byte 0…15 AES/ECB/NoPadding encrypted 16 bytes random Initialisation Vector
Byte 16…END AES/CBC/PKCS5Padding encrypted RES packet using the IV from the first 32 Bytes.

(notation for encryption is: Cipher/Blockmode/Padding)

sigh … and now lets make the scheme way simpler to implement… and faster to execute… discussing helps…

there is no actual difference to using just IV of zero bytes and put the actual IV into the first block (first 16 byte)



Currently UDP encryptiuon is not supported by clients so the only way to get a secure ADCS hub is to enforce searches to be passive.
This is a proposal to help with this unneeded strain to the hub. While Asymetric encryption may be optimal in sense of security.
A symmetric cipher will protect perfectly against outside adversaries given the hub-client connections is also running ADCS.
New is that senders now create a random IV for their searches and send it along the searchresult.

To signal support for this ADCS enhancements proposal clients should add “SUD1” in their SU field.

If a client signals support for SUD1 in an ADCS hub. It may extends SCH command with a KY-flag with 16-byte AES-key encoded in Base32.
RES messages over UDP to the client may then be encrypted by using:
AES/CBC/PKCS5Padding as Cipher/Blockmode/Padding , using 16 zero bytes for the IV. while prepending 16 random bytes (the real IV) in the first Block.
So in short : iv = 0 , cbc(16 random bytes || data || pkcs5 padding)


this is sort of equivalent to the last post thouigh should be way simpler to implement. as now there is only one cipher/mode in use.

I will try to rephrase the description above to make it better understandable.

Purpose: ADCS lacks encryption of UDP/RES traffic. To prevent leaking of information from the hub to the outside UDP either has to be switched off resulting in larger load on the hub or it has to be encrypted. SUDP proposes a simple way to encrypt UDP traffic. For this purpose a symmetric cipher is used, with the key for the cipher being distributed over the hub with the search.

How its done:
In ADCS hubs clients signal support for Secure UDP by adding SUDP in their INF to the SU list (currently SUD1 as this is just a proposal).

A client that wants to received encrypted UDP RES then can send a key for encryption by adding it Base32 encoded with a “KY” flag to its SCH command. Key is 16 Bytes in size as 128Bit AES encryption will be used. Resulting in 29 Bytes of overhead in the SCH (“KY”+26 Bytes Base32 encoded key)

A client that has results for the SCH command can now encrypt a RES messages by prepending 16 bytes of random data. and afterwards encrypting it with AES/CBC/PKCS5Padding (Cipher/Blockmode/Padding) using 16 zero bytes as iv for CBC.


Note to decryption:
The searching client in return for decryption first has tu guess which commands it receives are encrypted and which are not. It can do so for example by simply trying decryption with all currently active Keys. If a Key is wrong or the message was not encrypted, padding will fail and decryption is unsuccessful!

Note to ADC:
Its important that the key in SCH is not sent to unencrypted ADC hubs, so it can not be seen on the line!

Whilst I do not have the expertise to critique the specific choice of padding, et cetera, the overall approach seems fine and about the minimal feasible setup. The choice of AES is hard to dispute. One can mostly avoid repeat-plaintext attacks by just picking random keys. Further, ADCS is not complete without allowing for encrypted search.

This topic is of particular interest to me as I have a need to encrypt the UDP traffic and have been failing to hack the hub to force passive mode searches. (the encryption is purely to prevent protocol sniffing and the UDP traffic is the only unencrpyted traffic at the moment)

However, I do have a couple of suggestions:

Is it critical that you change the key each for each search? The random prepended data will prevent repeated message attacks. Having one key in use at any one time will reduce the workload of decrypting the messages - decryption is a computationally expensive task and your current method requires an attempt to decrypt every UDP packet (10 from each user for results) with every key you have, which can quickly lead to doing several hundred attempted decryptions if you are searching for several popular things.

I would suggest using a single key which can be advertised in the INF string. There is nothing to stop you semi-regularly rotating that key if you feel that you need to. However, it is no less secure than advertising the key to all users every time you want to search. (Also, removing the key data from SCH will decrease the hub bandwidth if you do multiple searches with the same key)

I do agree that sending the key to an unencryped hub is silly in general but I possibly have the one case where its sensible ( distributed hub - a node of which runs on the same PC as every client. The hub url is 127.0.0.1 so encryption is pointless).

Perhaps suggest that clients should ask the user if they wish to send key data across an unencrypted connection, with an option to disable the prompt if they know what they are doing. (this should probably be on a per-hub basis but there are plenty of settings which should be and arnt)

~Andrew

Sending the key accross unencrypted connection breaks the security for all searches in all hubs.
Your gain of connecting to a local hub without encryption is anyway artificial. (no computing power saved only benefit is for you it being simpler to debug connections with tools like wireshark)

So is the gain of not trying out all Keys you are currently using. How many saearches do you expect active? At the most time it will just be the most recent one (or search results will arrive for the most recent search) so you will have to try one! key… not more … in average less defiantely less than 2.
Decryption is not that computationally expensive… we might say that in theory to recify cool algortihms… and its teached in university courses… fact is… modern CPUs can easily decrypt 100 MiB/s … and you will seldomly get that much UDP traffic … even if you have to try 10 different keys … (and are not using the latest key first or some other guessing alg) even 10 MiB of Results are less than a second of CPU power.

So in practice decrypting all searchresults of a normal search is by a order of magnitude lower as the cpu time needed to for example create a bloom filter for BLOM feature.

Sending the key with searches has 2 advantages:

  1. automatically get that key refreshment: primary motivation behind that is that only people from inside the hub can read searchresults… people that vanish from the hub can’t.
  2. Less traffic … sending the key with each search costs less traffic than just once sending it with the INF (and even more if you for example send a new Key every hour) primary reason for this is that searches are due to blom filter often only sent to less than a twentieth of all participants in the hub.

Sending the key accross unencrypted connection breaks the security for all searches in all hubs.

Yes - i agree, which is why I suggested a per-hub setting.

no computing power saved

Errm? Since when is encrypting something, sending it part of the way through the network stack then decrypting it no more computationally expensive than just sending it through the network stack? The difference might be neglegable for most humans to notice but there is still a difference.

I do agree that in general, sending any form of key like this over an unencrypted connection is paramount to stupidity but as shown (and DHE is total overkill), there is a corner case where sensible/useful. (even if the common view is that its too much of a corner case and should be ignored, thats fine, as long as it is at least considered).


Fair point about the number of searches. I clearly had some mixed up thinking there. Following your reasoning, i would also agree that normally the average is less than 2. I would however suggest some guidence about how long to keep keys for. If you have a UDP packet gets corrupted somehow but not caught before getting to the client, you shouldnt go through the entire history of past keys attempting to decrypt it - you should only range over the likely used key(s). e.g. if a search an hour ago used a key, it should no longer be deemed an active key.

I would query the relevence of people vanishing from the hub. The only way they would be getting UDP packets addressed to you from another client would be if they were doing some form of MITM attack. Also, as you say, anyone on the hub will get your key to encrypt the data so this encryption is not to hide the search parameters from other hub users - its to hide the ADC protocol from observers. If an observer is not connected to the hub, using the same key for a short while is not going to relalistically increase the observers chances of decrypting the packets. Alternativly, if the observer is also listening to the hub, you have no way of hiding your key from them which means the observer will always be able to decrypt any packets they intercept (although this is useless because its not gaining the observer any information that they cant find out on their own from the hub chatter).

Less traffic … sending the key with each search costs less traffic than just once sending it with the INF

Please explain? How on earth is it less traffic to send a key with every SCH rather than to update your INF every hour (assuming you are doing more than 1 search an hour, which is a fair assumption to make imo).

~Andrew

so as I am in a bit og a hurry:

yes encryption costs computing power… but its neglectable…

Intelligent key handling … is kind of the Job of the implementation. i.e. does not have to be part of the spec.


on less traffic if added to SCH then to INF:

adding to INF -> means about n messages i.e. one for each other user… especially it adds to any client often reconnecting… further this first INF should rather be kept small and simple… as with some hubrestart having lots of INFs these are kind of problematic…


adding to SCH -> about 99% of all searches are TTH based … most of the time the searched TTH is only owned by a constant ammount of users in the hub … so may be 3 or 4 …
in the end the difference is that with adding it to SCH the search only goes to very few users but with INF to everyone… especially if you schedule a new KEY with INF every hour while in the same time the client may do only about 2 or 3 searches …

of course this traffic saving by sending it with the SCH only applies if BLOM feature is in place…

still even without BLOM it would be good not to increase the size of the initial INFs too much

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 +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

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.

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.

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.

Hello Quicksilver,

Looks reasonable to me, just wanted to know about that.

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).

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

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.

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.

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.

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.

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.

After the command.

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!

Thanks, I always use to confuse after and before, I’m sorry :frowning:

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 :frowning:.

The why don’t add a secondary port for SUDP as there is for TLS, that’d be better?

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.


Well, although we don’t use PKI, certificate signatures can be checked by other ways (for example on an HTTP server with PKI :stuck_out_tongue:), though not the integrity of this packets.


knowing my users I’d expect them to be using around 10 simultaneous searches.

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.

Try to find the attacker between 500 people :stuck_out_tongue: it may be near but you don’t know him.

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).

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 > :stuck_out_tongue:> ), 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.

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 :stuck_out_tongue:

I don’t find that as a reason to justify that, a hole will be a hole no matter there are other bigger ones.



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.

And what happens if it’s an 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.


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 hash2-1): SALT XOR Hash of key ( using the same algorithm as for CID) +
(size of hash
2)…(size of hash2+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 :frowning: )