cryptlib FAQ

  1. Why do I get an "Assertion failed" when I use cryptlib?
  2. Does cryptlib run on CPU X/embedded OS Y?
  3. Do you have any performance measurements for algorithm x?
  4. How much RAM/flash does cryptlib require?
  5. Can I read keys from PFX/PKCS #12 files?
  6. Can I read keys from the Windows registry/CryptoAPI blobs/the Netscape cert database/OpenSSL PEM files/etc?
  7. How do I read a key from a crypto device such as a smart card or a keyset when I don't know the label for the key?
  8. When will cryptlib support OAEP? RSA-PSS?
  9. Does cryptlib support AADS, CDMF, CMC, CMMF, CPM, CRS, CSVP, DHPOP, DCS, DVCS, ICAP, OCDP, QC, RMP, SCVP, SDSI, SPKI, VMP, ... ?
  10. Does cryptlib have FIPS 140 certification?
  11. Does cryptlib handle base64/MIME encoding/RFC 822/SMTP/POP3/IMAP messaging?

Why do I get an "Assertion failed" when I use cryptlib?

You've built the debug version of cryptlib rather than the release version. The debug version is intended for people developing cryptlib, and provides extended diagnostic and debugging information that isn't present in a normal release. See "Debug vs.Release Versions of cryptlib" in the manual for more information.

Does cryptlib run on CPU X/embedded OS Y?

This question has two answers depending on the intent of the question. If it's "can cryptlib run on CPU type X or OS type Y?" then the answer is as follows:

cryptlib runs on virtually all CPUs and operating system platforms, however there are some obscure embedded OSes that it hasn't yet been ported to, generally because they're non-mainstream enough that access to a development system and/or documentation is anything form difficult to near-impossible. cryptlib has been designed for easy portability to any OS, targetting new systems hasn't proven much of a problem in the past. Anyone requiring a port is strongly encouraged to involve the cryptlib developers in the process, since past experience has shown that this leads to a significant reduction in effort in performing the port (a typical example was several months vs.2 days to get it running on a particular proprietary embedded environment).

If the question is "can cryptlib run on our particular system?" then that depends on what memory and CPU resources are still available once the rest of your code is installed and running, and what it is you want to do with cryptlib. While the answer to the abstract question is invariably "yes", in order to provide an answer for a specific system and configuration it's necessary to know exactly what's available. Question 4 contains more detail on this.

Do you have any performance measurements for algorithm x?

It's impossible to answer this question because it depends on the system it's being run on, the compiler being used, the algorithm, the key size (for public-key algorithms), the fact that cryptlib is in some cases performing a lot of other work in the background (e.g. data encapsulation or certificate processing), and a variety of other factors. In general on a modern system the raw performance of most of the block ciphers and hash functions is tens to hundreds of megabytes per second, and the raw time for public-key operations is a few milliseconds. With cryptlib hardware assist, the processing speed is limited mostly by the I/O bus speed.

These are representative times. If you need a definitive figure for your exact hardware, OS, compiler, and application, run the code and see.

How much RAM/flash does cryptlib require?

As with the previous question, this depends on the build options that you use when you're compiling the code and what you want to do. Since cryptlib can be extensively customised, the memory usage can vary quite significantly based on which options you enable. As a general rule of thumb, if you're implementing something like SSL/TLS, SSH, S/MIME, or PGP, cryptlib requires an absolute minimum of 128kB RAM, 256kB of flash, and about 100 DMIPS of performance unless you don't mind waiting around for awhile for crypto operations to complete. If you want to do anything involving certificates, double the flash requirements.

Can I read keys from PFX/PKCS #12 files?

This format has had some serious security problems, as well as being a very poorly-designed format for storing keys. Because of these security concerns, cryptlib will not import or export its keys to files in this format since it in effect constitutes a security compromise of the private key. Instead, it uses the PKCS #15 format, which is an enhanced key and certificate storage format without the problems of PKCS #12.

(Actually there is partial support for PKCS #12 present via the code module keyset/dbxpk12.c, if you really want PKCS #12 support you can add it by completing the code in the module. Note that there are several incompatible versions of the PKCS #12/PFX standard, as well as many different interpretations of how to implement any particular version of PKCS #12, and finally since the standard leaves many things undefined, vendors have invented their own ways of doing things that are (needless to say) again incompatible. As a result, it's quite possible for half a dozen different vendors to create fully-compliant PKCS #12 files that can't be read by any other implementation. You'll need to handle this chaos yourself if you decide to go with PKCS #12).

Can I read keys from the Windows registry/CryptoAPI blobs/the Netscape cert database/OpenSSL PEM files/etc?

These are proprietary/undocumented formats that conform to no known standard. Because of their nature, they are tied to a particular vendor or platform, and can't be read by cryptlib (or anything else).

How do I read a key from a crypto device such as a smart card or a keyset when I don't know the label for the key?

The underlying key storage system, either a disk file, smart card, HSM, or crypto token, identifies keys using labels or some similar form of identifier. In order to fetch a key from a keyset or device, you need to provide a label to identify the key that you want to fetch (keys always have labels, no matter how they're generated or which application generated them). If you can't identify which key you want, then neither can cryptlib.

When will cryptlib support OAEP? RSA-PSS?

New crypto algorithms and mechanisms will be supported in cryptlib when they become generally adopted in implementations of security standards like SSL/TLS, S/MIME, ssh, and PGP. Without this general support, there's little use for them since absolutely nothing would be able to make use of them even if they were present in cryptlib (that is, any data produced using these algorithms would be unusable by any other implementation). Note also that:

Does cryptlib support AADS, CDMF, CMC, CMMF, CPM, CRS, CSVP, DHPOP, DCS, DVCS, ICAP, OCDP, QC, RMP, SCVP, SDSI, SPKI, VMP, ... ?

Standards groups are constantly inventing new standards. Many will disappear without trace, some will be implemented by a few vendors (often in an incompatible manner) and ignored by the rest, some will be so complex and difficult to interpret that they won't be viable for years (if ever), and a very small number will survive and prove useful. The cryptlib developers keep a close eye on the standards situation and will support those that serve a useful purpose and have good industry support (note that being hyped in the trade press does not constitute good industry support). The intention behind taking this cautious approach is to avoid having users locked into a collection of orphaned and legacy protocols that have very little support elsewhere. Since cryptlib is available in full source code form, you're welcome to implement any particular protocol you require yourself.

Does cryptlib have FIPS 140 certification?

cryptlib was designed from the outset to be certifiable at the highest FIPS 140 level, level 4. However, each certification is specific to a particular hardware and software platform and a particular FIPS 140 level, so there's no such thing as a generic "FIPS 140 certification" (although vendor marketing often confuses the issue). If you need to use a FIPS 140 certified toolkit, we'd be happy to get the certification done for you at your required level and with the required hardware and software combination, please contact us to discuss the details and cost involved.

Does cryptlib handle base64/MIME encoding/RFC 822/SMTP/POP3/IMAP messaging?

Mailer functions such as base64/transfer-encoding and sending and receiving mail are an MUA/MTA issue, while cryptlib is a crypto toolkit and not a mailer. The manual contains further information on interfacing it with various MUAs/MTA's. In particular, MIME processing and base64 en- and decoding require an enormous amount of functionality to handle mailers that mangle or rewrite content, change line lengths and terminators, substitute characters in text, escape or otherwise alter values, and so on. This is what MIME-processing agents like mailers do. cryptlib is not a mailer or MIME-processing engine, but will accept content coming from a MIME-processing engine and work with that.