The high quality cryptography provided by FIPS 140-2 validated MOVEit Crypto and its integral use in MOVEit Transfer makes MOVEit Transfer subject to cryptography export controls. It is currently legal to install and use MOVEit Transfer from any country that is not one of countries covered in the U.S. Department of Commerce "Regional Considerations" documents.
The remainder of this document is an abbreviated response to "Control Policy--CCL Based Controls", "Supplement No. 6 to part 742", "Export Administration Regulations". (The full document is on file with the Commerce Department.) By request, it was last updated on May 15, 2002.
MOVEit Transfer and MOVEit Automation.
1. MOVEit Transfer uses:
MOVEit Automation also uses a simple stream cipher to protect passwords stored locally. This is a rotor-based scheme specifically designed to be exportable back around 1990, when regulations were more restrictive.
Aside from the SSL implementation supplied by Microsoft, the products do not use asymmetric encryption.
2. MOVEit Transfer encrypts files with a 256-bit key.
The key management algorithms for SSL are well-documented, and will not be discussed here.
3. The AES algorithm is not proprietary. It has been FIPS 197 validated to work as required by NIST and CSE in their public documents.
(Source code has been inspected as part of the FIPS 140-2 validation process.)
The rotor-based algorithm works as follows:
4. No pre-processing is applied to the data before encryption.
5. For the AES cipher, the ciphertext is prefixed with a 128-byte header used to store a message hash, original message size, and other information that cannot be stored using the underlying operating system file structure alone.
For the rotor-based scheme, as described above, RFC 1113-style printable encoding is applied.
6. TCP and SSL are supported. We rely upon standard Microsoft software already installed on the user's computer.
7. We implement two APIs; both are internal only.
These methods encrypt and decrypt files without having to read the entire file into memory. To accommodate both the ASP and ASP.NET versions of Response.BinaryWrite, Progress | Ipswitch has implemented both BSTR and SafeArray of Byte versions.
8. The API that uses AES is implemented both by static linking, and by a COM object, which is dynamically linked. The same source code is used in either case.
We also use TCP/IP Enterprise Edition from Dundas Software. This software supplies some code in a static library, and some in a dynamic library named UTSecureLayer.dll. The actual encryption code is not supplied by us or Dundas; instead, Microsoft's CRYPT32.dll is used. CRYPT32.dll is dynamically linked and must already be present on the user's computer. (MOVEit products do not install CRYPT32.dll.)
9. We do not use Java byte code.
10. The product is supplied as compiled and linked Microsoft .exe and .dll files. No special checksumming or obfuscation is used to prevent binary editing of the files.
1. - 4. Not applicable - we are not selling components.
1. - 3. Not applicable - we are not attempting to distribute source code.
See Also |