HMAC Hex Key Ambiguity

This happens all the time..

Quite often, a service provider will provide instructions for HMAC generation, and will provide a hexadecimal HMAC key in the example, such as:


This is implicitly ambiguous because there are two ways to interpret the instructions:

1) The HMAC key is composed of the ascii bytes ‘0’, ‘1’, ‘A’, ‘0’, ‘2’, ‘5’, etc. In other words, the HMAC key is 0x30, 0x31, 0x41, etc.


2) The HMAC key is composed of the bytes represented by the hex string. In other words, the HMAC key is 0x01, 0xA0, 0x25, etc.

Both can be accomplished using Chilkat.
For the #1 case, one would call

crypt.SetMacKeyString("01A0251D … 67CDFDEBCD")

For the #2 case, one would call

crypt.SetMacKeyEncoded("01A0251D … 67CDFDEBCD","hex")

Java to copy byte[] to/from a CkByteArray

The Chilkat online reference documentation for the CkByteData class, concerning the methods for copying Java byte arrays into and out of a CkByteData object, are incorrect.

This is the correct way to do it:

CkByteData byteData = new CkByteData();

// Create a Java byte array with some bytes..
byte[] myData = "Any String you want".getBytes();

// Copy the bytes from the Java byte array into the CkByteData.

// Copy the bytes from the CkByteData to a new Java byte array.
byte[] myData2 = byteData.toByteArray();

Hints for Minimizing Size of Windows CE 6.0 EXE in Visual Studio 2008

Chilkat continues to support (and will continue to support for many years to come) older development environments and platforms. The C++ lib for Windows CE (specifically for VS2008) is one such case. The size of the EXE in this environment can matter. Here is one customer’s helpful hints on how to reduce the size of the EXE when building/linking:

Hints for Minimizing Size of Windows CE 6.0 EXE in Visual Studio 2008

Using the Chilkat ActiveX in VB6

To use the Chilkat ActiveX in a Visual Basic 6.0 program, review each of these items to make sure you’re doing everything correctly:

  1. Make sure you’re using the 32-bit ActiveX, even on 64-bit Windows.
  2. The ActiveX must be registered (via regsvr32) on each computer.  If you’re having trouble, try using the .msi installer available here: Chilkat 32-bit ActiveX MSI Installer
  3. The ActiveX should be added to the VB6 project by adding a reference.  Add a reference from the VB6 menu “Project–>References”.  Do NOT “add the component”.  Do NOT add the ActiveX via the “Project–>Components…” menu item.  You should NOT see anything added to the VB6 palette.  The Chilkat objects are non-visual and should always be instantiated dynamically using the New keyword.  Do NOT drag-and-drop a Chilkat object onto a form.  (This should not be possible if you’ve only added a reference.)
  4. If the first method call on an object crashes, check to see if the object was created.  Check to see if the variable is Nothing prior to calling the method.  If there is still a problem, check to see if you can examine the Version property.  All Chilkat objects have a Version property.  If the access to the Version property crashes, the ActiveX object was never instantiated.  It may not be registered correctly, or your program may have never created an instance via the New keyword.
  5. If you see a .oca file, this is not something provided by Chilkat.  It is something VB6 generated.  If you recently updated to a new version of the Chilkat ActiveX, delete the old .oca.

Chilkat Binary Encoding List

Throughout the Chilkat API there are method arguments and properties to indicate an encoding. These are encodings for binary data such as “hex”, “base64”, etc.

Note: These are not character encodings. A character encoding, such as “utf-8” indicates the byte representation of a character. A binary encoding, such as “base64”, represents non-character binary data in printable string form.

Wherever an encoding method argument or property exists, the list of valid encodings supported by Chilkat are as follows:

  • base64
  • hex
  • modbase64
  • base64url
  • base32
  • base58
  • uu
  • qp (for quoted-printable)
  • url (for url-encoding)
  • Q (for MIME Q-Encoding)
  • B (for MIME B-Encoding)
  • url_oauth
  • url_rfc1738
  • url_rfc2396
  • url_rfc3986
  • fingerprint (added in Chilkat v9.5.0.55)
  • decimal (added in Chilkat v9.5.0.55)
  • eda (added in Chilkat v9.5.0.65, for encoding/decoding to the UN/EDIFACT Syntax Level A character set)
  • json (added in Chilkat v9.5.0.66, for escaping and unescaping JSON strings)
  • decList (added in Chilkat v9.5.0.66. See the notes below.)
  • base64_mime (added in Chilkat v9.5.0.67. Same as “base64” but the output is in lines just as it would appear in MIME or in a PEM.)

