Encryption Wizard
Frequently Asked Questions

Download and Installation Issues

My MacOS X says I don't have permission to open the EW .jar file!

There can be two different causes of this error. Depending on what you used to unpack the EW .zip file, the read-only permission flags on the files can sometimes be interpreted on MacOS as "no permission to do anything." Simply select the files, use Command-I to Get Info, and change the Sharing and Permissions access to read and write.

Other users may encounter problems because EW comes from an "untrusted publisher" (that is, the Air Force Research Laboratory instead of the Apple Store). You will need to look under Settings→Security and Privacy for "Allow application downloaded from" and change the value to "Anywhere".

It's 2019 and Java costs money? What?

No, not exactly... well, maybe.

Rather than trying to duplicate a lot of confusing information, we will first refer you to this summary by Trisha Gee writing for JetBrains. The extremely abbreviated overview is that Oracle is changing their license starting with Java 11, and if you use it in a production environment, you need to pay for it (but will get updates and support). There is an open source build also from Oracle, using the same source code, and this can be used for free (but will not receive automatic updates).

Before you feel constrained to choosing between two JDK builds, be aware that there are multiple JDK builds available. Again, rather than trying to duplicate complex information, we will refer you to Stephen Colebourne's excellent survey of JDK builds. That list includes links for downloading each of the available builds. The TENS office generally recommends the OpenJDK builds by Oracle, but be aware of what you are and are not receiving.

The internet says Java is full of security holes! How can I protect myself?

