23

The Wolfram blog post: Using Mathematica Enterprise Edition to Create Professional Apps, Tools, and Reports makes the following statement (emphasis mine):

Enterprise Edition allows you to create EnterpriseCDF files, which provide enhanced capabilities that can be deployed via the free Wolfram CDF Player. But what are these capabilities, and why are they important to the work that you do? Let’s take a look.

First, Enterprise Edition allows you to encrypt your code, so recipients cannot see your proprietary algorithms. For consultants and application developers, this was an absolute must. With Enterprise Edition, you can deliver reports, updates, and full solutions to your potential customers without revealing your intellectual property.

Note that this statement says "encrypt" not "encode". A great deal hinges on this distinction.

In a comment to Albert Retey's answer to this question: What can webmathematica do that CDF cannot do?, Andreas Lauschke states:

With the CDF, the M code is included in the distribution. WRI shows you ways to "encode" that, but it's a joke, you can hack that with 5 lines of code.

Others on this site have expressed similar concerns.

With these concerns in mind and knowing that promotion and marketing doesn't always represent things as accurately as one would like, a colleague contacted Wolfram to ask whether Enterprise Edition really could encrypt code or if it only relied on something akin to encoding of packages?

Neither Premier Support or sales could supply a direct and immediate answer. I think anyone reading this who has an interest in deploying Mathematica applications that need to include proprietary code, would share the unsettling feeling this left us.

Now, we appreciate that this may represent new functionality and that support and sales people need to get up to speed on such things. So we hope they clarify this. If we hear back from Wolfram, we'll share the information.

But for now, it leaves the question...

Can Enterprise Edition really encrypt code for distribution via CDF?

If it does support real encryption, knowing a bit about what type of encryption would also provide some comfort.

I recognize this falls a bit out of the normal range of questions, but I think it concerns many of us in this community and raises some other questions about using Mathematica and what one can and cannot reasonably do with it.

Community
  • 1
Jagra
  • 14,343
  • 1
  • 39
  • 81
  • "I recognize this falls a bit out of the normal range of questions" — I think it's a fine question for this site, since it's objective and has an answer. However, the prospects of those who know how to work around the encryption sharing it in public are little to none, since they themselves have to rely on what's available for their apps. – rm -rf Mar 18 '13 at 19:01
  • @rm-rf -- That presumes that only other Mathematica developers would have an interest in decrypting an application. Lots of others with lots of have reason to steal IP. Some credible encryption approach, maybe some current version of PGP, with public and private keys, would make me much happier than encoding. – Jagra Mar 18 '13 at 19:42
  • 2
    Good question, and if recent precedent is anything to go by, you may get a faster and more direct answer here than by going to WRI support. Regarding your desire for a "credible encryption approach"--just remember that, no matter how secure a scheme may appear, if you give someone the tools to decode its ciphertext legitimately, they have everything necessary to decode it illegitimately as well, and what they do with the decoded result is not under your direct control. – Oleksandr R. Mar 18 '13 at 20:01
  • @OleksandrR. -- Why would one ever need to give someone else the tools to decode encrypted code. They might have a means to reverse engineer functions by looking at inputs and outputs, but that seems a very different thing. – Jagra Mar 18 '13 at 22:14
  • 4
    Well, how can they run the code unless they can decrypt it for that purpose? – Oleksandr R. Mar 19 '13 at 00:05
  • @OleksandrR. -- You make a good point, which really raises more questions for Wolfram. How does this new "encrypt" described in the blog post work? Encode seems to just disguise the code but doesn't affect its operation, one doesn't have to reverse the encoding to run the code. Does this new encrypt (if real) work in similar manner, while being less easily read? – Jagra Mar 19 '13 at 02:43
  • Encode does need to be undone before the code is run--it is more than just obfuscation. This occurs internally to Mathematica when you Get the encoded file. Actually, I think that Encode really should be considered as a form of encryption, especially when a non-default key is used. – Oleksandr R. Mar 19 '13 at 12:12
  • @Oleksandr, encoding is certainly NOT encryption. And therefore should also not be "considered" as such. You can call a horse an elephant, but that doesn't MAKE it one. – Andreas Lauschke Mar 19 '13 at 17:00
  • 2
    Such postings are very useful, because they put pressure on WRI. They have their priorities misaligned. We don't need that alpha nonsense, we want bug fixes for SERIOUS PROBLEMS (such as lacking encryption). And m.SE is a great platform to discuss such matters. And I had suggested this before, we should create a venue to rank/vote on bugs so WRI learns the users' priorities. On LinkedIn you can create polls on the fly, we should do something similar. If this "encryption" were really all that great, they'd tout it big time. But they don't. And we have other issues that they don't want to fix. – Andreas Lauschke Mar 19 '13 at 17:12
  • 1
    @AndreasLauschke I strongly disagree, and this is not merely a semantic matter. Encode with a specified key absolutely is encryption since knowledge of the key is needed to decode the message (the encoded content does depend on the key, so it is not merely a check to see if the key is correct--I did check this, of course). Not specifying a key (or using a default key, if you prefer) is arguably equivalent to simple encoding, not encryption. But it is not merely obfuscation; it is actually a code. – Oleksandr R. Mar 19 '13 at 17:26
  • See my comment in Murta's answer below. A serious development platform needs equivalent functionality (or better) to industry standard IP protection, not a Batman decoder ring. – Jagra Mar 19 '13 at 17:36
  • @Oleksandr: nope, it's not. It's not already encryption just because you use a key. You can do key-specific encoding. Your sentence "Encode with a specified key absolutely is encryption since knowledge of the key is needed to decode the message (the encoded content does depend on the key" is complete garbage. I can do many nonsense things that depend on keys. You'd have to KNOW what the actual algorithm does, and you don't know that, but I do. I am pretty sure you are not prepared to discuss professional crypto with me. – Andreas Lauschke Mar 19 '13 at 17:43
  • 2
    @AndreasLauschke the RC4 algorithm wasn't known until it was leaked from RSA security. Are you saying that until the leak occurred it wasn't an encryption algorithm? Or are you saying that you know the algorithm used by Encode and that it is not secure? (Here I am concerned about the algorithm, not the implementation--I know full well that the implementation isn't secure.) If the latter it would have been helpful for you to state this earlier rather than making cryptic references to "5 lines of code" &c. And by "decode" of course I do not mean the usual stupid tricks with Locked. – Oleksandr R. Mar 19 '13 at 17:55
  • @AndreasLauschke Do you consider Encrypt from V10.1 an encryption? – Kuba Apr 09 '15 at 13:50
  • @Kuba, sorry for the long wait, I was absent for a while. Yes, the key-based RSA encryption is indeed encryption. Parts of Encrypt seem to be bolted on to OpenSSL, although I can't tell yet to what extent OpenSSL is used. If it's coded correctly, it will probably be all right. A friend of mine informed me that the Windows version doesn't seem to encrypt RSA without the padding routine, contrary to the documentation, but as I'm not a Windows user, I couldn't check that. Tests with PowerMod show that the keys and exponents work correctly, so I'd call it encryption. – Andreas Lauschke Apr 14 '15 at 20:25
  • @AndreasLauschke -- Great news. Many thanks for your contributions to this discussion. Maybe Wolfram would have gotten their on its own, but I think questions, discussions, and criticism like this has help speed the process. – Jagra Apr 17 '15 at 19:05

1 Answers1

7

I believe that this Wolfram video is exactly what you want.

From Wolfram support:

Essentially, the steps are as follows:

1) Place all of the symbol definitions that you would like to obfuscate into a Mathematica package file.

