|
|
Q1: What is Unicode?
All Visual Basic® Strings are Unicode Strings. The normal ASCII character set only requires one byte (8 bits) of storage per character. Unicode, on the other hand, requires two bytes (16 bits) of storage per character. The extra byte allows Unicode to represent all characters used in every language (English, Japanese, Hebrew, etc.). Since we only use the ASCII character set the upper byte of each Unicode character is zero. A good overview of the Unicode standard is published on the WWW by the Unicode Consortium.
Q2: Why does DEScipher/OCX always return question marks ("?????....") as the encrypted string?
If we encrypt a Unicode string of eight characters we are actually encrypting 16 bytes of data instead of 8 bytes (see Q1). When we encrypt a Unicode character we encrypt both the upper and lower bytes - as a result the upper byte of that character is (usually) no longer zero. When the encrypted Unicode string is displayed in a text box or written to a file the system tries to interpret each Unicode character as an ASCII character. Since the upper byte is no longer zero the system does not know how to represent the value in the ASCII character set - so a '?' is displayed in place of the undefined character. If you look at the numerical value of each character in the string you will see that they are not truly question marks (i.e. h3F). This will also be apparent if we decrypt the string - the original plaintext will be recovered correctly, and the ASCII characters will display normally.
Q3: How can I avoid the Unicode problem & display an encrypted string?
To avoid the Unicode mess we have to compress the Unicode string into an ASCII string. The most straightforward way to do this is by using the "String Convert" (StrConv) function in VB. A sample project which illustrates the use of the StrConv function is available for download by clicking StrConv Example. A screen shot is shown below:
Most registration problems can be traced to using an incorrect version of one or more of the "dependency" files that ship with the ActiveX controls. It will help if you first understand some of the basics:
Dependency files are DLLs that an ActiveX control "depends on" to function properly in its target environment. If they are not present, or if they are not the correct revision level, a variety of errors may result - including failure to register the ActiveX control properly. For all of Bokler's ActiveX controls, the dependency files are commonly-used libraries (DLLs) produced by Microsoft. The required dependency files are included in Bokler's distribution, and installed on your development PC when the ActiveX control is installed --if-- the version in the distribution is newer than the version currently residing on your system. Dependency files used in Bokler's ActiveX controls vary by product and revision level; this is a function of the OS, and the release/revision level of the C++ compiler used to build that product/revision.
The names of the dependency files are listed in the Developer's Reference Manual for the product you purchased - the revision level is not. Revision levels of the dependency files are typically changed by Microsoft several times over the lifetime of a particular compiler release. As you might imagine, many of your other applications (or controls) also depend upon these same DLLs, and replacing these DLLs with different revision levels might seem to be inviting disaster - in some cases it is. This problem is often referred to as "DLL Hell", and has been extensively documented and discussed. Microsoft has published an excellent article discussing the problem of "DLL Hell", and how they propose to fix it with Windows 2000 (we'll see).
With this background in mind, the following simple procedure will solve most of the registration errors described to us involving the installation of applications that use Bokler's ActiveX controls:
- Identify the required dependency files by name from the appropriate Developer's Reference Manual.
- Locate these files in the Windows system directory on your development PC; make a note of the revision level by checking the DLL's properties.
- Include these files with the distribution for your application.
- Copy these files to the Windows system directory on the target PC if and only if the file in your distribution is newer than the file currently residing on the target. Overwriting a later revision with an earlier revision may well "break" other applications on the target PC, thereby creating "DLL Hell" on the target.
This should resolve most registration problems - in fact, it has resolved all of them to date. Bokler's ActiveX controls have so far had no "backward compatibility" problems; that is, older versions of the control have always worked successfully with newer versions of the dependency files. While this happy situation is not by accident, neither is it a guarantee that future changes made to the dependency files by Microsoft will not break an older version of a Bokler ActiveX control.
We also get a fair number of questions regarding various problems encountered while building installations using the "Setup Wizard" in older versions of Visual Basic. While we cannot provide tech support to resolve issues with Setup Wizard (or other install programs), the following dependency file (.dep) listing is provided as-is. The dependency file lists all of the dependent files used by an ActiveX control (.ocx), version and registry information. You can cut & paste the dependency files for DEScipher/OCX from the text below. Note that the dependency filenames may have to be changed depending the control and version being used.
; Dependency file for setup wizards.
[Version]
Version=5.0.37.14
; Dependencies for DCIPH32.OCX
; Default Dependencies ------------------------------------------------------
[DCIPH32.ocx]
Dest=$(WinSysPath)
Register=$(DLLSelfRegister)
Uses1=MFC40.DLL
Uses2=MSVCRT40.DLL
Uses3=OLEPRO32.DLL
Uses4=
[MFC40.DLL]
Dest=$(WinSysPathSysFile)
Uses1=
[MSVCRT40.DLL]
Dest=$(WinSysPathSysFile)
Uses1=
[OLEPRO32.DLL]
Dest=$(WinSysPathSysFile)
Uses1=
The current 32-bit version of DEScipher/DLL uses the "standard" (aka "Pascal") calling convention which is supported in Visual Basic. Older releases of the DLL used the "C" calling convention, and are not compatible with Visual Basic. All versions of TDEScipher use the "standard" calling convention, and therefore are compatible with VB (see next question).
YES! The 32-bit TDEScipher/DLL control uses the Pascal (aka "Standard") calling convention that is supported in Visual Basic and virtually all other Windows development environments. Sample VB code ships with the TDEScipher/DLL distribution, and the TDESutil project is available for download.
YES! Version 2.1 of the 32-bit HASHcipher/DLL control uses the Pascal (aka "Standard") calling convention that is suported in Visual Basic and virtually all other Windows development environments. Sample VB code ships with the HASHcipher/DLL distribution.
Q8: Can I use DEScipher (or TDEScipher) to encrypt fields in an Access (FoxPro, etc.) database?
Yes. DEScipher/OCX and HASHcipher/OCX are compatible in all development environments which support Microsoft's Component Object Model (COM). An example project developed in Visual Basic for Applications (VBA) illustrating the use of both DEScipher and HASHcipher in MS Access '97 is available for download.
TDEScipher may also be used In VBA applications, and in other development environments such as FoxPro, Power Builder, Delphi, etc, etc. Compliance with COM is not required to use the TDEScipher/DLL, and since TDEScipher supports the Pascal (aka "Standard") calling convention it may be used in virtually all Windows devlopment environment.
Developers should also keep in mind that encrypted data is binary data, and any binary value is possible. This may cause a variety of related problems depending on the characteristics of the database engine, and the receiving field type. For example, some databases interpret "null" (00) as a string terminator, resulting in truncated data being written into the field. Various solutions are available including Base64 conversion, or simply writing a hex string representation of the encrypted data.
Due to recent changes (January, 2000) in the Export Administration Regulations (EAR) you may be able to export applications that use DEScipher or TDEScipher to most users in most countries of the world. These changes have made it easier to export strong cryptographic software that does not incorporate unpopular key escrow features. However, the new regulations still impose requirements you must satisfy, and restrictions you must follow.
If you are interested in exporting your DEScipher- or TDEScipher-based application, and would like for us to prepare and submit the required forms and supporting documentation please contact us for a quote. If you'd prefer to do this yourself you can obtain guidance from the Dept. of Commerce's Bureau of Export Administration's website,
Since HASHcipher does not perform encryption per se, there are no export restrictions on applications that use only HASHcipher.
Q10: Are Message digests calculated by HASHcipher ver 1.x incorrect?
Possibly so! During the HASHcipher validation process an error was identified that affects both the ActiveX and DLL versions of HASHcipher, version numbers 1.3 and earlier. The error results in an output (message digest) which may be erroneous. This error has been corrected in version 2.1 which has received NIST validation. Registered users will receive notification and a free upgrade to HASHcipher ver 2.1; unregistered users must first register, and contact support at bokler dot com to receive the upgrade.
All users should upgrade to the latest version of the product. Note however that since message digests calculated with ver 1.x and 2.x may disagree, end-user upgrades must be planned to accomodate legacy data.
Q12: What are the 16 "weak keys" for DES, and how are they handled?
There are 16 weak keys defined for DES. Weak keys (K) have the property that there exists a dual key (K') for which encryption with K is the same as decryption with K', and vice versa (K and K' are both weak keys). In other words encrypting a message with a weak key K produces the same output as decrypting it with K'. See section 3.6 of FIPS PUB 74 for further details. These weak keys (K and K') are:
E001E00lFl0lFl0l01E001E00lFl0lFlFElFFElFFEOEFEOE1FFElFFEOEFEOEFEE01FE01FF10EF10E1FE01FEOOEF10EF101FE01FE01FE01FEFE01FE01FE01FE01011F011F0l0E010E1F011F0l0E0l0E01E0FEE0FEFlFEFlFEFEE0FEE0FEFlFEF10101010101010101FEFEFEFEFEFEFEFEE0E0E0E0FlFlFlFllFlFlFlF0E0E0E0EThe keys in the last row are unique in that they are equal to their duals (i.e. K = K' ). The result of this is that a message encrypted twice with one of these keys produces the original message!
For security reasons, all of the weak keys are to be avoided. Bokler's TDEScipher and DEScipher controls produce a fault event and/or return an error code (DES_ERRWEAKKEY) if the key used is one of the weak keys.
Q13: I need plain ASCII ciphertext... What can I do about those "gibberish" encrypted characters?
First, some background: The encryption process produces binary data... this is a natural and very desirable result! The designers of DES worked hard to assure that your ciphertext output would be statistically random. Being random means that all possible encrypted outputs are equally likely. Consider the single string character "a" represented internally by 8 bits (1 byte) - if we encrypt this character we get another 1 byte character that depends on the key (and IV) selected. This encrypted character may or may not be an alphanumeric or printable character... it might be the carriage return character, or the backspace character, or any one of the other non-printable characters from the total set of 256 characters that can be formed with 8 bits of data. This is how it should be.
Now despite the fact that the encryption algorithm works as it should there are applications in which it is inconvenient, impractical or impossible to store, process or communicate binary data. Does that mean that you're hosed?... No, it simply means that we need to map or convert the ciphertext into another character set - to be more precise we need to map it into a subset of the total 8-bit character space. This is not new stuff; conversion algorithms such as uuencode and Base64 were developed many years ago to deal with problems associated with transfer of binary data. These same solutions may be applied to ciphertext strings.
If you're working in VB you may want to consider mapping your ciphertext into the hexadecimal character set; i.e 0-9, A-F. While VB has no built-in functions or native libraries that perform Base64 or uuencoding, it does provide the "Hex" and "Chr" functions for working with hexadecimal strings. In hex, each 8 bit character is represented by two hexadecimal characters, so the length of your string will double. For example: a = &H61 (the "&H" is VB notation indicating hex), and backspace = &H08. We've prepared the example VB project HexCiphertext that shows how this is done.
Q14: Can I use Bokler's controls (or DLLs) to encrypt data on Microsoft's IIS webserver using Active Server Pages scripting?
Yes! Perhaps the easiest way to accomplish this is to use Visual Basic with the TDEScipher/DLL (or HASHcipher/DLL) to create an ActiveX dll "wrapper". The ActiveX dll is then installed and registered on the IIS webserver, and may be accessed through an ASP script. See working examples for TDEScipher and HASHcipher. You may also want to check out the CipherLock ASP example.
Copyright ©, 1995-2001 Bokler Software Corp. All rights reserved. DEScipher, TDEScipher and HASHcipher are trademarks of Bokler Software Corp. The "animated_cipher.gif" is copyrighted by Bokler Software Corp. Microsoft, Windows, Visual Basic, Visual C++ and ActiveX are trademarks of Microsoft Corp.
", not this: "
". 