This is a common question: You receive encrypted data and a key and want to decrypt. The person providing the encrypted data has provided little information, perhaps only that the encryption algorithm is AES. Where to do you begin, and what additional information, if any, do you need?

Answer:

AES encryption comes in 3 key sizes: 128-bit, 192-bit, and 256-bit. Look at the key you received. Which of the following does it look like:

1. zxcv1234abcdQWER
2. 7A786376313233346162636451574552
3. enhjdjEyMzRhYmNkUVdFUg==

The strings above are all the same key encoded differently.

#1 is a us-ascii string that is exactly 16 characters.  This is a clue that the person gave you a 128-bit key (16 bytes * 8 bits/byte = 128) and that the bytes used for the key are the ascii values of the characters in the string.

#2 is a hexidecimal representation of #1.  If you have a hexidecimal representation of the key, you’ll notice that only the characters 0-9 and A-F (or a-f) are used.  Each byte of the key is represented by 2 ascii bytes.  If your hex string is 32 characters, you have a 16-byte key (and therefore 128-bit encryption).

#3 is a base64 encoded representation of #1.  The tell-tale signs of Base64 are:  It is often a string ending in “=” or “==”, and it is not a multiple of 16 characters in length, and it uses characters not valid in a hex string.  A base64 string will be about 1/3rd longer than the binary bytes it represents.  Thus it is longer than our ascii representation, but shorter than the hex representation.  Therfore, if it’s between 16 and 32 bytes, you can guess 128-bit encryption.  if longer than 32-bytes, it’s 256-bit encryption.

So… once you understand the key, you can set the KeyLength and secret key:

cryptObject.KeyLength = 128;

// If the key is represented as an ascii string:
cryptObject.SetEncodedKey(keyStr, "ascii");

// If the key is represented as an hexidecimal string:
cryptObject.SetEncodedKey(keyStr, "hex");

// If the key is represented as an base64 string:
cryptObject.SetEncodedKey(keyStr, "base64");

OK, the KeyLength and the secret key are specified. What’s left?
You need to know the following:

• CBC or ECB mode?
• If CBC mode, what is the initialization vector (IV)
• Padding scheme?
• Format of your encrypted data?

Chances are more likely that it is CBC mode (which stands for cipher block chaining).  If so, you need an initialization vector.  This will always be 16 bytes long, regardless of the key length.  If no IV is provided, then it’s probable that it is assumed to be all NULL bytes, and this is the default w/ the Chilkat component.

If you have the IV, then examine it just like you did for the key, and call SetEncodedIV just like you called SetEncodedKey, passing the correct encoding (”ascii”, “hex”, or “base64″) for the 2nd argument.

If ECB mode is used, then set the CipherMode property = “ecb”

cryptObject.CipherMode = "ecb";

The PaddingScheme property may be initially left at the default value (which is the most commonly used).  My suggestion is to test with an amount of data that is more than 16 bytes.  The reason is that if everything is correct *except* the PaddingScheme, then your decrypted output will be correct except for the very last 16 bytes.  Once you know that all is correct except for the padding scheme, you can test with different PaddingScheme values.  If you only have a very short amount of data for testing, then it’s not possible to make this distinction.

Finally, look at the encrypted data itself.  Is it hex or base64?  If it is a “string” it must be one or the other.  You’ll want to set the EncodingMode property equal to the encoding of the encrypted data:

cryptObject.EncodingMode = "hex";

Assuming the decrypted result is a string, you’ll call DecryptStringENC.  The “ENC” in the function name indicates that the input is an encoded string and that the encoding is specified by the EncodingMode property.  It returns a string — your decrypted data.

string decryptedStr = cryptObject.DecryptStringENC(encryptedStr);

A Chilkat customer pointed me to this useful information:
http://www.campaignmonitor.com/css/

Important: I don’t know if the writers at campaignmonitor.com are aware of the different ways embedded images may be referenced (from within the CSS or from within HTML). It can be via “CID” or by URL w/ matching Content-Location header field. Chilkat can do both by setting the UseCID property (true/false). It may be that in some cases “CID” does not work, but URL/Content-Location does, or perhaps the reverse. This would need to be studied in more detail…

The following changes, fixes, and new features are available in version 9.0.8.

General

• Fixed iso-2022-jp issues with converting to/from the iso-2022-jp character encoding.
• General performance improvements
• Added AutoFix property to POP3, SMTP, IMAP, and FTP2. If on, then the component will auto-fix property setting mistakes related to port numbers and SSL/TLS. For example, well known ports 465, 990, 995, and 993 are all implict SSL/TLS ports for the above protocols. If the port is one of these, then the SSL/TLS related properties will be checked and auto-fixed if incorrect.
• Fixed large-transfer SSL/TLS performance issues.