2) For each of these symbols, use the Attributes function to set the Locked, Protected, and ReadProtected attributes after you've defined them.

http://reference.wolfram.com/mathematica/ref/Attributes.html

3) Use Mathematica's Encode function on the package file.

http://reference.wolfram.com/mathematica/ref/Encode.html

4) Copy (as plain text) the entire contents of the encoded file.

5) Paste as a Mathematica string (with escapes inserted) into an ImportString command in the Initialization option to your Manipulate command, like so:

Initialization :> ImportString["PASTE HERE", "Package"]

6) If necessary, re-evaluate any Manipulate commands and deploy your Manipulate object as usual.

The only difference is that, for Enterprise CDF you can use Needs inside the Initialization, instead of past the string, due to the import capability.

Murta
  • 26,275
  • 6
  • 76
  • 166
  • This video appears to predate the release of Enterprise Edition. The blog post describes encrypting code that will then run in a "free" CDF player. This seems like new functionality. I haven't seen this described before the appearance of Enterprise Edition – Jagra Mar 19 '13 at 02:48
  • 1
    I talked about it here – Rolf Mertig Mar 19 '13 at 13:57
  • @Rolf Mertig: For your talk, in my browser the bottoms of many pages are getting clipped (and it's not just an issue of scrolling down). – murray Mar 19 '13 at 15:19
  • 3
    @RolfMertig Thx for the link. Unfortunately, while perhaps technically accurate, WRI's use of the term encrypt (encoding may represent a very weak form of encryption) seems misleading and avoids the key issue. IMHO a serious development tool ought to have IP protection at least comparable to other professional tools. WRI doesn't market Mma as an limited R&D tool. WRI publishes comparisons of speed & code conciseness relative to other languages & platforms. It presents Mma as a development platform. But, if we don't have comparable functionality to protect IP such comparisons seem hollow. – Jagra Mar 19 '13 at 16:11
  • @murray Maybe you have an older CDF Plugin? Try to download the notebook and save it and open it in Mathematica 9. – Rolf Mertig Mar 19 '13 at 16:32
  • @Jagra I don't work for Wolfram. Call them. Though, if you need it very urgently we could probably cook up something as the community. Should not be too hard if one uses some Java solution for, say, a true PGP or whatever encryption of an Encode[]-ed Mathematica package being saved as a Java string. – Rolf Mertig Mar 19 '13 at 16:36
  • @RolfMertig Called Wolfram, awaiting reply:( Your talk & Oleksandr's comments have me thinking. The problem presents some challenges. PGP makes sense, but then, wouldn't one want the Mma kernel to have the private key? I can't think of another solution that would work. When deploying software, one doesn't want the client able to get to source code. I hope I'm wrong (it happens), but for it to work I think Wolfram has to implement it in the kernel. Even then one would have to trust Wolfram, which still presents a problem. It you have some ideas, we could move this to chat. Thx – Jagra Mar 19 '13 at 17:12
  • -1. This is a bad reply, downvoting. It's actually NOT "exactly what you want". a) it's only encoding, not encryption, b) it can be hacked with 5 lines of M code by a pro, c), it was long before the CDF Enterprise Edition came out. – Andreas Lauschke Mar 19 '13 at 17:15
  • @AndreasLauschke: re (b), there is no provided function in M that can convert encoded files back to their original form, and setting Locked/ReadProtected prevents inspection of symbol definitions in the kernel. what 5 lines of "pro M code" are you talking about? – William Mar 19 '13 at 18:24
  • @AndreasLauschke - I humbly request you don't post the 5 lines of code. One has to work with what one has until one has something else. – Jagra Mar 19 '13 at 18:50
  • @AugR: that's EXACTLY the request I've been waiting for: so that I'd disclose it, and then I would be the one who publicly advertises on the web methods to hack into M, thereby indirectly spreading the security hole exploits. Sorry I'll have to disappoint you on your expectation here. Your statement "setting Locked/ReadProtected prevents inspection of symbol definitions in the kernel" is simply not true, plain and simple. It seems you are just regurgitating what others (users, WRI, marketing materials, whatever) have written. It doesn't make it a true statement. – Andreas Lauschke Mar 19 '13 at 18:51
  • @Jagra: no worries, see my other comment. I'm quite critical of WRI's denial of these problems (not just this, there's more), but I'm not malicious. – Andreas Lauschke Mar 19 '13 at 18:52
  • @Jagra and Rolf: what you are discussing along the lines of PGP is similar to my reply on a CDF blog post:http://blog.wolfram.com/2011/07/21/launching-the-computable-document-format-cdf-dont-compress-the-idea-expand-the-medium/ scroll down to "Mooniac". I mentioned GnuPG, which is a particular implementation of PGP. Some people called the CDF useless for corporate purposes, and although that's going too far (I've used it successfully in corporate environments where encryption wasn't needed), the lack of encryption is a VERY RELEVANT barrier to wide-spread adoption. – Andreas Lauschke Mar 19 '13 at 19:32
  • @AndreasLauschke Well written, but in general I think it is not necessary to encrypt the full CDF file. It should suffice to just encrypt the code which goes into the Initialization option of DynamicModule (I never use Manipulate really for anything else than toy stuff). And that might be possible at least in an EnterpriseCDF file already now, with some extra effort. But I have no time, and Andreas seems to not have had time to do it since 2011, too (understandably, since really WRI should do it. And maybe they will, who knows?). – Rolf Mertig Mar 19 '13 at 20:26
  • @Rolf, ok, just encrypting parts of it may do it. But that is the key info. And then you might as well encrypt everything, it's just a string. Once you have your crypto set up in a reliable manner, it doesn't matter if you encrypt a character or a long file because internally it's all done with block ciphers (which use stream ciphers on blocks). – Andreas Lauschke Mar 19 '13 at 20:36
  • @Andreas, sure. BTW, (also @Jagra), why don't you comment something similar as in 2011 here? Andre seems to be in charge now. – Rolf Mertig Mar 19 '13 at 20:42
  • 1
    @AndreasLauschke: Sarcasm noted... Your attachment to security-through-obscurity is misguided, and you should know it. There is no need for you to apologize; I had a feeling the "5 lines" wouldn't be forthcoming, for one reason or another. At the very least, you should send whatever info you might have to WRI so that they might have a better shot at fixing the problem you vehemently allege and (so far) provide absolutely no evidence for. – William Mar 20 '13 at 01:49
  • @AugR: a) I used no sarcasm at all. b) you're talking nonsense about security-through-obscurity, and what you "conclude" about me. c) "There is no need for you to apologize": for once, I agree with you, d) Why do you think I didn't do this already? WRI knows it already, and knew it before I reported it to them (from others). e) I don't need to provide evidence (to you, that is). The professionals whose opinion I care about (WRI and here) expect me NOT to follow your request of disclosure. Chide me for providing no evidence, I am more than A-OK with that! No sarcasm in this one either. – Andreas Lauschke Mar 20 '13 at 03:35