cryptlib-tools 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 encryption (S/MIME), CA services or SSH and TLS sessions.
All cryptlib-tools, the AES file encryption tool (claes), the public/private key management tool (clkeys) and the public key encryption tool (clsmime) are based on Cryptlib and are coded in Python3.
All cryptlib tools can replace complex OpenSSL code by using Cryptlib and are designed to interoperate with programs that are widely used and established like gpg2, openssl and Email clients like Thunderbird or Outlook.
If you use only one of these programs, either openssl or gpg2 for file encryption, 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 only encryption method.
claes [-debug] [-decrypt] [-cms | -openssl [-128]] [FILE | -]
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.
clkeys generate [-DSA] KeysetName [-SIZE RSABits] [-CN YourName]
clkeys request KeysetName [-CN YourName]
clkeys import KeysetName CertFile
clkeys casign CA-KeysetName RequestFile
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.
clsmime [OPTIONS] encrypt messagefile certificate
clsmime [OPTIONS] decrypt encrypted_message KeysetName
clsmime [OPTIONS] sign messagefile KeysetName
clsmime [OPTIONS] verify signed_message [CArootCertificate]
clTLS opens a TLS-1.2 session to a selected server and transferres any amount of data from the server (GET) or uploads the binary content of a file to the server (PUT).
Unlike a web browser or CLI programs like curl, which rely heavily on the global public key infrastructure, clTLS is designed to do only one thing, getting sensitive information from A to B in the most secure way available. In order to achieve this reliable data exchange, clTLS connects only to those web servers (via TLS) which can be authenticated using known-good information that is available to the end-user.
Essentially, there are two very different mechanisms that clTLS uses to ensure that the connection is actually established with the correct web server a user wants to connect to. But both mechanisms require trustworthy information that must be stored in the user's home directory before any TLS data exchange can happen.
The first one (fingerprints) is used to make the reliance on a global PKI completely obsolete. Once the end-user is in possession of a fingerprint (SHA-256) of the certificate, a web server uses in the TLS-handshake, it can be stored in the user's home directory as a sign of trust. It does not matter, whether the server certificate has been acquired via a public CA or is a self-signed certificate, the existence of the stored fingerprint authenticates the web server as long as it produces the matching certificate when a connection is being initiated.
The global public key infrastructure has its inherent problems, because generally, any CA can issue a certificate for any web server domain. In contrast, cltls is build to restrict the number of trusted CAs to a very limited set of CAs that are positively known to work securely. This set of trusted CAs is under the end-user's sole control as only the few (checked) CA certificates that are stored in the user's home directory will be allowed to verify a server certificate, not the plethora of CAs build into the operating system by default.
cltls [OPTIONS] GET https://servername/path/to/resource[?query]<br>
cltls [OPTIONS] GET servername /path/to/resource[?query]<br>
cltls [OPTIONS] PUT https://servername/path/to/resource[?query] file<br>
cltls [OPTIONS] PUT servername /path/to/resource[?query] file<br>
cltls [OPTIONS] STORE servername
These are only three examples of how you can use Cryptlib to build reliable tools for users. And there are many more tools to come in the near future.
Every code review is most welcome, however in order to maintain the stability and reliability of the code base I will carefully vet any contribution and I may chose to rewrite it, add comments and documentation, rather than taking it as is. Needless to say that code changes will happen only after conclusion of extensive tests.