Email Object

• Added email.AddHeaderField2 — this one will not replace the header field if it already exists. It allows for adding duplicate header fields (i.e. header fields having the same name)
• Fixed certain MIME field folding issues for Subject when semicolon characters are present.
• Added the Email.PrependHeaders property to control whether new headers added via AddHeaderField or AddHeaderField2 are prepended or appended to the email header.

Data Compression

• Fixed x64 PPMD implementation.

Encryption

• Fixed memory leak in CkEncryptFile/CkDecryptFile when PKI is used.

FTP2

• Added AutoGetSizeForProgress property. Forces the component to always get the size of the file to be downloaded beforehand. This may cause some additional overhead (time delay) when downloading files, but ensures that the remote file size information is available for progress monitoring.
• FTP issues fixed for filenames ending in SPACE chars.
• Fixed problem with Oracle Internet FTP Server (where the server responds to downloads erroneously indicating that the file size is 0 bytes)
• Fixed VMS OpenVMS FTP directory parsing problem.
• Added SyncPreview, SyncRemoteTree2, SyncLocalTree2 to FTP2 component.
• Fixed problems related to resuming FTP uploads of large files.

HTML-to-Text

• Improved the way that hyperlinks are presented in the text output.
• Fixed performance problem in HTML-to-Text for pages with large amounts of unbroken text.

HTTP

• Fixed asynchronous HTTP. This error was occurring when it shouldn’t: “Cannot do this while background HTTP task on this object instance is running.”
• Fixed problem with Http.SetSslClientCert in ActiveX.
• Fixed HTTP proxy authentication for SMTP, IMAP, POP3.

IMAP

• Added the UidNext property: A 32-bit positive value containing the UIDNEXT of the currently selected folder, or 0 if it’s not available or no folder is selected.

SSH / SFTP

• Fixed problem with setting ssh.IdleTimeoutMs after Connect.
• SFTP problems fixed for filenames ending in SPACE chars.

SMTPQ

• Fixed SOCKS and HTTP proxy support.

Zip

• Added ZipEntry.CompressedLengthStr, UncompressedLengthStr to Zip ActiveX
• Added ZipEntry.CompressedLength64 and UncompressedLength64 to .NET and C++.
• IgnoreAccessDenied now applies to AppendFilesEx when appending an entire directory tree.

Question: How do I go about adding text to the entry.comment field while zipping individual files?

Answer: After appending files via the AppendFiles (or other append methods), you’ll have a zip object with N entries, each of which is a reference to a file that will be zipped when WriteZip is called (or WriteZipAndClose, or WriteExe, etc.).
You can then iterate over the entries, or search for a particular entry, and then update that entry’s Comment property with the comment you want to add.  Then when you write the zip, your comment is included…

When an email is sent with BCC recipients, the BCC email addresses will *not* be found in the header.   You’ll find the “To” recipients listed in the “To” header field, and the “CC” recipients listed in the “CC” header field, but the BCC recipients are intentionally left out.  This is what makes it a “blind” carbon copy — the recipients are unable to see the BCC recipients.  This is by design.  Otherwise the BCC recipients would simply be “CC” recipients.  How do BCC recipients get the email?  To understand, you need to spend 10 minutes reading this blog post: SMTP Protocol in a Nutshell.   The BCC recipients are passed to the SMTP server in “RCPT TO” commands.

Here is a C# example to append more text to an email’s body:

    Chilkat.Email email = new Chilkat.Email();

    bool success = email.LoadEml("in.eml");
    if (!success)
    {
        textBox1.Text = email.LastErrorText;
        return;
    }

    // Does this email have a plain-text body?
    if (email.HasPlainTextBody())
    {
        string s = email.GetPlainTextBody();
        s += "\r\nMore text appended to the email's plain-text body.";
        // Replace the plain-text body:
        if (email.HasHtmlBody())
        {
            // This is an email with both plain-text and HTML alternatives
            // The AddPlainTextAlternative body replaces the plain-text body if it already exists.
            email.AddPlainTextAlternativeBody(s);
        }
        else
        {
            // This is a plain-text only email.
            email.Body = s;
        }
    }

    if (email.HasHtmlBody())
    {
        string s = email.GetHtmlBody();
        s += "<p>More text appended to the email's plain-text body.</p>";
        // Replace the HTML body:
        if (email.HasPlainTextBody())
        {
            // This is an email with both plain-text and HTML alternatives
            // The AddHtmlAlternativeBody replaces the HTML body if it already exists.
            email.AddHtmlAlternativeBody(s);
        }
        else
        {
            // This is an HTML-only email.
            email.SetHtmlBody(s);
        }
    }

    email.SaveEml("out.eml");

Question:

How can I access Public Folders in IMAP? This does not work:

