How to determine which tweak was used

Question

Imagine the following situation:

• you have a tweakable block cipher
• you have a plain text block
• you have a cipher text block
• you have the key which was used to encrypt the plain text block

I have these questions to it:

• Is there a way to determine the tweak which was used? (a method which is significantly faster than brute forcing)
• Is a tweakable cipher considered more secure if there is no fast method to do that?
• Is any tweakable block cipher explicitly protected against that?

My concrete case is the following: I wrote an implementation of threefish in python. To check if I did sth wrong, I looked for test vectors in the internet. Every vector worked, except one. The difference between this vector and a previous example on the same page was only the tweak (to show that changing the tweak leads to another cipher block). So I wanted to know if there might be a fast way to calculate the tweak they actually used. Though this is very specific to threefish, I was curious if this might be a general design goal of tweakable ciphers.

Answer 1

This is outside the goal of tweakable block ciphers. For a counterexample, the following is an example of a secure (if inefficient) tweakable block cipher in the paper introducing tweakable block ciphers as Theorem 1 (p. 35): $$\widetilde E_K(T, M) = E_K(T \oplus E_K(M)),$$ where $E_K(M)$ is a block cipher. If you know $K$, $M$, and $C = \widetilde E_K(T, M)$, then it is trivial to compute $$T = E_K(M) \oplus {E_K}^{-1}(C).$$

The intentional nonsecrecy of the tweak is made clear in the introduction to the paper: all the uncertainty from the attacker's perspective is contained in the key; the tweak is just an index into a family of independent secret permutations.

It's unlikely that any tweakable block cipher is designed to keep the tweak secret. You may as well just use a longer key if you're going to choose it unpredictably. But maybe if you gave more details about your intended application, it might become clearer what you need?

Answer 2

I finally found an answer to my concrete problem with the threefish test vector: It seems like the tweak wasn't updated correctly in the pyskein implementation: In threefish, the tweak is a sequence of 16 bytes (two words). However, it consists of three words (24 bytes) internally. This third word is defined as

word0 xor word1

The pyskein implementation doesn't recalculate this third word when changing the tweak (or at least the version of pyskein they used for this test vectors). Please correct me if I'm wrong and this is intended, though it would be really weird since the encryption would base on two different tweaks: the current tweak and the first tweak.

Update:

on this page you can see which changes have been made on pyskein. The only tweak handling change is at 0.5.1

I don't know if these changes mean that they fixed the described bug or if it is actually intended.