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
Quicksilver
Member
Posts: 56
Joined: 17 Aug 2009, 21:32

Re: SUDP - encrypting UDP traffic

Post by Quicksilver » 17 Aug 2010, 22:24

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
Nothing hinders you to discard packets if there are more than x times ammount of users in the hub.

I don't find that as a reason to justify that, a hole will be a hole no matter there are other bigger ones.
Its a matter of the weakest link ... There is no point in putting an additional defense mechanism against DoS caused by garbled RES in if valid RES are more dangerous for DoS and defense mechanism for them should also work for the garbled version.

The problem is that you are thinking only in RES when SUDP should cover any UDP message used with ADC.
And you can check the first 5 letters for all commands you are willing to handle ... it doesn't matter if you support 1 or x commands.

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.
Indeed yet I don't see that tinkering succeed. The attack you linked just won't work here. To short command.. to few possibilities to copy ... and no matter what you do, you will only create an invalid RES that can be discarded.

But that all doesn't matter what you can reach by tinkering, as anything you could reach by tinkering with the UDP packet could have just been sent from the start directly by yourself...
so no .. there is no point in preventing tinkering as long as we don't start signing the packets. Though signing was decided against for simplicity, so there is no point in a hash for integrity.

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

Re: SUDP - encrypting UDP traffic

Post by Pretorian » 15 Oct 2010, 22:22

The following is what I've been able to gather from this thread.

Three items;
  • I have written the text to be encrypting any UDP message and not only RES. At time of writing, yes, it is not very likely to get any other type of message. However, I think this approach is the best, for forward compatibility. The example text is using with SCH and RES, though.
  • The text currently specifies PKCS5 padding, yet it was claimed this was bad. Please come up with an alternative text or padding algorithm (or whatever the term is). Edit: This appears to be only a problem in particular circumstances and not in general case. Will continue to use PKCS5 in the future.
  • The text state specifies that KY is 16 bytes yet the example is using 26 bytes. I don't understand this reasoning, so please clarify. I have left it as is, for the time being. Edit: 16 bytes in plain text appears to be 26 bytes in Base32.
I have gone the route of Quicksilver's text since he has been able to argue for his algorithm the best (in my mind).
==== SUDP - Encrypting UDP traffic

This is an extension that allows UDP traffic to be encrypted.

While assymetric 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 'request command' (e.g. searches) and send it along the 'response command' (e.g. search result).

Signal SUDP in SUP and in the INF's SU field.

If a client signal support for SUDP in an ADCS hub, it may extend commands (that will generate a response, e.g. SCH) with a KY-flag as the encryption key. [Edit:] Clients shall only include the flag in ADCS hubs.
[options="autowidth"]
|=====
|KY | 16 byte encryption key in BASE32. 128 bit AES encryption shall be used.
|=====

For example, a SCH command will result in 29 Bytes of overhead ("<space>KY"+26 Bytes Base32 encoded key).

A client that has a response for the command can now encrypt the response message 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.

In above scenario, the response would be a RES command.

====== Decryption notes
In the case of searching, the searching client in return for decryption first has to 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! [Edit:] Clients may also try and interpret the message as plain message and then try all keys and take the first key as valid that succeeds decrypting and produces a non-garbled message. Note that in a normal circumstance, the client will most likely be using relatively few active keys.

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

Re: SUDP - encrypting UDP traffic

Post by Pretorian » 15 Oct 2010, 23:08

I was going to modify the edited text, but appearantly the forum software don't allow me anymore. Anyway, the previously edited text should be;
Client may otherwise verify if the message is a U-type message, followed by a known command (and a space). If that is not the case, the client takes the most recent key and decrypts. If that succeed, the message is valid.

There is a potential chance that decryption succeed with what is bad key. If that is the case, the client should verify that the data is not garbled.

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

Re: SUDP - encrypting UDP traffic

Post by Pretorian » 15 Oct 2010, 23:35

Added to ADC-Ext 1.0.6.

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

Re: SUDP - encrypting UDP traffic

Post by Pretorian » 29 Nov 2010, 20:27

Pushed in official ADC-Ext 1.0.6.

klondike
Member
Posts: 73
Joined: 14 Nov 2010, 13:06

Re: SUDP - encrypting UDP traffic

Post by klondike » 17 Feb 2011, 15:28

