The MCOE mode provides a really nice way to implement a nonce-misuse resistant AEAD and is based on an arbitrary tweak block cipher.
A specific requirement of the tweak block cipher is that the data block length is the same size as the tweak.
As I use Skein to perform key derivation and hashing, the Threefish cipher comes as an automatic blessing, hence the desire to try to use it as much as possible to minimize my application footprint.
Unfortunately, Threefish minimum block size is 256 bits and its tweak block size is 128 bits, so there is no direct way to use the cipher in this mode.
While the authors provide two additional modes that convert a regular block cipher into a tweakable one, one mode has been shown to have some weaknesses, and the other requires additional complexity.
A simple idea to “compress” the new tweak value form 256 bits to 128 bits occurred to me. Simply XOR the MSB 128 bits of the new tweak value with the LSB bits of the new tweak value and let this be the final new tweak.
Would this be secure? Possibly reduce overall security, but not render the modified mode insecure?
The MCOE mode as designed outputs a single tag at the end of the message processing. I need to be able to output intermediate tags so as to reject processing early if the message is invalid.
My application is firmware update in deeply embedded small sensors, so I cannot download the entire firmware image to RAM, check it, and accept or reject before reprograming. I must erase FLASH memory, download to FLASH, and then check the final tag. If it is rejected, I erase FLASH, but now leave the device in a non-functional state.
Ideally, I would download a header part of the file, check its intermediate tag, and abort download if there is a mismatch. This would avoid having to erase FLASH and will leave the sensor in its previous state.
The MCOE final tag is an encrypted value that is dependent on the associated data and its length as well as the encryption key. At the end of the message, the tag value that was generated from the key and associated data is encrypted using the key and current value of the tweak (the tweak changes as new blocks are processed).
I was thinking that a simple way to generate intermediate tags would be to simply process the final tag as an intermediate one with the same chaining as for secret message data, just treat the initial unencrypted tag value as secret data.
Multiple intermediate tags will all be different because they are dependent on the tweak as it changes for each new block processed. The initial unencrypted tag value is never published, so to reverse the encrypted tag would require knowledge of the key and tweak used.
Will this modification impact the overall security, and if so, how? Is there a better method?