SUDP - Encrypting UDP traffic
From DCBase Wiki
This is an extension that allows UDP traffic to be encrypted.[1]
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-field as the encryption key. Clients shall only include the flag in ADCS hubs.
| 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 ("<separator>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!
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 a bad key. If that is the case, the client should verify that the data is not garbled.
Note that in a normal circumstance, the client will most likely be using relatively few active keys.
