Cryptlib FAQ

1. What is Cryptlib?
2. What software tools are included in the Cryptlib Software Security Development Toolkit?
3. What platforms does Cryptlib run on?
4. How much does Cryptlib cost?

5. How is Cryptlib licensed?

6. Is Cryptlib subject to any export restrictions?

7. Why do I get an "Assertion failed" when I use Cryptlib?

8. Can I read keys from PFX/PKCS #12 files?
9. Can I read keys from the Windows registry/CryptoAPI blobs/the Netscape cert database/etc?
10. When will Cryptlib support SHA-2? OAEP?
11. Does Cryptlib support AADS, CDMF, CMC, CMMF, CPM, CRS, CSVP, DHPOP, DCS, DVCS, ICAP, OCDP, QC, RMP, SCVP, SDSI, SPKI, VMP, ... ?
12. What about X9.42 key management in S/MIME?
13. Does Cryptlib run under VM/CMS or MVS or on the AS/400?
14. Does Cryptlib run under other random OS?
15. Do you have any performance measurements for algorithm x?

What is Cryptlib?

Cryptlib is a powerful software security toolkit that allows even inexperienced crypto-programmers to easily add world-class encryption and authentication services to their software. The high-level interface provides developers with the ability to add strong security capabilities to an application in as little as half an hour, without needing to know any of the low-level details that make the encryption or authentication work. As a result, Cryptlib dramatically reduces the costs involved in adding security to new or existing applications.

 

What software tools are included in the Cryptlib Software Security Development Toolkit?

At the highest level, Cryptlib provides implementations of complete security services such as S/MIME and PGP/OpenPGP secure enveloping, SSL/TLS and SSH secure sessions, CA services such as CMP, SCEP, RTCS, and OCSP, and other security operations such as secure time-stamping. Since Cryptlib uses industry-standard X.509, S/MIME, PGP/OpenPGP, and SSH/SSL/TLS data formats, the resulting encrypted or signed data can be easily transported to other systems and processed there. Cryptlib runs on virtually any operating system, and Cryptlib doesn't tie the developer to a single system. This allows email, files, and EDI transactions to be authenticated with digital signatures and encrypted in an industry-standard format.

 

Cryptlib provides an extensive range of other capabilities including full X.509/PKIX certificate handling (all X.509 versions from X.509v1 to X.509v4) with additional support for SET, Microsoft AuthentiCode, Identrus, SigG, S/MIME, SSL, and Qualified certificates, PKCS #7 certificate chains, handling of certification requests and CRLs including automated checking of certificates against CRLs and online checking using RTCS and OCSP, and issuing and revoking certificates using CMP and SCEP. In addition Cryptlib implements a full range of certification authority (CA) functions, as well as providing complete CMP, SCEP, RTCS, and OCSP server implementations to handle online certificate enrolment/issue/revocation and certificate status checking. Alongside the certificate handling, Cryptlib provides a sophisticated key storage interface that allows the use of a wide range of key database types ranging from PKCS #11 devices, PKCS #15 key files, and PGP/OpenPGP key rings through to commercial-grade RDBMS' and LDAP directories with optional SSL protection.

 

In addition to its built-in capabilities, Cryptlib can make use of the crypto-capabilities of a variety of external crypto-devices such as hardware crypto-accelerators, Fortezza cards, PKCS #11 devices, hardware security modules (HSMs), and crypto-smart cards. For particularly demanding applications, Cryptlib can be used with a variety of crypto-devices that have received appropriate FIPS 140 or ITSEC/Common Criteria certification. The crypto-device interface also provides a convenient general-purpose plug-in capability for adding new functionality that will be automatically used by Cryptlib.

 

What platforms does Cryptlib run on?

Cryptlib is supplied as source code for BeOS, DOS, IBM MVS, Macintosh/OS X, OS/2, Tandem, a variety of Unix versions (including AIX, Digital Unix, DGUX, FreeBSD/NetBSD/OpenBSD, HP-UX, IRIX, Linux, MP-RAS, OSF/1, QNX, SCO/UnixWare, Solaris, SunOS, Ultrix, and UTS4), VM/CMS, Windows 3.x, Windows 95/98/ME, Windows CE/PocketPC/SmartPhone and Windows NT/2000/XP. Cryptlib's highly portable nature means that it is also being used in a variety of custom embedded system environments. In addition, Cryptlib is available as a standard Windows DLL and an ActiveX control. Language bindings are available for C / C++, C# / .NET, Delphi, Java, Python, and Visual Basic (VB).

 

How much does Cryptlib cost?

No. The software has been developed outside the USA and is therefore not covered by US export restrictions and may be used anywhere in the world.

 

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.

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.

 

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).

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:

• Because these new mechanisms are barely supported by anything, it will be difficult to impossible to use them with crypto hardware such as HSMs or smart cards.
• The security benefits of using some of these new techniques is questionable. For example, standard PKCS #1 1.5 is secure when used properly (that is, there's no real security benefit to using OAEP). Protocols like TLS and S/MIME simply include a note about using PKCS #1 1.5 securely, rather than requiring a move to OAEP or Simple-RSA.
• If you use some new mechanism, there's a risk that you'll be stuck with an orphaned mechanism if something else comes into fashion. SET is stuck with a version of OAEP that nothing else uses any more. OAEP has itself been overtaken by things like Simple-RSA.
• Performance of SHA-2 on the x86 architecture is terrible due to the lack of CPU registers, so you should consider whether you really need this before deploying it on systems with Intel/AMD processors.

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.

This key management mechanism represented an attempt to avoid the RSA patent, however its adoption was severely hampered by the fact that US vendors already had RSA licenses, non-US vendors don't care (and in any case the patent has now expired, so they care even less), no CA's of note will issue X9.42 certificates, and even if they did almost no S/MIME implementations support it. Although X9.42 is listed as mandatory to implement for S/MIME v3, the approach being taken by most vendors (Cryptlib included) is to vaguely pretend to support X9.42 while actually concentrating on RSA, knowing that no one else really supports it either.

Yes and no. The IBM mainframe adaptation was performed by building the code under VM and bringing it as close as possible to building under MVS at which point the code snapshot was taken over by a company that generally doesn't talk to others about security issues and whose lawyers wouldn't allow the changes they made to go back into the code base - Open Source has yet to arrive there. This means that anyone wanting to run Cryptlib on IBM mainframes will need to duplicate some of the work they did: system information polling to gather randomness for key generation (misc/rndmvs.c and misc/rndvm.c), miscellaneous code tweaks here and there, and fixing up the JCL, which apparently wasn't very good :-). The last two are pretty trivial, the only thing that requires any real work is the randomness polling. A more recent port was performed by an open-source friendly company, and will hopefully be available towards the end of the year. The AS/400 situation is somewhat worse, to date there have been multiple ports performed but none have been released.

Cryptlib runs on all common operating system platforms, however there are some lesser-used OS's that it hasn't yet been ported to, generally because they're non-mainstream enough that access to a development system is difficult. Cryptlib has been designed for easy portability to any (vaguely normal) OS, targeting new systems hasn't proven much of a problem in the past.

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.