The Cryptlib Tools - An Overview

With Cryptlib comes a program "stestlib", coded in C, that is designed to test every single feature of the main library extensively. This program is a great resource for everyone who is looking for example code that encourages the adoption of Cryptlib in their own project.

But in my opinion, what's missing is a collection of single stand-alone tools, that cover all aspects of one specific encryption problem, be it conventional symmetric file encryption (AES), public key management, RSA encryption, email message crypto support, CA services or SSH sessions.

We all know the numerous OpenSSL commandline programs that can do all such things, if used correctly, but very few real life software actually uses Cryptlib for such tasks. The cryptlib tools I have developed already and those, that will extend the collection further in future, are here to change that. All cryptlib tools can replace complex OpenSSL code and are designed to interoperate with programs that are widely used and established like gpg2.

As Python is my go-to programming language, I will also describe the lessons I've learned while developing the cryptlib tools in Python. Please have a look at clAES: Using Cryptlib - Encryption Based On Solid Foundations for a start.

claes - File Encryption Using Pure AES

With the extraordinary foundation that Cryptlib provides at hand, I started to code a message encryption program that uses AES reliably and is able to interact both with GnuPG and with OpenSSL.

If you use only one of these programs (openssl or gpg2) , the resulting encrypted cipher texts are stored in a format that cannot be interchanged with the other. GnuPG aims to implement the OpenPGP standard with various degrees of success in a format that consists of packets described in RFC-4880, while OpenSSL (accessed via the command line tools) can produce cipher text in CMS-format or in its own proprietary format. As it is seen so often, both worlds (although using AES) cannot talk to each other easily.

But the tool clAES is made to talk to both, as it can produce OpenPGP messages (as the default) and additionally switch to CMS or OpenSSL message formats if need be. In any case, the input data is encrypted with a passphrase that the user provides to the program and AES will always be used as the default encryption method.

The default mode of operation is encryption storing the cipher text base64-encoded in OpenPGP format. To decrypt base64-encoded or binary input data the option "-decrypt" can be used.

Fortunately, claes is already included in the Fedora package for Cryptlib. The code is signed with my Codesigningkey and there is a manual page available both as a Unix-style man page and as a PDF document.

claes [-debug] [-decrypt] [-cms | -openssl [-128]] [FILE | -]

clkeys - Public and Private Key Management

One of the main features of clkeys is to generate RSA and DSA asymmetric keys and to store these keys safely in a file in the PKCS#15 token format.

If you ever have imported RSA keys for use in an email client like thunderbird, you'll probably know that this software expects both the private and the public key together in a single file in PKCS#12 format. This bad habit has become common-sense, despite the fact that the PKCS#12 format is a weak format and a bad idea to store a private key.

Cryptlib, on the other hand, will always store private keys in the PKCS#15 format, a format that is used with cryptographic tokens like Smart Cards, where the keys never leave the device. Because one of the principal design features of Cryptlib is that it never exposes private keys to outside access, Cryptlib chooses to use the PKCS#15 format with no exception. So do not wait (or even wish) for a conversion tool that makes Cryptlib-generated keys available in a PKCS#12 format file. It makes no sense to deliberately reduce the security of your private keys just because some email client wants them in a weak format only.

In addition to generating RSA and DSA public key pairs, clkeys can generate certificate signing requests for a public key and also import self-signed certificates or certificates signed by an external CA. All files that clkeys will create (cert requests and certificates) can be used by other software, just the private key remains secure in a PKCS#15 format file, that will be used with Cryptlib exclusively.

Once you have understood, that a private key should remain where it has been generated, the idea of exchanging private keys - and using PKCS#12 files - will vanish completely. Information that must be exchanged between people is always related to public keys.

Just as claes, clkeys is also included in the Fedora package for Cryptlib. The code is signed with my Codesigningkey and there is a manual page available both as a Unix-style man page and as a PDF document.

clkeys generate [-DSA] KeysetName [-SIZE RSABits] [-CN YourName]
clkeys request KeysetName [-CN YourName]
clkeys import KeysetName CertFile
clkeys casign CA-KeysetName RequestFile

clsmime - S/MIME public key encryption tool

clsmime is a tool that uses public and private RSA keys made with clkeys to generate encrypted SMIME messages and signed SMIME messages. It can also exchange SMIME encrypted and signed messages with established EMAIL clients like Thunderbird, Evolution or Outlook. clsmime handles SMIME messages that are produced by OpenSSL as well. While clsmime will use private keys generated with clkeys in PKCS#15 format for decryption and signing, it can use certificates generated by OpenSSL for encryption and verification as well.

Just as clkeys, clsmime is also included in the Fedora package for Cryptlib. The code is signed with my Codesigningkey and there is a manual page available both as a Unix-style man page and as a PDF document.

clsmime [OPTIONS] encrypt messagefile certificate
clsmime [OPTIONS] decrypt encrypted_message KeysetName
clsmime [OPTIONS] sign messagefile KeysetName
clsmime [OPTIONS] verify signed_message [CArootCertificate]

clsha1, clsha2 - Fingerprint Tool

clsha1 and clsha2 can replace the standard programs sha1sum and sha256sum.

The default mode of operation is printing the hexadecimal format of the hash value, but with the option "-base64" the hash value can be printed base-64 encoded instead of hexadecimal.

clsha2 [-base64] [FILE]

Future Projects

There are quite a number of additional tools one can think of to extend the collection of existing cryptlib tools.

OpenSSL allows to encrypt, decrypt, sign and verify small pieces of information (smaller than the modulus of a RSA key pair) with the RSA algorithm (including padding) directly. clrsa is meant to replace this functionality.

clrsa - File Encryption Using Pure RSA

And there are a number of tools imaginable that make use of Cryptlib's session interface. The secure transfer of files using TLS sessions to connect clients and servers (clget) is one example. Or the secure execution of a command on a remote server via the SSH protocol (clssh) are both interesting examples for a stand-alone program using Cryptlib.

So there is much to do in 2025.

Please contact me, if you need a helping hand to base your project on Cryptlib.