Chilkat is case-insensitive for recognizing an encoding by name.  For example “Base64” and “base64” are both recognized as “base64”.

The “fingerprint” encoding is a lowercase hex encoding where each hex digit is separated by a colon character.  For example: 6a:de:e0:af:56:f8:0c:04:11:5b:ef:4d:49:ad:09:23

The “decimal” encoding is for converting large decimal integers to/from a big-endian binary representation.  For example, the decimal string “72623859790382856” converts to the bytes 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08.

The “decList” encoding is for converting comma-separated lists of decimal integers to bytes and back.  For example, “84, 104, 101, 32, 116, 114, 117, 101, 32, 115, 105, 103, 110”.  Each decimal integer is a value from 0 to 255.

Mismatch between the processor architecture of the project being built “MSIL” and “AMD64”

For the following Visual Studio warning, see

There was a mismatch between the processor architecture of the project being built “MSIL” and the processor architecture of the reference “ChilkatDotNet45”, “AMD64”. This mismatch may cause runtime failures. Please consider changing the targeted processor architecture of your project through the Configuration Manager so as to align the processor architectures between your project and references, or take a dependency on references with a processor architecture that matches the targeted processor architecture of your project.

Chilkat v9.5.0 Release Notes

* As with any new release, some fixes occur deep within the internal Chilkat code base and are applicable to many classes/objects.  These are labeled as “Internal” fixes.

FTP2: Fixed XCRC problem.

HTTP: Added  the AwsEndpoint property.  This is the regional endpoint (domain) to be used for Amazon S3 method calls.  The default value is “”.  This can be set to any valid Amazon S3 endpoint, such as “”, or the endpoints for S3-API compatible services from other different providers.

HTTP/Upload: Added the Upload.Expect100Continue boolean property.  Also modified the HTTP class so that if the “Expect: 100-continue” header is included, then the intermediate HTTP response is first received before continuing with sending the data of the HTTP request.

Zip: Fixed a ZipEntry problem.  If an existing .zip is opened, and an entry’s Filename property is modified, then the re-written .zip did not have the updated filename.  Also fixed a ZipEntry.ReplaceString problem.

TAR: Fixed long path problem with the ustar format.

MHT: The Mht.UseCids property will now default to False because using Content-Location seems to be more robust than using Content-ID for embedded images. (IE showed broken images even though the Content-ID and “CID” URLs were correct.)

UnixCompress: Fixed an uncompress problem.

