1
$\begingroup$

I am trying to code a simple WBC situation to help my understanding about white-box cryptography.

Details:

  1. I have 2 programs, a "server" and a "client", the server utilises caesar cipher (key = 2) encrypts the plaintext "HELLOWORLD" and sends it to the client.

  2. On the client side, key = 2 is embedded into the source code.

how would the WBC implementation of either my "server" or "client" be different from a normal "server" and "client"

$\endgroup$
1
$\begingroup$

The current way of implementing a (symmetric) cryptographic algorithm as a white-box is to implement it as a network of encoded lookup tables (a good white-box will also have so called 'external encodings' applied, but I'll skip these for now).

In this case however, a network of tables is not required (one table will do) and as a result encoding the tables is no longer nescessry. So in this case, I would implement this algorithm as 'a lookup table'.

Let's say (for easyness) that A=0, B=1, ..., Z=25. Than we can implement the decrypt function on the client as following:

public int WhiteBoxDecrypt(int letter) {
    // Decrypt one encrypted block - in this case, a block is one character (represented as integer).
    int[] lookupTable = {24, 25, 0, 1, 2, ..., 23 };
    return lookupTable[letter];
}

Note that this implementation is as secure as a black box implementation would be (well, a black-box implementation that would decrypt per character). The only way to crack this implementation is to compare the inputs and outputs to the algorithm (all of these inputs and outputs are provided in a single table). This is why using lookup tables is so cool - it's a datastructure that shows just inputs and outputs, just like a real black-box would do.

Bonus: a pretty good tutorial by James Muir on implementing a white-box AES can be found here.

| improve this answer | |
$\endgroup$
  • 1
    $\begingroup$ From perspective of having a secure implementation, using lookup tables is not always as good as a black-box implementation, because of subchannels information (e.g., timing). Table lookups tend to be take variable time due to cache effects. $\endgroup$ – user4982 Jan 18 '15 at 10:51
  • 1
    $\begingroup$ The idea is to make it as strong as a black box: you can place a debugger or logger for the input and output. But even if you do that, you cannot see the key, or what happends inside the algorithm. What extra information can the timing give that a debugger cannot? $\endgroup$ – Matty Jan 18 '15 at 12:07

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.