Let's take AES as an example. What would be wrong with just having a 256 bit key that you XOR into your input and then XOR into your output? No key expansion at all.

I believe it's even known as the Even-Mansour construction and is secure under the assumption that the permutation is sound.

So I'm confused by the purpose of key schedules, you need variability to resist slide attacks but you don't need a key schedule for that, round constants suffice.

  • 2
    $\begingroup$ what about related key attack? cipher without a keyschedule will need more rounds to be secure under related key attack as compare to cipher with the key schedule. if you are familiar with AES operations, then see LED block cipher, it does not employ key schedule and its specification document provide proof against related key attack but with 32 and 48 rounds as compare to 10 and 14 rounds of AES $\endgroup$ – khan Sep 5 '18 at 4:18
  • 2
    $\begingroup$ AES has a 128-bit block, you cannot XOR a 256-bit key into that $\endgroup$ – Richie Frame Sep 5 '18 at 4:37

What would be wrong with just having a 256 bit key that you XOR into your input and then XOR into your output?

If I understand you properly, you split the 256 bit key into two 128 bit parts. This will be the whitening key that helps to resist exhaustive key search.

In term of round constant, it is adds asymmetry to the key and prevents slide attacks. However, you overlooked other attacks such as invariant subspace attacks for which you have to choose constants that eliminate weak key classes.

A related-key attack may remove the effect of the constant (key difference eliminates the constant) but in real world, the adversary needs to have access to key generation to perform this attack.

I believe that the design of key-schedule lacks to solid proof. There was a paper in FSE18 about the mathematical proof of the AES-128 key schedule under related key attack. A solution was proposed using a better and lighter key-schedule without s-box or round constants, just permutation.

However, how to choose constants that prevent slide attacks? In other words, is there a proof that adding any constant will stop a slide attack?

  • $\begingroup$ I'm not familiar with the AES-related paper, but I don't think the S-box part could be right. That's the only part of AES that is non-linear with respect to XOR. Without it every bit of output can be described as a sum (well, XOR) of a fixed set of input bits and key bits. You end up with a system of equations which are just bits XORed together; solving them lets you recover the key with just one known input/output pair. $\endgroup$ – Future Security Sep 6 '18 at 3:53
  • $\begingroup$ the paper called : "Human-readable Proof of the Related-Key Security of AES-128" . page 21 $\endgroup$ – hardyrama Sep 9 '18 at 5:10
  • $\begingroup$ Sorry. I misread. I thought you said that the permutation (one used in an EM type cipher) used no S-boxes. Somehow I missed the "key schedule" parts... $\endgroup$ – Future Security Sep 9 '18 at 15:17
  • $\begingroup$ You're ending your answer with a question (or two). That's generally not a good way to conclude. $\endgroup$ – Maarten Bodewes Oct 5 '18 at 13:51

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.