Re: consulting question.... (DRM)
Their product inserts program code into existing applications to make those applications monitor and report their own usage and enforce the terms of their own licenses, for example disabling themselves if the central database indicates that their licensee's subscription has expired or if they've been used for more hours/keystrokes/clicks/users/machines/whatever in the current month than licensed for. The idea is that software developers could use their product instead of spending time and programming effort developing their own license- enforcement mechanisms... Many people have had the same idea before. The software license manager field is pretty full of little companies (and divisions of big ones). Your prospect might be able to find a niche in there somewhere, if they study their competition to see what's missing and how they can build up an edge. But customers tend to hate software that comes managed with license managers, so it takes an exceptional company to fight the uphill sales battle to impose them. (And having a company switch from License Manager A to License Manager B requires reissuing licenses to every customer, an extraordinary customer- support hassle.) Only in markets where the customer has no effective choice (of a competing DRM-free product) does it tend to work. My last startup, Cygnus, sold un-license-managed compilers, competiting with some entrenched companies that sold license-managed compilers. We kept seeing how our own automated overnight software builds would fail using our competitors' compilers because the license manager would screw up -- or merely because the local net or Internet was down. Or it would hang overnight awaiting an available license, and doing no work in the meantime. Our compiler always ran when you asked it to. We got tens of thousands of people to switch to our (free) GNU C and C++ compilers, and enough of them paid us for support and development that our company kept growing. Our best selling point against Sun's compilers, for example, was that ours didn't use any license manager. Once you bought or downloaded it, it was yours. It would run forever, on as many machines as you liked, and you were encouraged to share it with as many friends as you could. It was simple for us to invade their niche when they had deliberately forsworn a feature set like that. John Gilmore PS: Our trade-show giveaway button one year was License Managers Suck; it was very popular. PPS: On a consulting job one time, I helped my customer patch out the license check for some expensive Unix circuit simulation software they were running. They had bought a faster, newer machine and wanted to run it there instead of on the machine they'd bought the node-locked license for. The faster their simulation ran, the easier my job was. Actually, I think we patched the Unix kernel or C library that the program depended upon, rather than patch the program; it was easier. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: white-box crypto Was: consulting question....
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 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 signature.asc Description: OpenPGP digital signature
Neat idea
Using retransmissions for steganography. http://arxiv.org/pdf/0905.0363v3 -- Jerry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
white-box crypto Was: consulting question....
2009/5/27 Alexander Klimov alser...@inbox.ru mailto:alser...@inbox.ru: 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)? White-box crypto is about implementing 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. The prior objective would obviously be the protection of secret keys in key instantiated implementations of encryption schemes, but often it goes beyond that. In some practical settings you would want the resulting white-box implementations to behave as a public-key primitive, as you mention below. You can find formal definitions of white-box cryptography in a paper I recently wrote: http://eprint.iacr.org/2008/273 http://eprint.iacr.org/2008/273. More information on white-box crypto you can find in my PhD dissertation of March this year. https://www.cosic.esat.kuleuven.be/publications/thesis-152.pdf https://www.cosic.esat.kuleuven.be/publications/thesis-152.pdf 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)? 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. Regards, 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, BELGIUMoffice 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
What will happen to your crypto keys when you die?
Fascinating discussion at boing boing that will probably be of interest to this list. http://www.boingboing.net/2009/05/27/what-will-happen-to.html Udhay -- ((Udhay Shankar N)) ((udhay @ pobox.com)) ((www.digeratus.com)) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: End-of-chapter questions for Practical Cryptography?
On Fri, May 22, 2009 at 7:55 AM, Perry E. Metzger pe...@piermont.com wrote: may be mistaken but I'm not aware of any significantly superior alternatives. What about Mao's *Modern Cryptography* ? As for Paul's question, maybe we can collaborate as a list on fun questions for readers of *Practical*. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
NYT: Pentagon Plans New Arm to Wage Wars in Cyberspace
Full article: http://www.nytimes.com/2009/05/29/us/politics/29cyber.html -- Perry E. Metzgerpe...@piermont.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: consulting question.... (DRM)
Jerry Leichter leich...@lrw.com writes: For the most part, software like this aims to keep reasonably honest people honest. Yes, they can probably hire someone to hack around the licensing software. (There's generally not much motivation for J Random User to break this stuff, since it protects business software with a specialized audience.) But is it (a) worth the cost; (b) worth the risk - if you get caught, there's clear evidence that you broke things deliberately. I think a far more important consideration for license-management software isn't how secure is it but how obnoxious is it for legitimate users? I know a number of people who have either themselves broken or downloaded tools to break FlexLM and similar schemes, and in every single case they were legitimate users who were prevented from using their legally purchased product by the license-mismanagement tools, or who after spending hours or even days fighting with the license-mismanagement software found it easier to break the protection than to try and figure out what contortions were required to keep the license-checking code happy. I've experienced this myself with a software tool I use, there are some (as I found out after several hours of searching support forums) well-known problems with it that the vendor doesn't seem interested in fixing, and that you can eventually resolve either with some registry hacks and other low-level changes or by downloading haxor tools that'll achieve the same result with a few minutes work (just for the record, I took the multi-hour route). So if your license-management software is sufficiently obnoxious that it turns legitimate users into DMCA-violators, you have a problem. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
