SocketTools 10 introduced some general purpose functions which make it easier to encrypt and decrypt data. For the Library Edition, these functions were added to the Encoding and Compression API. For the .NET and the ActiveX Editions, they were added to the SocketTools.FileEncoder class. For technical details, refer to the online documentation.
To simplify things, SocketTools uses only one type of encryption algorithm, AES (Advanced Encryption Standard), which is an international standard for data encryption. We use 256-bit encryption, and the encryption keys are generated from hashes using the SHA-256 algorithm. To this date, no method has been developed to read AES-256 encrypted data without having access to the encryption key.
There are three general groups of functions or methods you can use to encrypt and decrypt data, depending on your specific needs.
Encrypting Memory
You can provide a byte array or string and have the data returned as an encrypted array of bytes. The .NET class also supports the use of MemoryStream objects. For the Library Edition, you would call the AesEncryptBuffer function. For both the .NET class and ActiveX control, you would use the FileEncoder.EncryptData method.
All you need to do is provide the input data (the data you want to encrypt), an output buffer (a byte array that will contain the encrypted data) and a password which is used to generate the encryption key. The password can be any string, and it can include spaces.
To decrypt previously encrypted data, you would use the AesDecryptBuffer function in the Library Edition, or the FileEncoder.DecryptData methods in the .NET class and ActiveX control. It reverses the process and will return the decrypted data in the output buffer, as long as the password matches the one used to encrypt the data exactly.
Encrypting Strings
One problem you can face when encrypting data is that, regardless of what the original data consists of, the output is always going to be binary. It can contain embedded null characters and unprintable text and it must be handled as an array of bytes. To help with this, we have a set of functions that explicitly work with text input and return the encrypted data as printable text output.
The AesEncryptString function accepts a string as input and performs the same encryption as AesEncryptBuffer. However, the encrypted data is automatically converted to printable text using base64 encoding. This makes it safe to store in text files, registry strings and so on. Likewise, the AesDecryptString function decrypts the encrypted string and returns the original string.
For the .NET Class and the ActiveX control, you would use the same EncryptData and DecryptData methods. If you pass in a string value as the input buffer, and provide a string for the output buffer, it will automatically be handled as text and the output will always be a printable string.
It’s important to keep in mind that when you’re encrypting strings, the encrypted string will always be larger than the original plain text string, due to how base64 encoding works. If you’re storing the encrypted text, make sure your application is allocating enough space. Never make assumptions that the encrypted output will be about the same size as the original input.
Encrypting Files
The third group of functions are used to encrypt and decrypt entire files. For the Library Edition, this is done using the AesEncryptFile and AesDecryptFile functions. For the .NET Class and ActiveX control, they are the FileEncoder.EncryptFile and FileEncoder.DecryptFile methods.
You provide an input file, an output file and a password which is used to generate the encryption key. If the output file already exists, it will be overwritten with the encrypted contents of the original file; otherwise a new file will be created. The encrypted file will always contain binary data, and therefore cannot be handled like a text file, even if the original file only contained text. This is particularly important if you’re uploading the encrypted file using FTP. Attempting to upload an encrypted text file as text will corrupt the data and prevent you from being able to decrypt it later.
If you want to compress the file you’re encrypting using CompressFile, you should always do this before performing the encryption. Generally speaking, the compression ratio will always be worse for encrypted data, particularly text data. Compressing the file and then encrypting it will give you the best results.
Passwords and Encryption Keys
When you encrypt and decrypt data, you need to provide a password, which is really any string you wish and it can be a passphrase or just a sequence of random characters. That value is used to generate a 256-bit hash, which is in turn used to create the encryption key. To prevent brute-force attacks, we recommend you use randomly generated passwords that are at least 20 characters in length and do not use common words or phrases.
Once you’ve encrypted a block of memory, a string or file, it can only be decrypted using the corresponding SocketTools function with that same password. You will not be able to use a third-party tool to decrypt the data, even if you provide the same password string or generate the SHA-256 hash yourself. This is because the actual encryption key is generated from a permutation of internal hash values in combination with the hash of the password string you provide.
If you encrypt a file using the AesEncryptFile function or the EncryptFile method, not only would someone need the password you’ve used, but they would also need to know to specifically use SocketTools to perform the decryption. Likewise, SocketTools cannot be used to decrypt data or files that were encrypted using another third-party tool or encryption API. For example, you couldn’t use SocketTools to decrypt a protected document created by Microsoft Office, even if you knew the password used to encrypt the document.
Data encrypted using the Library Edition API can be decrypted by the .NET class or ActiveX control, and vice versa. So if you had one application written using C++ with the Library Edition, and another application written in C# using the .NET Edition, both would be able to encrypt and decrypt the data and files generated by the other.
Under the Hood
The SocketTools functions and components use Microsoft’s CryptoAPI which is part of the base Windows operating system. Specifically, it requires the RSA AES cryptographic service provider. If this provider is not available for your version of Windows, due to regulations or laws in your country governing the use of cryptography, these encryption functions will fail.
Some countries have strict laws regarding the export of technology which uses cryptography. If you use these functions or components, make sure you review any relevant laws regarding their use, particularly if your software is being redistributed outside of your country.