Pretorian, I'm asking this as I don't know enough of the ADC way of doing things, can a new propossal for SUDP be submited as SUDP2 or similar?

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

Re: SUDP - encrypting UDP traffic

Post by Pretorian » 20 Feb 2011, 20:57

klondike wrote:Pretorian, I'm asking this as I don't know enough of the ADC way of doing things, can a new propossal for SUDP be submited as SUDP2 or similar?
All features must be a 'four character code'; so you have to either have "SUD2" or something completely new.

What exactly do you want modified?

klondike
Member
Posts: 73
Joined: 14 Nov 2010, 13:06

Re: SUDP - encrypting UDP traffic

Post by klondike » 11 Mar 2011, 23:32

Well I had some ideas that could be useful to handle the obfuscation problem whilst having still key identification, I also miss a message digest to ensure the messages are not modified. Here is the proposal:

As part of the myinfo, the client will send an OBK (or obfuscation key) in BASE32. This key should be randomly chosen, should be the same on all the hubs but can be changed (using the OKS command) when the client doesn't expect to receive new messages obfuscated with it.

When sending a command that will produce UDP replies (for example SCH) you pass two positional parameters:
KY encryption key in BASE32
KI key identifier in BASE32 (should be random and of the same size or smaller than the block size)

This adds at least a 3 extra byte overhead but also results in easier key search.

When answering, the client will do the following:
id = Generate a random byte (which is not U nor $ to avoid clashes with unencrypted NMDC and ADC UDP packets)
iv = Generate a IV of blocksize bits.
eki = Encrypt with the destination OBK using CBC and iv as IV the KI (extended with 0 bytes on its left if it is smaller than the provided one).
md = Hash with the session hash the answer being sent (for example URES ...)
pcmd = Pad
em = Encrypt with the received KY using CBC and eki as IV the command with the md appended at the end of it.

Finally you send id | iv | eki | em

Regarding decryption:
The client checks that the id is not U nor $ otherwise passes the message to be interpreted by the SUDP parser or the normal parsers.
The client decrypts the key id using the provided iv with his OBK and checks if it has a matching key which was sent. If it doesn't the message is passed to SUDP for parsing or dropped.
If it finds a matching key then decrypts the message, unpads it (WITHOUT checking the padding) and calculates its digest.
Finally it checks the padding and then that the digests match. if they don't the message is dropped. If it doesn't the message is passed to SUDP for parsing or dropped.

To avoid oracle style attacks it is very important to check the padding and that the digests match after calculating the digest itself.

---

I still want to make the protocol not cipher dependent, so I'll reread again the session hash negotiation algorithm and propose a similar solution for this.

klondike
Member
Posts: 73
Joined: 14 Nov 2010, 13:06

Re: SUDP - encrypting UDP traffic

Post by klondike » 18 Mar 2011, 05:02

Seeing nobody said nothing I bet that part is good enough. Now lets go to the encryption algorithm discussions:

keys are negotiated through the new proposed key format:

Keys will be in a slightly different format, instead of being plain keys they will have the format:
TYPE1":"BASE32 key1","TYPE2":"BASE32 key1","...","TYPEN":"BASE32 keyN"
Where types correspond to the cipher feature name.

For example:
AES:aaaaaaaaaaaaaaaaaaaaaaaaa,NONE:bbbbbbbbbbbbbbbbb

To avoid conflicts with the previous SUDP version the named parameter to be used when passing the in the request password will be K2 instead of KY.

Cipher and they feature names will be proposed in the same way as extensions and must not conflict with them. Their name can't also contain the : and , characters to make parsing easier.

Implementers should bear in mind that increasing the number of supported protocols will be doing more operations to check the validity of packets (specially bad packets) as it will be needed to do as many decryptions as ciphers it supports over the first block. It is reasonable to think that in case AES 128 is broken a new cipher will be propossed and migration to it will be fast enough so more than two cipher won't coexist.

==============================================================================================================
AES cipher proposal:
This proposal only defines AES 128 bits in CBC mode and using PKCS5 under the name AES.

===============================================================================================================

So well any comments, suggestions, critics or whatever? I'd like to start making the reference implementation if you think is OK.

cologic
Junior Member
Posts: 41
Joined: 21 Jul 2009, 19:34

Re: SUDP - encrypting UDP traffic

Post by cologic » 18 Mar 2011, 21:51

Disclaimer: crypto is more subtle than I understand, so I probably missed a lot here.

Post Reply