imap.SelectMailbox(”Public Folders”)

Answer:

The syntax in Outlook may be different than what is actually
used in the underlying IMAP protocol. For example, in Outlook you may see
“public folders\all public folders\test”, but you would instead use:

imap.SelectMailbox(”public folders/test”)

The following Java code produces a digital signature that can be verified using Chilkat RSA.  Links to the Chilkat signature verification examples follow this code.  The Java signature creation code does not use Chilkat to produce the digital signature.  It also demonstrates how to save a generated key (public and private) to DER files that can be used with Chilkat RSA.

import java.io.*;
import java.security.*;

// Chilkat is only used for Base64 and Hex encoding.
import com.chilkatsoft.*;

public class SignTest {

  static {
    try {
        System.loadLibrary("chilkat");
    } catch (UnsatisfiedLinkError e) {
      System.err.println("Native code library failed to load.\n" + e);
      System.exit(1);
    }
  }

  public static void main(String argv[])
  {
  	  try
  	  {
		KeyPairGenerator generator = KeyPairGenerator.getInstance(”RSA”);
		System.out.println(”Generated RSA Key!”);
		generator.initialize(1024);
		KeyPair keyPair = generator.generateKeyPair();

		PrivateKey privKey = keyPair.getPrivate();
		PublicKey pubKey = keyPair.getPublic();

		// Save the private key to an ASN.1 DER file:
		byte[] privKeyDer = privKey.getEncoded();
		OutputStream outPrivKey = new FileOutputStream(”privKey.der”);
		outPrivKey.write(privKeyDer);
		outPrivKey.close();

		// Save the public key to an ASN.1 DER file:
		byte[] pubKeyDer = pubKey.getEncoded();
		OutputStream outPubKey = new FileOutputStream(”pubKey.der”);
		outPubKey.write(pubKeyDer);
		outPubKey.close();

		Signature _signature = Signature.getInstance(”SHA1withRSA”);
		_signature.initSign(privKey);

		// Sign the string “The quick brown fox jumps over the lazy dog”
		String strToSign = “The quick brown fox jumps over the lazy dog”;
		byte[] bytesToSign = strToSign.getBytes();
		_signature.update(bytesToSign,0,bytesToSign.length);

        // If you signed a string with characters in non-English languages, you may
        // wish to see the exact bytes signed, perhaps by loading the following file
        // in a hex editor.  Make sure the program verifying the signature uses the same
        // byte representations for the characters (i.e. the same character encoding).
		OutputStream outBytesSigned = new FileOutputStream(”bytesToSign.txt”);
		outBytesSigned.write(bytesToSign);
		outBytesSigned.close();

		// Sign the contents of a file with this commented-out code:
		//FileInputStream fis = new FileInputStream(”dude.gif”);
		//BufferedInputStream bufin = new BufferedInputStream(fis);
		//byte[] buffer = new byte[1024];
		//int len;
		//while ((len = bufin.read(buffer)) >= 0) {
			//_signature.update(buffer, 0, len);
			//};
		//bufin.close();

		// Create the signature.
		byte[] sigBytes = _signature.sign();

		OutputStream out = new FileOutputStream(”sig.dat”);
		out.write(sigBytes);
		out.close();

		// Convert the signature to a Base64 or hex string:
		CkByteData ckSigBytes = new CkByteData();
    	ckSigBytes.appendByteArray(sigBytes);

	    //  Convert to hexidecimalized string:
	    System.out.println(ckSigBytes.getEncoded(”hex”));

	    //  Convert to base64 string:
	    System.out.println(ckSigBytes.getEncoded(”base64″));

		System.out.println(”Success!”);

	    //} catch (NoSuchProviderException e) {
	    //	System.out.println(”NoSuchProviderException!”);
	    } catch (IOException e) {
	    	System.out.println(”IOException!”);
	    } catch (InvalidKeyException e) {
	    	System.out.println(”InvalidKeyException!”);
		} catch (SignatureException e) {
			System.out.println(”SignatureException!”);
		} catch (NoSuchAlgorithmException e) {
	    	System.out.println(”NoSuchAlgorithmException!”);
			}

  }
}

Verify Digital Signature examples using Chilkat in various programming languages:
ASP: Verify Java Signature
SQL Server: Verify Java Signature
C#: Verify Java Signature
C++: Verify Java Signature
MFC: Verify Java Signature
C: Verify Java Signature
Delphi: Verify Java Signature
Visual FoxPro: Verify Java Signature
Java: Verify Java Signature
Perl: Verify Java Signature
PHP: Verify Java Signature
Python: Verify Java Signature
Ruby: Verify Java Signature
VB.NET: Verify Java Signature
Visual Basic: Verify Java Signature
VBScript: Verify Java Signature

