Compliance
Published
A form arrives from someone in legal or trade compliance, and one line on it asks whether the product contains, uses, or is designed to use encryption. Your build applies a code protection step. Somebody has described that step as encrypting the strings, so the form now looks harder than it is. The way out is to describe what the software actually does, in words chosen before any of it was marketed.
Why a code protection step ends up on a trade compliance form
Cryptography has been treated as a dual-use technology for decades, which means software containing it can attract controls that ordinary software does not. Most jurisdictions run some version of this, and the practical consequence for a software vendor is a questionnaire before a release goes out, asking whether the product contains encryption and if so what kind.
These forms are usually completed by engineers who did not write them and read by compliance staff who did not write the software. The hazard is a vocabulary mismatch in the middle. A form asking about encryption means the established technical sense: an algorithm and a key, where withholding the key withholds the content. An engineer scanning a build configuration and finding an option named for encryption can reasonably tick the box, and everything downstream then proceeds from an inaccurate premise.
Getting this right is worth a little care, because the cost is asymmetric. Answering carelessly in the permissive direction risks a compliance failure, and answering carelessly in the restrictive direction generates work, delay and sometimes a classification you then have to live with on every subsequent release.
A transform that ships its own decoder is not cryptography
The determining question is not how unreadable the output looks. It is whether anything is withheld from the recipient.
Consider what a string protection option actually emits. The string table stops being an array of literals and becomes a call to a generated decoder, and the arguments to that call are the packed literal together with the numeric parameter that unpacks it. Both are written into the same expression, in the same file, delivered to the same browser. There is no key held anywhere else, because there could not be: code that has to run in a browser without calling home must carry everything it needs to execute, and that includes any means of recovering its own literals.
So the transform is a permutation over characters with its parameter travelling alongside the data. That is a reversible encoding by construction rather than a weak cipher, and the distinction is categorical rather than a matter of degree. There is no key, no key management, and no confidentiality property to classify.
The closely related question of whether any of this could satisfy a cryptographic requirement, and why validation attaches to a module rather than to a technique, is answered on the FIPS 140-3 page. This article is about a different regime with a different purpose: classification for distribution rather than validation for assurance.
Where genuine cryptography does appear
It would be misleading to stop at the transform, because the toolchain does use real cryptographic primitives elsewhere, and an accurate answer accounts for them rather than omitting them.
Release signing generates an Ed25519 key pair and produces an EdDSA signature over a manifest of SHA-256 file digests, which is what lets a recipient confirm that the artefact they hold is the one that was published. Watermarking computes an HMAC-SHA256 signature over a plaintext tag, so that a marker attributing a build to a particular recipient is hard to forge. Both are conventional, publicly specified algorithms, and both are computed by the cryptographic library of whatever runtime you are executing on rather than by a bundled implementation.
It is worth noticing what these are for. Signing and hashing establish integrity and authenticity, which answer the question of whether something was altered or who produced it. Neither of them conceals anything, and questionnaires frequently have separate treatment for authentication and integrity functions than for confidentiality. Describing the function precisely, rather than reaching for the word encryption because cryptography is involved, is what lets the person assessing the form apply the right part of it.
The classification problem you can author yourself
Here is the failure mode worth guarding against, and it originates in your own copy rather than in any regulation.
If your datasheet says your product encrypts the application code, your export questionnaire will be completed from your datasheet. The compliance team has no independent way to know that the word was doing marketing work rather than technical work, and they are being appropriately careful when they take it at face value. You can end up asserting a capability you do not have, in a document with legal weight, on the basis of a sentence somebody wrote to make a feature sound stronger.
The same word causes trouble in the other direction too. A customer reading encrypt in your materials may conclude that shipping a secret in the bundle is now acceptable, which it is not, and that misunderstanding surfaces later as an incident rather than as a question. Keeping the vocabulary accurate is not pedantry here; it is the thing that prevents both problems.
The practical remedy is a single consistent description of what the protection step does, reused verbatim across the website, the datasheet, the security questionnaire and the trade compliance form. Anywhere those four disagree is somewhere a reviewer can find a discrepancy, and discrepancies attract exactly the kind of attention you were hoping to avoid.
What to write, and who has to sign it
A useful answer describes function rather than product category, in a form somebody else can verify. For a build-time protection step that means: it is a source-to-source transformation applied during the build, it renames identifiers and re-encodes literals with the decoding parameter emitted alongside the data, it holds no keys, it performs no confidentiality function, and it is absent from the running application.
For the signing and watermarking features, describe them separately and accurately: EdDSA signatures over SHA-256 digests for release integrity, and HMAC-SHA256 for watermark authenticity, computed using the host runtime’s cryptographic library. If your own application ships cryptography of its own, that is yours to declare and has nothing to do with the protection step, which is a distinction worth drawing explicitly since the two arrive on the same form.
Then hand it to the people whose responsibility it actually is. Classification and licensing decisions rest with the exporter, informed by counsel who know your jurisdictions, your destinations and your product. Nothing on this page is legal advice and none of it substitutes for that determination. What an engineer can contribute, and what is genuinely valuable, is an accurate technical description that the determination can be made from.
The short version
Export questionnaires ask about encryption in the strict sense of an algorithm plus a withheld key. A code transform that emits its decoding parameter in the same expression as the data withholds nothing and is a reversible encoding, not a cipher. Real cryptography appears in the toolchain for signing and watermarking, which are integrity and authenticity functions computed by the host runtime’s library. The most common way to create a problem here is to call a transform encryption in your own marketing and then complete a legal form from it.
Frequently asked questions
Does obfuscating JavaScript count as encryption for export control?
Not in the sense these questionnaires use, because nothing is withheld from the recipient. A string protection option emits the packed literal and the numeric parameter that unpacks it as arguments in the same call expression, delivered together in the same file to the same browser. Code that must run without calling home has to carry the means of recovering its own literals, so there is no key and no key management to describe. That makes it a reversible encoding rather than a cipher. Your own counsel makes the classification, but that is the technical fact it rests on.
Our build configuration has an option with encrypt in the name. Does that matter?
It matters only in that it causes exactly this confusion, which is why it is worth describing the behaviour rather than quoting the option name on a compliance form. The option packs a string table and emits a call to a generated decoder, with the decoding parameter passed alongside the packed data in the same expression. An option name is a label chosen for a user interface. A trade compliance form is asking about function, and the function here conceals nothing.
You use Ed25519 and HMAC-SHA256. Should those be declared?
Describe them accurately and let the people completing the classification decide, which is easier for them when the function is stated precisely. Release signing produces an EdDSA signature over a manifest of SHA-256 digests, and watermarking computes an HMAC-SHA256 signature over a plaintext tag. Both establish integrity or authenticity rather than confidentiality, both use conventional publicly specified algorithms, and both are computed by the cryptographic library of the host runtime rather than by a bundled implementation. Questionnaires often treat authentication and integrity functions differently from confidentiality, which is why the distinction is worth making rather than collapsing everything into the word encryption.
Can we just say our product contains no encryption at all?
Only if that is true of the whole product, which for most vendors it is not. Your application almost certainly uses TLS, may hash passwords, and might ship cryptography of its own, and all of that belongs on the form independently of the protection step. The accurate position is usually that the build-time transform performs no cryptographic function, stated separately from whatever your application itself does. Collapsing the two into one answer in either direction is how these forms go wrong.
Who is responsible for getting the classification right?
The exporter, advised by counsel familiar with the relevant jurisdictions and destinations. A software vendor cannot outsource that determination to a documentation page, and this article does not attempt to make it. What an engineering team can usefully supply is a precise description of what the software does: what the transform emits, whether any key exists, which cryptographic primitives appear elsewhere in the toolchain and what they are for. Accurate inputs are what make a sound determination possible.
Why does the wording in our marketing matter for this?
Because the form gets completed from your own materials. If the datasheet says the product encrypts application code, the compliance team has no independent way to know the word was chosen for emphasis, and being careful they will take it literally. You then assert a capability you do not have in a document that carries legal weight. The same word misleads customers into thinking a bundle can hold a secret. One accurate description, reused across your website, datasheet, security questionnaire and trade compliance form, removes both problems and any discrepancy between them.
Related reading