1
$\begingroup$

In a previous question, I asked how to implement arbitrary s-box in side-channel-free fashion. The code I posted in the question loops over all 256 values of a byte to avoid timing channel, and I want to change it to loop over the values of a word.

Before getting carried away and lost, I'm considering lazy-initializing the s-box table. Specifically:

  1. write byte-for-byte (i.e. 8-bit) sbox table.
  2. on the first invocation of the sbox on that table, multiply all entries of that table with 0x01010101 to make it 32-bit.
  3. loop over the words and mask each bytes individually to get whole word substituted.

Now. The purpose of this question has nothing to do with coding technique (a serious drawback of this approach is that, what was previously constant data is now variable, and some dyld optimization is no longer applicable). The said technique assumes that a fixed point at 0 in the sbox is something that should never happen in any secure blockcipher, so comparing this value against 256 can tell whether the initialization had occured before or needs to be done.

This question wants to ask, whether and how fatal it is, to have a fixed point at 0 in the sbox of a block cipher?

$\endgroup$

1 Answer 1

1
$\begingroup$

This question wants to ask, whether and how fatal it is, to have a fixed point at 0 in the sbox of a block cipher?

Whether a fixed point at 0 in an sbox is fatal would depend on the cipher. For AES, it is fatal, because the AES sbox is fixed and expects a value of 0x63 at location 0.

On the other hand, it is also irrelevant; if you want to encode an sbox with the above technique, then what you can do (assuming that the sbox you want has 0x63 at location 0) is actually encode sbox[] ^ 0x63 with the above technique. Then, after you've evaluated the modified sbox, xor in a constant 0x63636363 to the result, and that'd give the original sbox.

$\endgroup$
4
  • 1
    $\begingroup$ I think you missed my point. The initialization checks sbox[0x00]>=256, so a fixed point here will cause initialization to repeat endlessly, as sbox[0x00]==0. So if this technique is to be used, 0 must not map to itself. And I think there should be security concern with this particular fixed point. $\endgroup$
    – DannyNiu
    Commented May 8, 2023 at 14:33
  • $\begingroup$ If a blockcipher gets all-0 for input, and it doesn't use some kind of round constants like keccak or chacha, and it has this particular fixed point, then I think it'll probably output all-0. $\endgroup$
    – DannyNiu
    Commented May 8, 2023 at 14:43
  • $\begingroup$ Oh, you insist that sbox[0] != 0. In that case, you can use the same trick (except in reverse; if sbox[0] == 0, you xor'ed in a nonzero value in both the sbox and at the end) $\endgroup$
    – poncho
    Commented May 8, 2023 at 17:11
  • 1
    $\begingroup$ And, if a blockcipher doesn't have a per round constant (that is, all the rounds are identical), it's probably vulnerable to a slide attack... $\endgroup$
    – poncho
    Commented May 8, 2023 at 17:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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