Page 4 of 4

Re: SUDP - encrypting UDP traffic

Posted: 23 Mar 2011, 18:38
by klondike
cologic wrote: [*]Use HMAC, not a raw hash function. See Wikipedia's HMAC design principles section's references for why - basically there are some trivial prefix/suffix attacks that don't depend on breaking the underlying hash function. There's a Google Tech Talk on this issue too - see 22:54 in Crypto Strikes Back.
[*]You seem to be looking for authenticated encryption, a reasonable goal. However, there are (see Wikipedia article) several authenticated encryption modes which avoid the insecurities in both MAC-then-encrypt and encrypt-then-MAC modes (you use the former) as documented by Authenticated encryption: Relations among notions and analysis of the generic composition paradigm (see table 2) and The order of encryption and authentication for protecting communications (or: How secure is SSL?) (which does admit that MAC-then-encrypt, though generally insecure, actually works in your specific case of using CBC).
Thanks for the clue, effectively the first goal was confidentiality (to attain ofuscation) and the second one authentication.
After some analysis SIV seems the best candidate to provide authenticated encryption, as it also provides some resistance in case nonces repeat (which can happen as the number of peers increases, see

Here the authenticated data will be the IV and key identifier, the encrypted message will be the U message and the Key will be the preshared key. The hash is removed and the rest of assumptions (CBC and a random IV being used to encrypt the Key ID) will stay.
cologic wrote: [*]It's important to get the IV from a cryptographically secure RNG such as BN_rand().
Agreed, I will state that on the rewrite of the propossal.
cologic wrote: [*]NIST's Recommendation for Block Cipher Modes, appendix A (and the various other sources I could find), suggests that 0-padding is fine. For some specific crypto protocols it's very important to avoid (zero-padding, or more generally deterministic padding, was important in the recent PS3 break for example).
0 padding shouldn't be a problem as the receiver just can drop the padding bytes and check for the key. Anyway, usage of the full key identifier field length is encouraged unless there is a good reason not to do so.
cologic wrote: [*]PKCS#5 seem fine.
I think this will be dropable since the SIV specification states that arbitrary length messages can be used (need to verify that though).
cologic wrote: [*]The general design looks okay - the random IV reduces the (mostly unavoidable, but...) risk of reusing a secret encryption key across so many messages.
Disclaimer: crypto is more subtle than I understand, so I probably missed a lot here.
The random IV is meant mainly to ensure packages look different since the encryption key and the keyid will be shared between all the people answering the message.

As a side note:
* The siv specification specifies two keys, K1 an authentication key and K2 an encryption one, K2 MUST be sent with the request generating the answer but K1 may be negotiated between the peers to ensure the sender is whom it says to be and not another peer on the same hub (similar to signatures but without non repudiability).

I will write a simple extension on how this negotiation can be done using the hub as a trusted party later so we can also ensure that property too.

Just for the record, information on the SIV mode:

Re: SUDP - encrypting UDP traffic

Posted: 13 Mar 2013, 14:52
by klondike
Seems like OCB is now free for most uses:
I think this covers most if not all of the uses of ADC. What do you think?

OCB is quite easy to implement having the encrypt/decrypt primitives and quite fast so adoption shouldn't be a big problem either.

Re: SUDP - encrypting UDP traffic

Posted: 14 Mar 2013, 17:12
by klondike
So we had a discussiĆ³n on this topic yesterday and the following point were raised about OCB.
* The speed wins may not be that important since we are speaking of UDP packets.
* SIV is still safer against missuse.
* The patent license still could hinder some corner cases like a developer working for the military and in the long term cause issues for the protocol (despite the cases being quite unlikely).

So unless somebody can provide any argument to support OCB we'll stay with SIV on the propossal for now.

Re: SUDP - encrypting UDP traffic

Posted: 15 Mar 2013, 20:16
by klondike has an initial draft for the SUD2 extension, comments are more than welcome in the appropriate thread: