James Muir wrote: > Alexander Klimov wrote: > >> On Tue, 26 May 2009, James Muir wrote: >> >>> There is some academic work on how to protect crypto in software from >>> reverse engineering. Look-up "white-box cryptography". >>> >>> Disclosure: the company I work for does white-box crypto. >>> >> Could you explain what is the point of "white-box cryptography" (even >> if it were possible)? >> > > The introduction to the following paper (from SAC 2002) gives a very > good overview of white-box crypto: > > http://www.scs.carleton.ca/%7Epaulv/papers/whiteaes.lncs.ps >
The aim of white-box cryptography is to implement cryptographic primitives in such a way that they remain /secure/ against software analysis. The 'white-box' refers to the fact that the adversary has full access to the software implementation and control over its execution environment. Its prior objective would obviously be the protection of secret keys that are embedded in key instantiated implementations of encryption schemes. But often it goes beyond that objective. In some practical settings it will indeed turn out that the resulting white-box implementation behaves as a public-key primitive, as you point out, but for other applications, that might be overshooting the objective. The paper that James mentioned introduced the subject of white-box cryptography into academia. In the mean time, the subject received more interest, and has been studied further on. For more information (introduction and subsequent research), I'm happy to point you to my PhD dissertation of March this year, entitled "white-box cryptography". https://www.cosic.esat.kuleuven.be/publications/thesis-152.pdf I also wrote a (rather theoretical) paper to settle a concrete definition of white-box cryptography, which you can find on e-print: http://eprint.iacr.org/2008/273. > >> If I understand correctly, the only plausible result is to be able to >> use the secret key cryptography as if it were the public-key one, for >> example, to have a program that can do (very slow, btw) AES >> encryption, but be unable to deduce the key (unable to decrypt). If >> this is the case, then why not use normal public-key crypto (baksheesh >> aside)? >> > > You're right -- a white-box implementation of a symmetric cipher > essentially creates an asymmetric cipher. Despite this, there are still > situations where you might want a whitebox AES implementation running on > a client. Consider a server that sends out updates to several hundred > clients (each client has its own key). The clients are subject to > whitebox attacks but the server is not. Rather than force the server to > do several hundred public-key operations when it needs to push out an > update, we might be able to save the server some work if use a symmetric > cipher. > > -James > > Consider a DRM application that contains a key-instantiated decryption algorithm and some authentication scheme. In that case you want to prevent the extraction of the secret key, otherwise an adversary could easily circumvent the authentication scheme. Deploying a public-key cipher wouldn't help achieving this objective, since it is a matter of how you implement the decryption operation and entangle it with the authentication scheme. Another example might be a mobile agent system, where a signing key would need to be embedded in the software such that the agent can sign contracts. Brecht http://whiteboxcrypto.com -- Brecht Wyseur Katholieke Universiteit Leuven tel. +32 16 32 17 21 Dept. Electrical Engineering-ESAT / COSIC fax. +32 16 32 19 69 Kasteelpark Arenberg 10, B-3001 Leuven-Heverlee, BELGIUM office 01.53 brecht.wys...@esat.kuleuven.be http://homes.esat.kuleuven.be/~bwyseur P=NP if (P=0 or N=1) GPG Pub key: https://homes.esat.kuleuven.be/~bwyseur/pubkey GPG Fingerprint: 890C 7C0B F1D9 597E F205 87C8 B716 D7D3 20F8 353F --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com