Most of those high-strung web articles are talking about the Java browser plugin, not the underlying Java programming language. These are related, but not the same thing (even if the author of a scare article doesn't know it).

If you visit a webpage with a Java applet on it, the browser plugin is what allows your web browser (Firefox, Chrome, Internet Explorer, Edge, etc) to download and run the applet, using the underlying Java installation on your computer. It's supposed to constrain the applet with restrictions so that the applet can only do very specific limited things. Failure to do so means the applet can go secretly searching through your hard drive, send emails pretending to be you, and generally cause damage.

The highly publicized security flaws in Java have concerned ways in which applets and other "limited execution" programs can break out of the proprietary browser plugin. This has resulted in recommendations to severely limit the plugin's capabilities in your browser, increased warnings from web browsers before they run the plugin, and in some cases discontinuing support for the plugin altogether.

Encryption Wizard makes no use of the browser plugin. You are free to raise the browser plugin security restrictions as high as you (or your network administrators) prefer, or even disable the Java plugin in the web browser entirely. As a standalone Java application, EW merely needs a local Java runtime environment: for example, a "Server JRE" package, which does not contain a browser plugin or any installer helpers, and can be specifically restricted or enabled for a given application. Advanced users can even run EW inside a chroot jail or a container sandbox if you like.

Government FIPS versus Public

I work for the DoD or U.S. Government...

You're required to use FIPS 140-2 validated encryption to protect all your official or sensitive communication. The Government FIPS edition of Encryption Wizard ("EW-Govt") is the version you should be using. The key points to know are:

  1. You will need to either use your CAC to download EW-Govt (this is recommended), or fill out the request form (this goes through a human being and is much slower).
  2. The crypto algorithms of EW-Govt are exactly the same as those of EW-Public, and the encrypted files produced are 100% compatible in both directions. The difference is only in the FIPS 140-2 validation.
  3. You're allowed to give a copy of your EW-Govt to other people if they would be allowed to download and use it in the first place. This generally means military personnel and Federal Government employees.

...but my colleague is an offsite contractor. What now?

Secure communications with people outside the .mil enterprise email servers was why EW was created to begin with. Federal contractors are allowed to download and use EW-Govt too, with some restrictions:

  1. They must be using EW-Govt for an active Federal Government or military contract.
  2. They cannot redistribute EW-Govt, share it on their corporate network, put it up on their company website for downloading, etc.
  3. Other divisions of the same company are not permitted to use EW-Govt. Only the people actively employed on a Federal contract may use it. (The rest of the company is more than welcome to use EW-Public/EW-Unified, however, as they are interoperable.

Bear in mind that contractors who download EW-Govt will need to use their DoD CACs to authenticate. If they are 100% offsite and were never issued a CAC, then filling out the request form is their next step.

We know that these restrictions are cumbersome, but they are imposed on us by the terms of the license of the FIPS 140-2 crypto library.

...and I forgot my password.

Sorry to hear that. We cannot get your data back. No really, Encryption Wizard doesn't have any special master passwords, not even for the Government edition. For this reason, it's wise to always add your own CAC's public certificate as one of the encryption keys, so that you can always use your CAC to decrypt.

If you were using one of the custom Government editions of EW at the time you encrypted the files, and if that custom edition included recovery escrow keys, then all hope might not be lost. Contact the escrow address listed in the 'Help→About' dialog box, or if you no longer have access to the custom edition, contact us and we'll find the right address for you.

...and I want to exchange encrypted files with a Foreign Government Partner.

No problem. Your government office would continue to use EW-Govt, the foreign office would use EW-Public or EW-Unified, and communication is entirely compatible. For that matter, foreign nationsAny nation not in the Export Administration Regulations 740-1 Country Group E:1 can use Public or Unified Editions.

As of December 2016, this excludes Iran, North Korea, Sudan, or Syria.

Cuba is no longer on E:1 but is now on E:2, which may be equally prohibitive. Readers are cautioned that this status may change unpredictably, and are advised to obtain proper legal counsel.
are welcome to use EW-Public or EW-Unified for tasks outside of communication with US Government offices.

While EW-Public/EW-Unified may be shared, you cannot redistribute EW-Govt to Foreign partners, however. This is not a matter of national security; it's simply the terms of the license under which we use the FIPS 140-2 crypto library. We are only permitted to give the library to Federal employees and contractors, and Foreign partners don't fall into that category.

As the editions are interoperable, using combinations of Public, Unified, and Govt should not be a problem. The only issue that might arise is if your EW-Govt has been customized to use escrow keys, in which case you should contact us.

EW does not enforce any specific requirements about running in the 'en_US' locale, or typing passwords with an English keyboard, etc. However, it has not been localized to any languages, and receives minimal testing for execution environments outside of 'en_US'. That said, if EW actually crashes under a non-English locale, that's definitely a bug and should be reported.

...and my EW doesn't look like the screenshots in your manual.

If your copy of Encryption Wizard Government Edition has been customized, it's entirely likely that the menus are a little different. That's to be expected and is not a bug. If you are not certain whether your edition is customized, it's easy to check:

  • in the GUI, look under 'Help→About'
  • on the command line, run with --version
The text there should be self-explanatory in case of a custom build. For a more precise but less user-friendly check:
  • in the GUI, look under 'Help→System Info'
  • on the command line, run with --sys-info
In the first block of text, a Configuration Short Name of anything other than 'standard' indicates a custom build.

Operational Issues

Why can't Encryption Wizard read my CAC/PIV/smartcard?

Java, smartcard enablers, and CACs are a fragile combination.

Make certain your smartcard middleware is properly configured. Getting this wrong can lead to endless frustration, including a smartcard reader that works for some software some of the time, but not all software all of the time. Read through the advice on MilitaryCAC.com and don't skip any of the steps.

Check the smartcard library configuration inside EW. This is done inside the Wizard GUI under the Tools menu. You need to know which library to tell Java to use to see your smartcard reader. If you've already made changes here and want to start over, the easiest way is:

  1. Under 'Tools→Platform Support', choose 'Open Application Data Location'. This should open a file manager to the correct folder for your operating system.
  2. Exit Encryption Wizard.
  3. Delete the saved smartcardlibs.xml file. This file is stored in a subfolder whose name is based on your edition of EW; for most people this will be "config-standard".
  4. Start Encryption Wizard.

Why is the 256-bit AES option disabled?

If you are using Sun/Oracle's JRE prior to late Java 8, you will need to install "unlimited strength jurisdiction policy files" to unlock this capability, due to U.S. export laws. The specific files for your country are available from http://www.oracle.com/technetwork/java/javase/downloads/index.html.

If you are using a standard Java installation on your computer, then replacing the policy files will require administrative/elevated permissions. You will need to contact your IT staff. If instead you are using Oracle's "Server JRE" that can be unpacked in a user-writeable folder, then modifying the Java installation requires no extra permission.

If you are using a different JRE than Sun/Oracle's (for example, OpenJDK/IcedTea), then special policy files are often not required. The official Sun/Oracle JRE no longer requires special policy files starting towards the end of the Java 8 patches (essentially "Java 9 and later").

The maximum key strength is determined when EW starts up, so if you replace your policy files you will need to restart EW. You'll know if the correct policy files are in place using the Advanced Options window, or on the command line with the --cryptotest option.

Be aware that Oracle's usual update process will revert your policy files to the default "limited strength" variant. The good news is that the downloadable policy files remain the same for the lifetime of the Java major version (i.e., one set of policy files for Java 7, one set for Java 8, etc, no matter how many smaller patches are released in that time), so they do not need to be downloaded each time, only copied back into place. If you have automated administrative remediation scripts, a hash-based file comparison should suffice to trigger the copy.

Feature-related Questions

Can I make a self-extracting encrypted file?

Not yet. It's on our shopping list as a potential feature, but we have no immediate plans to implement it.

We may implement a self-extracting encrypted JAR file at some point, in which only the decryption functionality of EW is embedded. Having Java already available would still be required. Again, this is not in our immediate plans.

A completely self-contained executable is very unlikely for now. The EW code is fairly small, but embedding enough of the required JRE to function would bloat an executable considerably, even with wrapper technology. We will revisit this topic now that the JRE is split into more modular pieces, once time and resources permit. (The linked articles are by the Java Chief Architect at Oracle.)

Common Issues, Known Problems, Other Questions

What kinds of certification or accreditation does EW have?

Both EW-Govt and EW-Unified use FIPS 140-2 certified crypto libraries. EW-Public uses the crypto library already present as part of your Java SE installation, with the same key strength and crypto algorithm, but no formal certifications.

EW-Govt is certified for use on AFNET NIPR and SIPR systems. The certification memo is available via the "DoD Portal" link on the left-hand sidebar, which requires a CAC/PIV to authenticate.

Can I use EW for PII or HIPAA data?

Yes. If you are required to meet Federal requirements for information protection, then you will likely need to use EW-Govt or EW-Unified. (All of the editions use strong enough crypto for this purpose, but those two are the only editions with the paperwork to prove it.)

You will also be required to make good decisions regarding the encryption keys. If you are using one or more passphrases as keys, each passphrase ought to be at least 14 characters in length.

Why can't I use a smartcard under 64-bit Microsoft Windows?

Java doesn't support them up through Java 7. Beginning in Java 8, smartcard PKCS#11 support is present for 64-bit Windows. If you can't upgrade to Java 8, options include

I got an Error 17 while decrypting this enormous file. Why?

This is a false positive while performing a particular integrity test during decryption. It can appear when using the Government FIPS Edition on files that are typically several gigabytes in size.

During extensive testing, the output data files resulting from the decryption have always been bit-for-bit identical to the input files before encryption, even when the FIPS crypto library claims otherwise. There are also other additional integrity tests during decryption which, in the case of actual file corruption or tampering, would have raised red flags; none of these tests fail. We have no evidence that decryption of very large files produces any actual errors, and no reason to suspect that this is not a false positive.

Knowing about the bug is one thing; preventing it is another. In the interest of full disclosure, when Encryption Wizard detects that a false positive error has occurred, it will by default present you with an Error 17 message anyhow, and ask whether to ignore it.

If actual file corruption is detected, EW will not ask what to do; it will simply delete the corrupted output file and notify the user.

How do I know your software isn't full of backdoors?

Because doing so would violate principles of enlightened self-interest in exchange for no benefit. In other words, "we don't do that because that would be dumb." But, a little paranoia is healthy on the 21st century internet, so more detail follows. Concerns about violating trust tend to fall into particular areas:

Flawed AES

Encryption Wizard Public Edition doesn't provide its own implementation of AES, it just uses whatever is supplied by your Java Runtime Environment. If you are using the JRE from Oracle, then (beginning with Java 7), the open-source OpenJDK is the reference implementation.

For Encryption Wizard Government FIPS Edition, the AES implementation is provided by the JSAFE/BSAFE library from RSA Security, and is FIPS 140-2 validated.

Encryption Wizard Unified FIPS Edition includes an AES implementation publicly available from The Legion of the Bouncy Castle, and is FIPS 140-2 validated.

Cracked AES

The AES algorithms and their underlying Rijndael ciphers are well known, publically available, and extensively analyzed. No feasible attacks against AES have yet been demonstrated. The attacks which have been published to date fall into two broad categories. The first are academic/theoretical (in which the actual attack would take millennia, require calculating power that makes a Star Trek computer look like a microwave oven, or both). Technically this is faster than brute-forcing the keys, but still not practical.

The second are contrived attacks which among other things require access to the computer performing the ciphers (for example, malicious software already installed). An easy way of sidestepping that scenario for Encryption Wizard is to boot from trusted read-only media and avoid the local hard drive entirely.

NSA, Weak Algorithmic Constants, Various Sneakiness

Encryption Wizard makes no use of the Dual_EC_DRBG random number generator. Other elliptic curve algorithms are available in the keypair generator tool, but those (a) have never been shown to be compromised, and (b) are not used in the encryption routines themselves.

Privacy Violations

Encryption Wizard does not collect personal information nor upload any data to government computers. We don't collect usage statistics, even anonymously.

Some concluding observations from a pragmatic point of view: