0
$\begingroup$

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.

$\endgroup$
  • $\begingroup$ Sounds likely to be a trivial data entry error on someone's part, unless you're talking about, e.g., UBI bookkeeping. The block cipher itself is really hard to make pass all but one test vector, but there's no shortage of off-by-one errors that compositions of block ciphers like UBI can fall prey to. It's conceivable that you could figure out the tweak in Threefish, but doing that is above my pay grade on this site! $\endgroup$ – Squeamish Ossifrage Dec 20 '17 at 15:39
3
$\begingroup$

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?

$\endgroup$
  • $\begingroup$ I've edited my question to make clear why I asked $\endgroup$ – Aemyl Dec 20 '17 at 8:30
0
$\begingroup$

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.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.