SUDP - encrypting UDP traffic

[Quicksilver]

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)

[Quicksilver]

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)

[Quicksilver]

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.

[Quicksilver]

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 ("<space>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!

[cologic]

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.

[andyhhp]

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

[Quicksilver]

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.

[andyhhp]

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

[Quicksilver]

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

[Quicksilver]

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