search

OpenWhiteBox / AES

Implementations of white-box AES constructions and their cryptanalyses.
BSD 3-Clause "New" or "Revised" License
209 stars 31 forks source link

Problems trying to validate the full AES implementation #5

Open doegox opened 7 years ago

doegox commented 7 years ago

Hi, I'm trying to build a "challenge" out of the "full" implementation but I cannot validate it against test vectors. Taking e.g. your example in the README.md:

echo 000000000000000000000000deadbeef|xxd -r -p|openssl enc -e -aes-128-ecb -K 0123456789abcdeffedcba9876543210 -nopad|xxd -p
e99447e5eb535c5cd0baa5aa5151d7c9

instead of the expected dfc967b77a809c926075441565cbc3e3

And same thing if I generate my own with another key, I can't match the whitebox behavior with e.g. OpenSSL or NIST test vectors. Note that I didn't have this issue when I compiled and used challenges from your Chow or Xiao-Lai implementations some time ago.

Bren2010 commented 7 years ago

The full construction requires random affine transformations on the input and output of the white-box, which is why you get different output than openssl (and should get different output if you run go generate_key.go again). I believe Chow and Xiao-Lai also support this but you can disable it, as per the authors' descriptions.

The full construction is known to be insecure if the attacker knows the input/output transformations. However, here is a script that does encryption with the public part of the white-box and scrubs the input/output transformations with the private part: https://pastebin.com/KWh3Fy7p

Bren2010 commented 7 years ago

Also, I'm not sure if it will help, but you can disable Golang's garbage collector by setting the environment variable "GOGC=off"

doegox commented 7 years ago

Thanks a lot @Bren2010 ! Ok so the initial example was with remotely applied external encodings. We know that if both input and output are encoded and we don't have access to either clear input or clear output, a whitebox is safe against DCA (and safe against DFA if we don't have access to the clear output). But we know also that it limits the usage of such whiteboxes to proprietary protocols (e.g. authentication to the cloud, key provisioning, etc) and they can't be used for e.g. in DRM (they're all standard AES) or HCE EMV payments.

I will create both types of challenges and make a clear distinction between themselves (as for https://github.com/SideChannelMarvels/Deadpool/tree/master/wbs_aes_nsc2013_variants/target).

I will also try the trick of turning off the GC, thanks for that.