Sorry, the question is not easy to state (or wasn't for me, anyhow).
So I'm writing a very flexible format for security. It allows for full choice of cipher, key size, and so on, along with key confirmation and derivation. All of this is communicated in objects with Protocol Buffers serialisation. Now, I get that I need to authenticate the cipher configuration (using Encrypt-then-MAC), but in my protocol, the authentication method itself is highly configurable just like the rest. Is this a situation where I need to NOT provide flexibility, or can I actually NOT "authenticate the authentication"? I would prefer retaining the flexibility, but not at the cost of security.
The high level description of a PayloadItem (the format that defines how to write/read an item to/from the payload) is, with their types:
- Type (string)
- Name (string)
- ExternalLength (long)
- InternalLength (long)
- Encryption (SymmetricCipherConfiguration)
- KeyConfirmation (VerificationFunctionConfiguration)
- KeyDerivation (VerificationFunctionConfiguration)
And I am thinking of adding EncryptionAuthentication (as a VerificationFunctionConfiguration) ... it seems to me that I cannot authenticate KeyConfirmation or KeyDerivation (I do not have the key at this point, yet, after all), too. Please help me through the security implications of this. I have already thought about the problem a good deal but would like some thoughts from others.
The key confirmation works by accepting a set of possible keys a receiver holds for a sender, and iterating through them, testing for equality with a verified output. The confirmation method is configured by its configuration object, which allows use of a MAC or KDF, with salt.
Similarly the key derivation is configured by its configuration object, allowing a selection of functions.
Is it okay if I just make sure that I do NOT use short-circuiting comparisons?