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.

  • 2
    $\begingroup$ 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. $\endgroup$ Mar 18, 2013 at 20:01
  • 4
    $\begingroup$ Well, how can they run the code unless they can decrypt it for that purpose? $\endgroup$ Mar 19, 2013 at 0:05
  • 2
    $\begingroup$ 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. $\endgroup$ Mar 19, 2013 at 17:12
  • 1
    $\begingroup$ @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. $\endgroup$ Mar 19, 2013 at 17:26
  • 2
    $\begingroup$ @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. $\endgroup$ Mar 19, 2013 at 17:55

1 Answer 1


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.


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


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.

  • $\begingroup$ 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 $\endgroup$
    – Jagra
    Mar 19, 2013 at 2:48
  • 1
    $\begingroup$ I talked about it here $\endgroup$ Mar 19, 2013 at 13:57
  • $\begingroup$ @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). $\endgroup$
    – murray
    Mar 19, 2013 at 15:19
  • 3
    $\begingroup$ @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. $\endgroup$
    – Jagra
    Mar 19, 2013 at 16:11
  • 1
    $\begingroup$ @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. $\endgroup$
    – William
    Mar 20, 2013 at 1:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.