12
$\begingroup$

After an initial study of white-box cryptography, specially around the first article (Chow et. al.), I understood each step of transforming the lookup tables of AES into new ones.

If I understood it correctly, the purpose is to redefine the AES algorithm to propose new tables in each step and to perform lookups into different tables in order to obfuscate the key.

I have trouble understanding where the key is supposed to be in the white-box version of AES. During the AES development into code, is the key defined statically or it is diffused into tables in a "pre-calculated" manner always before the AES execution?

$\endgroup$
14
$\begingroup$

In whitebox cryptography the attacker is supposed to have access to every detail of the computation and the goal of this implementation is to protect the key, to -usually- avoid it is used on a classical no-whitebox implementation on a different platform.

The goal is that an attacker having access to the whole computation and intermediate values cannot achieve a bigger knowledge of the encryption key as he would have a black-box access (only input/output for all input of his choice).

The perfect way to create a whitebox implementation would be to tabulate the AES: for a given key, one takes all the possible input blocks, compute the encryption on a trusted machine and put the output on a table. In this scenario an attacker would have access only to the input/output and the computation has been done elsewhere. But, of course, this table would be ${HUGE}$ (e.g.: for the AES: $2^{128} \times 128$ bits, I don't even know how to write this quantity, but could be approximated by $2^{92}$ Terabytes). So, a typical solution is to use several lookup tables (noted as LUT) in a networked way. This allows to build an implementation in a less of a Megabyte (700k), even if this size is quite a lot in respect to a standard, no-whitebox implementation. Resume of white-box applied in AES algorithm (slides 18 - 24).

So you are not going to see the key in a whitebox implementation, the key is cut, smashed, embedded in all the tables used to compute a single encryption.

That also means that the key is not loaded somewhere during the computation but has to be embedded before shipping the implementation, and that when one needs do change/update the key, he has to ship another implementation (or on other set of tables).

$\endgroup$
  • $\begingroup$ Alternatively, the key is input via some other whitebox process (for example, a whitebox implementation of DH), and given in an obfuscated form to the internal whitebox AES implementation. $\endgroup$ – poncho Jun 30 '16 at 22:18
  • $\begingroup$ I, personally, would try to keep obfuscation separated from whitebox $\endgroup$ – ddddavidee Jul 1 '16 at 5:47
  • 2
    $\begingroup$ Well, if you want to write it out... wolframalpha... apparently it is called 43 duodecillion 556 undecillion 142 decillion 965 nonillion 880 octillion 123 septillion 323 sextillion 311 quintillion 949 quadrillion 751 trillion 266 billion 331 million 66 thousand 368 in the short number system. $\endgroup$ – Maarten Bodewes Jul 1 '16 at 7:33
  • $\begingroup$ That makes a lot of floppies!!! $\endgroup$ – ddddavidee Jul 1 '16 at 7:38

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.