Zip: The Encryption property did not initialize when a .zip is opened. (Technically, a zip archive may have entries with different properties.  Each entry within a zip is independent of the others.  There is nothing to prevent some entries from being encrypted, while other entries are unencrypted.  The typical behavior is that all entries are encrypted or unencrypted, but this is purely as a result of the common behavior found in zip utility programs.  Therefore, the Zip.Encryption property is set to the value of the 1st non-directory entry found within a .zip that is opened.

IMAP: In some rare cases, when downloading an email excluding attachments, such that the email has a zero-length body, then the email download hangs (until a timeout) and the download fails.

Android/iOS C/C++:  Added the “C” functions and includes to the iOS and Android C/C++ libs.

IMAP: Fixed problem with FetchBundle when downloading emails and excluding attachments.

SSH Tunnel: When a CHANNEL_CLOSE is received from the SSH Server, the tunnel is now closed.

FTP2: Directory listings missing user/group information are now correctly handled.

SFTP: Fixed rare problem with DownloadFileByName that caused a hang.

HTTP: Params added by the HttpRequest.AddParam method were not added to the “start line” for text/xml or other types of requests.

Objective-C: PercentDone events for MailMan, Zip and Ftp2 fixed.

Internal: For domain lookups, only IPv4 was used.  Now both IPv4 and IPv6 is possible, with preference automatically given to IPv4.  A new PreferIpv6 property will become available at some point in the future to allow preference to be given to IPv6 if both types of addresses are available.

SFTP: Fixed potential multi-threading problem with SFTP downloading of files.

SFTP: Improved memory usage for the ReadDir method.

FTP2: Added the SyncMustMatch and SyncMustNotMatch properties.

Email Object: Removed the SetFromMimeObject and GetMimeObject methods.

This is to eliminate the linkage between the Mime and Email objects which can result in much larger executables for apps linking with C/C++ libs (such as iOS). Existing apps that used these methods should instead accomplish the same in 2 steps: (1) Get the MIME as a string, (2) Load the object from the MIME string.  This is effectively what was happening in the removed methods, so there is no performance loss — it’s simply a matter of replacing 1 line of code with 2 lines of code..

MHT: Removed the GetEmail, GetMime, and HtmlToEmail methods because these return objects and cause much larger executables for apps linking with C/C++ libs.  Removing these methods disconnects MHT from Email/MIME objects for smaller executables which is important in some environments.  The same workaround as described above can be used to accomplish the same: (1) call the method that returns the MIME string, such as GetMHT or GetEML, and then (2) load the MIME string into a new instance of an Email or Mime object.

HTTP: Fixed a case in HttpRequest.AddHeader where an extra SPACE char was getting inserted after a semicolon in some header field values.

Delphi DLL (non-ActiveX):  The *.pas sources now include the Chilkat DLL in this way:


The file is a single location where the path to the Chilkat DLL may be modified.  It contains this:

const DLLName = ‘ChilkatDelphiXE.dll’;
const DLLName = ‘ChilkatDelphiXE64.dll’;
const DLLName = ‘ChilkatDelphiXE.dll’;  //Older versions of Delphi

Zip: The OpenFromWeb method was removed.  There are two reasons: (1) The HTTP related functionality creates dependencies on all that is related to HTTP/SSL/encryption/etc. which greatly expands the size of any EXE using zip functionality, and this is undesired on mobile platforms.  (2) The HTTP functionality is oversimplistic, because it lacks many features (such as proxies, and other HTTP complexities) that might be required.  It is better if a program separately uses the Chilkat HTTP functionality to download a .zip (into memory or into a file) and then open it with Chilkat Zip.

Zip: Removed the Proxy property, which only applied to OpenFromWeb.

Socket: Removed the BuildHttpGetRequest method to eliminate the Socket–>Http dependency, to help reduce size of C++ builds.  The HTTP API can instead be used to create HTTP GET requests.

Events:  C++ event callbacks have been modified to used 64-bit integers where appropriate (CkZipProgress, and others).  When using inheritance for event callbacks, such as w/ C++, check to make sure your derived class matches the method signatures that are now 64-bit.  One way to ensure that your event callback classes correctly match the base class method signatures is to declare methods using the #define’s found in the Ck*Progress.h headers.  For example:

void BeginDownloadFile(const char *pathUtf8, bool *skip);\
void EndDownloadFile(const char *pathUtf8, __int64 numBytes);\
void VerifyDownloadDir(const char *pathUtf8, bool *skip);\
void BeginUploadFile(const char *pathUtf8, bool *skip);\
void EndUploadFile(const char *pathUtf8, __int64 numBytes);\
void VerifyUploadDir(const char *pathUtf8, bool *skip);\
void VerifyDeleteDir(const char *pathUtf8, bool *skip);\
void VerifyDeleteFile(const char *pathUtf8, bool *skip);\
void UploadRate(__int64 byteCount, unsigned long bytesPerSec);\
void DownloadRate(__int64 byteCount, unsigned long bytesPerSec);

FTP2: Directory listings are now guaranteed to be transferred in binary mode to avoid certain charset/interpretation problems.

Zip: The AppendAnsi and AppendUnicode are removed because AppendString2 encompasses the same functionality and more.

CkZipProgress: Added the isDirectory arg to ToBeUnzipped and FileUnzipped callback methods.  This corrected a discrepency between the callback function definitions in different programming languages.

RSA: For OAEP signatures, fixed a problem in verification for signatures (where the last byte was 0xBC but just by chance..)

HTTP: HTTP requests are automatically re-tried if the request was sent on an open/persistent connection, but the disconnected state is not found until trying to read the response header.

TAR: Fixed a problem with writing 8GB or greater size files (not the size of the entire file, but when a single file contained within the TAR is 8GB or greater).

Delphi ActiveX: All object creation is now uniform and consistent.  This is reflected in the online examples an reference documentation.

Email: Fixed this problem: If text/csv attachments used non-usascii chars, then the bytes within the attachment were converted to the charset of the email (treating the attachment content like the text/plain or text/html body of the email.

MessageSet: The ToString method was renamed to ToCommaSeparatedStr because “ToString” has conflicts in the .NET environment.

Email Object: The GetLinkedDomains method was modified to return a CkStringArray object instead of passing by reference.

FTP2: The UploadRate/DownloadRate properties were renamed to UploadTransferRate/DownloadTransferRate because the names conflicted with events having the same names.

SFTP: Fixed a ReadDir internal parsing problem when FXP_NAME’s have extensions (rare).

SFtpFile: The FileType property never returned symLink, charDevice, blockDevice, fifo, etc.

Single-DLL ActiveX: Most ActiveX object names ending in “2” are changed so that the “2” is removed: MailMan, Email, EmailBundle, Zip, ZipEntry, Charset.   The Crypt2 and Ftp2 remain as-is because these agree with the names used in the other programming languages.

IMAP: Fixed rare IMAP response parsing problem.

Single DLL ActiveX methods removed:
** These are changes in the Single-DLL ActiveX.  The individual (deprecated) ActiveX DLLs are unchanged.
MailMan: VerifyRecipients, NewEmail, NewBundle
ZipEntry: InflateToString, InflateToString2, InflateToString3 (use UnzipToString instead)
Xmp: NewCkStringArray
Xml: CompressNode/DecompressNode (use ZipContent/UnzipContent instead)
Xml: CompressSubtree/DecompressSubtree (use ZipTree/UnzipTree instead)
Xml: DecryptNode/EncryptNode (use DecryptContent/EncryptContent instead)
Xml: LoadXmlV
Upload: VariantToString
StringArray: Intersect (use Subtract instead)
Spider: Sleep (use SleepMs instead), GetDomain (use GetUrlDomain instead)
Bounce: Removed ActiveX’s ExamineMail (use ExamineEmail instead)
Imap, Http, Ftp2: Removed unused last arg from SetSslClientCertPfx in ActiveX
Cert: IsExpired — use the Expired property instead.
CertStore: LinkForSigning (no longer needed)
Charset.UrlDecode — use UrlDecodeStr instead.
Emailbundle.AddMime –> AddMimeBytes (this is an ActiveX only method..)
Email.AddRelatedData method reverses args to conform with .NET, C++, etc.
Email.LoadTextFileToUnicode removed — use CkString.LoadFile instead.
KeyContainer.GetContainerName removed — call GetNthContainerName instead.
HttpRequest.Serialize removed
HttpResponse.Serialize/Unserialize removed
Ftp2: DllInfo/DllPath properties removed.

MHT: Will not modify image URLs with query params if they are not to be embedded.

HTTP: Various issues with proxy authentication resolved.

IMAP: Added new methods to the Mailboxes class/object: GetFlags,GetMailboxIndex,GetNthFlag,GetNumFlags,HasFlag

IMAP: Added the Capability method.

Internal: For SSL/TLS channel closure, if initiating the shutdown, Chilkat will now wait for the close notify alert response from the server after sending its close notify alert (for a cleaner shutdown)

Internal: Fixed ipv6 hostname issues w/ HTTP where the IP address was being truncated at the 1st colon character.

DKIM: Fixed DKIM problem where a null byte was sometimes added to the MIME when AddDkimSignature was called.

Objective-C: The Objective-C API now has the full set of event callbacks making it identical to the C++ API.

TAR/Gzip: Fixed problem in UnTarGz where an improperly terminated tar archive (i.e. a corrupted archive) caused in infinite loop within Chilkat.

Zip: Fixed QuickAppend for when the .zip grows beyond 4GB to automatically use ZIP64 format.

C++: Added the CkBaseProgress class as the base class for progress events (Ck*Progress).   All future Chilkat C++ classes will (try to) use only the standard CkBaseProgress events rather than having events specific to each class/object.  Therefore, if a new Chilkat class, named “Abc” is created, then the corresponding event class will be CkBaseProgress instead of CkAbcProgress.   If for some reason special events are needed, then a CkAbcProgress class can be added that derives from CkBaseProgress.  The event callbacks in the CkBaseProgress could also be extended in the future.

MHT: The “DownloadingUrl” event is removed from CkMhtProgress because it was only present in the C++ API and not in .NET or ActiveX.  It is
now a “ProgressInfo” event with the tag “DownloadingUrl”.

C++: Methods that passed binary bytes as a combination of “const unsigned char *pByteData, unsigned long szByteData” are changed to conform to the standard of passing a CkByteData reference instead.   (A CkByteData can “borrow” data to avoid memory-to-memory copying.)

The following methods were modified:
— for AddDataAttachment, in the ActiveX the order of the args reverses to agree with other languages.
— The Objective-C arg names change.
CkEmail::GetMbHeaderField2 is removed.
CkEmail::GetMbHeaderField args change to: fieldName, charset, returns bytes.
CkSocket::AsyncSendBytes  (Objective-C arg name changes)
CkSocket::SendBytes  (CkSocket::SendByteData removed) (Objective-C arg name changes)
Removed CkZip::AppendData2 (use AppendData instead)
CkZip::OpenFromMemory (Objective-C arg name changes)

Internal: Fixed URL parsing where a URL ending with a port number, such as “”, without any final forward slash char, the port number did not get parsed.

CSV: Fixed issue with backslash chars (double backslash must be used for input, but leading backslash needed to be removed when fetching content)

IMAP: Fixed problem with downloading emails without attachments.  In some cases, attachments were downloaded that should not have been.

IMAP: Fixed ListMailboxes for a case where a non-use-ascii string is passed for the wildcardedMailbox.

Internal: Fixed a rare iso-2022-jp charset conversion problem.

Email Object: The EmailDate and LocalDate will now both return local times.  The reason is that for anything returning a date/time in SYSTEMTIME, it will always be a local time. However, the SYSTEMTIME methods are deprecated and will not be used in new Chilkat classes or components.  The methods that use CkDateTime objects should be used instead.

Zip: Fixed problem  when re-writing zip archives having internal data descriptors.

Internal: Fixed problem with zero-length PFX/P12 passwords.

SSH/SFTP: IF the SSH password is empty, and keyboard-interactive is allowed by the server, then keyboard-interactive is chosen over password authentication.

MIME/Internal: Fixed Q/B decoding which could result in extra SPACE chars getting inserted into a MIME header.

MHT: Added code to recognize jpeg/exif and other types of jpg variants.

Email Object: SetReplacePatterns did not replace all possible header fields.

FTP2: The XML returned by DirTreeXml now includes size and last-modified date/time as XML attributes for each file.

Internal (Windows-only): SSL/TLS implementation may now be able to use client-side certs having non-exportable private keys.

XML: Double and single quotes in content are not automatically encoded to " and '

Zip: Fixed ZIP64 writing problem.

MIME/Internal: Fixed iso-2022-jp issue that can sometimes occur with MIME header parsing.

DirTree/FileAccess: Added FileSize64 property to DirTree ActiveX and FileSize64 method to FileAccess ActiveX.

HTTP: Added the BasicAuth property (must be set to true for the HTTP component to send a request using basic authentication).

HTTP: Fixed the HttpBeginReceive, HttpEndReceive, HttpBeginSend, HttpEndSend event callbacks.


Download SFTP Files Indirectly through a Web Site


I am doing a project that requires a web site to list files from an SFTP server and allow the visitor to download them.  Following the examples on your site, it was very easy to list the files.  However, you have no example of downloading a file to the user, only to the local filesystem.  Do you have any code that could help me with this?


This is a common question.  To restate the situation:

  1. There  is an SSH/SFTP server on your private network accessible from the server-side code running on your web server, but not accessible to the outside world.
  2. The need is to deliver files from this server to an end-user located anywhere on the Internet using only a browser.

The solution:

  1. The end-user clicks on a link or form “submit” button that sends an HTTP request (GET or POST) to your web server.
  2. The page handling this request includes server-side code, which (of course) runs on the web server.  It needs to download the file from the SSH/SFTP server to either a temporary file (on the web server) or perhaps directly into an in-memory byte array.
  3. The file data is then sent in an appropriate HTTP response, with correct Content-Type header indicating the type of data.  If using ASP/ASP.NET, it will probably involve calling Response.BinaryWrite.

ESET NOD32 false-positive: Genetik Trojan

Recently, the ESET NOD32 AntiVirus program began erroneously detecting the Chilkat .NET 2.0/3.5 download as containing a Genetik Trojan virus. This is incorrect (i.e. it is a false positive). After researching the Genetik Trojan, it has become apparent that NOD32’s virus definition for this particular virus is frequently a false-positive. If you experience this problem, report the false-positive by sending email to

NOTE: The problem only occurs during the download. The ChilkatDotNet2.dll, once on your system, is not detected as a virus. Therefore, you may bypass the problem by downloading the Chilkat .NET assembly from this encrypted .zip:
The password is “chilkatsoft”.

Unzip and place the ChilkatDotNet2.dll in your app’s bin directory. In Visual Studio, add a reference to this assembly by browsing to the DLL’s location and selecting the DLL.