I've used the C++ prog I found on the web to generate the standard Sbox with poly 0x11b, and also modified it to use a lookup table of all the multiplicative inverses of the 256 values, which also works fine. I'm now trying to generate alternative Sbox using polynomial 0x11d, as used in the paper by Das, Zaman & Ghosh, but without much success. I've again generated all the multiplicative inverses for the poly and used them in a lookup table, but I do not get the same results as the paper's authors.

  • 1
    $\begingroup$ I added a link to a paper that seems to be refereed to in the question. I guess that the results not replicated are those in Appendix A. To the OP: welcome to CSE. Don't attach your C++ prog: describe what it does and how, and illustrate that with the intermediary steps producing an example value that does not match; like, the first discrepancy w.r.t. Table A1(a). There is a good chance you will solve your problem in this way. And if you do not, someone likely will. Unrelated: the interest of what this paper does is dubious at best, and some of it (section 3 and its table 1) is nonsense. $\endgroup$ – fgrieu Nov 25 '19 at 11:08
  • 1
    $\begingroup$ I generated all the inverses for the polynomial 0x11d, my first error against the paper was for the value 0x03, which I have inverse of 0xf4, (which I manually checked ok in the GF) The affine transform of this gives me 0x26, adding the fixed offset vector 0x0a i get the result 0x2c, the paper has 0x90. Is the paper wrong, or is it me? $\endgroup$ – KevP Nov 25 '19 at 11:51
  • $\begingroup$ Sorry, but to me the paper you cited looks like rubbish (not your fault!!). The purpose of the paper seems to add a publication to their list. I hope none of the authors is your advisor, and that you don't have an advisor recommending you to read such stuff. $\endgroup$ – j.p. Nov 26 '19 at 6:26

The paper's tables in Appendix A are wrong.

For the entries in the first line of Table A1(a) I independently get:

0A 15 3F 2C 90 3B 19 51 FD EF 28 8C 83 A0 A7 36

and the fourth value (for input 03h) matches the OP's computation.

Note: there are fixed points (including 23h), invalidating the list of the valid additive constants, which is about the only attempt at an addition to self-citation [15] (at least, Appendix 1 table 2b appears correct and is available for free there).

Recommendation: if working on that paper is an assignment in a crypto course, question the competence or/and honesty of the assigner.

  • $\begingroup$ Thanks for the reply "fgrieu", I agree with your first 16 values, presumably the whole 256 values. I guess the paper I came across is rubbish, (I also spotted that 23 mapped to 23). I was only doing this for my own edification, as a retired electronic engineer where I used AES in systems quite bit, just thought I'd see what options there were for (maybe) improving security, as obviously the standard S-box is widely known. $\endgroup$ – KevP Nov 25 '19 at 20:46

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.