There are many FTP2 component properties that affect how data connections are established between the FTP client (Chilkat FTP2) and the FTP server. Finding a workable combination of property settings for a given client/server situation can be difficult.  This blog post can hopefully provide some guidance.

Before beginning, it is crucial to understand one basic thing about the FTP protocol: The control connection (typically port 21 or 990) is used for sending commands and getting responses. File uploads/downloads and directory listings are NOT transferred over the control channel. A separate data connection is established for each transfer. One side is responsible for choosing a port number and accepting the data connection, the other side initiates the connection. The direction of the data connection establishment is controlled by the Passive property setting. Passive=true uses passive mode. If Passive=false, then “Active” mode (also known as “port” mode) is used.

Active Mode: The FTP client chooses a port number and sends a “PORT” command to the FTP server. The FTP client then listens at the chosen port and the FTP server issues a connect request to establish the connection. The data connection is outgoing from the FTP server, and incoming to the FTP client.

Passive Mode:The FTP client sends a PASV command to the FTP server. The FTP server chooses a port number and sends it in the PASV response. The FTP server then listens at that port for the incoming connect request from the FTP client. The data connection is incoming to the FTP server, and outgoing from the FTP client.

The data connection establishment can be blocked at either side (client or server) by many things:  firewalls, TCP/IP port filtering, anti-virus, NAT routers causing problems, etc.

If a file upload or download fails with the dreaded “WSAEWOULDBLOCK” message in the LastErrorText, it means that something blocked the data connection.

The first thing to try in resolving the problem is to reverse the value of the Passive property.  If that doesn’t work, try calling the DetermineSettings method to try a collection of approximately 15 different combinations of property settings.  Examples for DetermineSettings can be found at example-code.com.

The DetermineSettings method does not try all combinations of property settings.  It cannot because there are too many potential combinations.

The FTP2 property settings involved in the data connection establishment are:

• ActivePortRangeEnd
• ActivePortRangeStart
• AuthSsl
• AuthTls
• ForcePortIpAddress
• Passive
• PassiveUseHostAddr
• Ssl
• UseEpsv

If you are able to transfer files using other FTP client software, such as FileZilla, then you should examine the settings of that program and duplicate them w/ Chilkat FTP2.  If you are unsure, you can narrow down the possible combinations by setting the known values.  For example, if you know that FileZilla is working in Passive mode, then you may set the Passive property = true.  This reduces the number of possible combinations by 50%.  Here are some guidelines for duplicating the settings of another FTP client, such as FileZilla:

• You should certainly know whether the mode being used is Passive or Active (non-passive), so set the FTP2’s passive property appropriately.
• If Active mode is used, check to see if your FTP client is using a port range.  If so, then set the ActivePortRangeStart and ActivePortRangeEnd properties to the same values.  If not, leave these properties unset.
• If implicit SSL is used (typically port 990) then set the Ssl property = true.  (Implicit SSL and explicit SSL are mutually exclusive.  if Ssl = true, then both AuthSsl and AuthTls should = false)
• If explicit SSL is used (AUTH TLS or AUTH SSL) then set either AuthTls = true or AuthSsl = true.  Usually it doesn’t matter which because both commands are technically the same.  Some servers require the “AUTH SSL” command whereas others require “AUTH TLS”.  Most servers don’t care and accept either.
• If Passive mode is used, test with both PassiveUseHostAddr on and off.   Also test with both UseEpsv on and off.  The ForcePortIpAddress only applies to Active mode, so it can be ignored.
• If Active mode is used, test with ForcePortIpAddress both on and off.  The PassiveUseHostAddr and UseEpsv properties don’t apply when in Active mode.

Still cannot get it to work?  Programs such as anti-virus may have exceptions for some applications.  It could be that these apps were marked as “trusted” at some earlier time whereas your custom application is not trusted by the anti-virus program.

Cannot get anything to work including all FTP clients such as FileZilla, WS FTP, Internet Explorer, etc.?  It probably means that so many barriers exist on both client and server sides (firewalls, port filtering, anti-virus, NAT routers…) that something must be “opened up” in some way to allow FTP to work.

Question:

Is there a way to encrypt a file with progress monitoring?  Huge files can take a while and it seems like the app is hanging.

Answer:

Yes, here is the sample VB6 code:

Public WithEvents myCrypt As ChilkatCrypt2

' ....

Private Sub myCrypt_PercentDone(ByVal pctDone As Long)

    ProgressBar1.Value = pctDone

End Sub

Private Sub Command2_Click()

    Set myCrypt = New ChilkatCrypt2

    success = myCrypt.UnlockComponent("test")

    ' ...

    success = myCrypt.CkEncryptFile("c:/temp/big.txt", "c:/temp/bigEncrypted.dat")

End Sub