Thanks for the clue, effectively the first goal was confidentiality (to attain ofuscation) and the second one authentication.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).
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 http://en.wikipedia.org/wiki/Birthday_problem).
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.
Agreed, I will state that on the rewrite of the propossal.cologic wrote: [*]It's important to get the IV from a cryptographically secure RNG such as BN_rand().
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: [*]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).
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: [*]PKCS#5 seem fine.
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.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.
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: http://www.cs.ucdavis.edu/~rogaway/papers/siv.pdf