3
$\begingroup$

In a paper on a Feistel network, I found the line

we have made no effort to guard against attacks in the open-key model

and then I found this paper at iarc.org on the subject. I found only a single reference to this as an actual problem with RC4 and related keys in WEP implementations. If the open key model is an issue with related keys, why would the authors of a paper relating to a Feistel network make the statement regarding the "open-key model". Particularly, due to all of the work with Feistel networks and their proven security for a high round counts, I just don't understand why they would need to include this disclaimer. Is there something that I am missing?

$\endgroup$
  • 2
    $\begingroup$ I can only hazard a guess, but e.g. AES-256 has an issue with related key attacks. That doesn't mean that AES is insecure when used for most modes of operations as they will operate without related keys. But it is an issue with regards to using the block cipher as component for other functions such as cryptographic hashes, RNG's etc. So I would interpret it as: use this cipher for confidentiality, but don't change the key of the cipher often within an algorithm or protocol. $\endgroup$ – Maarten Bodewes Aug 18 '16 at 20:47
  • $\begingroup$ Could you point me to a reference for AES-256 attacks? I couldn't find a reference, but I'm a bit of a novice and I am catching up on my literature. I'm just sort of curious because let's say that I have an embedded system, or something that uses a 64-bit key, which isn't strong. It seems like the logical thing would be to change the key every hour. I guess as long as the keys aren't algorithmically connected. $\endgroup$ – b degnan Aug 18 '16 at 23:39
  • $\begingroup$ @bdegnan I'm not sure if you still would like a reference to AES related key attacks, but here is one $\endgroup$ – Ella Rose Feb 2 '17 at 17:34
1
$\begingroup$

It is not uncommon for a paper to state that the proposed design was not designed to protect against related key attacks. One reason for this is the over-powered nature of the attack against confidentiality: If the adversary already possesses the key, and can encrypt and decrypt at will, then one has to wonder how/why the adversary even stands to benefit from running an attack.

The open key model appears to go a step further, and assume that the adversary may have even chosen the key in question.

As far as confidentiality goes, there appears to be little point to defending against a known/chosen key attack. Doing so would likely require a more elaborate design, or at least more rounds, which will degrade performance in the "regular" use case to protect against an edge case situation that seems unlikely to occur in practice.

As to why a paper would explicitly mention such a thing: It is better to see "we made no attempt to protect against this class of attack" as opposed to not even mentioning the existence of the class of attacks. If the authors decline to mention related key attacks, it could be interpreted that they were not aware of them, as opposed to did not care to defend against them.

On the opposite side, there is one compelling reason to try and defend against known/chosen key attacks: If the cipher is to be used as a component of a hashing function, known/chosen key attacks become a relevant threat model. For example, this is mentioned briefly on page 9 of the proposal for simon/speck.

$\endgroup$
  • $\begingroup$ The simon paper was where I first came across this actually; however, I found it in another Feistel paper, which was why I tried to generalize the question. Thank you again for the link. $\endgroup$ – b degnan Feb 2 '17 at 17:57

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.