Hello Quicksilver,
Quicksilver wrote: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
Looks reasonable to me, just wanted to know about that.
Quicksilver wrote: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 ..
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: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
According to the spec any message of the UDP kind should have the CID appended before the command in the header.
Quicksilver wrote: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
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:also a integrity check is needed to avoid random messages.
PKCS5 padding is an integrity check for the message
(end-16)..end:key (which should be checked to ensure the message integrity).
As said PKCS5 padding does integrity check
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: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.
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: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.
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.
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 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.