- What is Cryptlib?
- What software tools are included in the Cryptlib Software Security Development Toolkit?
- What platforms does Cryptlib run on?
- How much does Cryptlib cost?
- How is Cryptlib licensed?
- Which Algorithms does cryptlib support?
- What security standards does cryptlib comply with?
- Is Cryptlib subject to any export restrictions?
- Why do I get an “Assertion failed” when I use Cryptlib?
- Can I read keys from PFX/PKCS #12 files?
- Can I read keys from the Windows registry/CryptoAPI blobs/the Netscape cert database/etc?
- When will Cryptlib support SHA-2? OAEP?
- Does Cryptlib support AADS, CDMF, CMC, CMMF, CPM, CRS, CSVP, DHPOP, DCS, DVCS, ICAP, OCDP, QC, RMP, SCVP, SDSI, SPKI, VMP, … ?
- What about X9.42 key management in S/MIME?
- Does Cryptlib run under VM/CMS or MVS or on the AS/400?
- Does Cryptlib run under other random OS?
- Do you have any performance measurements for algorithm x?
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.
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 timestamping (TSP). 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, and cryptlib itself runs on virtually any operating system — cryptlib doesn’t tie you to a single platform. 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.509v3) with additional support for SET, Microsoft AuthentiCode, Identrus, RPKI, 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 certificate 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. cryptlib also provides a general-purpose crypto HAL (hardware abstraction layer) interface that allows it to use the native crypto capabilities available in some ARM, MIPS, and PPC cores used in embedded systems and devices.
cryptlib is supplied as source code for AMX, BeOS, ChorusOS, DOS, DOS32, eCOS, µC/OS-II, embedded Linux, FreeRTOS/OpenRTOS, IBM MVS, µITRON, Macintosh/OS X, OS/2, PalmOS, RTEMS, Tandem, ThreadX, 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), uClinux, VM/CMS, VxWorks, Windows 3.x, Windows 95/98/ME, Windows CE/PocketPC/SmartPhone, Windows NT/2000/XP/Vista/Windows 7 (32- and 64-bit versions), VDK, and Xilinx XMK. cryptlib’s highly portable nature means that it is also being used in a variety of custom embedded system environments.
cryptlib comes with language bindings for C / C++, C# / .NET, Delphi, Java, Perl, Python, and Visual Basic (VB).
Cryptlib is competitively priced and easily licensed compared to it’s rivals. We take a flexible approach, often adapting the license model to the customer’s requirements, rather than the other way around. This means we are always cost-competitive, and our clients have a real input into the final licensing arrangement. Please contact the Cryptlib sales team for a specific quotation and more details, and see the Cryptlib pricing information.
Cryptlib is distributed under a dual license that allows free, open-source use under a GPL-compatible license (a.k.a. the Sleepycat License) and closed-source use under a standard commercial license. In addition, Cryptlib is free for use in low-cost, non-open-source applications such as shareware, and for personal and academic or research use. The majority of commercial users who do not wish to disclose their source code must obtain a commercial license, which will be negotiated and agreed with Digital Data Security Limited, the registered owner of the Cryptlib software.
Specifically, any large-scale commercial use of Cryptlib requires a license. “Large-scale commercial use” means any revenue-generating purpose such as use for company-internal purposes, or use of Cryptlib in an application or product, with a total gross revenue of over US$5,000. This allows Cryptlib to be used in freeware and shareware applications, for evaluation and research purposes, and for non-revenue-generating or personal use without charge. In addition the author reserves the right to grant free licenses for commercial use in special cases (for example where there is a general benefit to the public), however you must contact the author for permission if you think you qualify.
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.
Included as core cryptlib components are implementations of the most popular encryption and authentication algorithms, AES, Blowfish, CAST, DES, triple DES, IDEA, RC2, RC4, RC5, and Skipjack conventional encryption, MD2, MD4, MD5, RIPEMD-160, SHA-1, and SHA-2/SHA-256 hash algorithms, HMAC-MD5, HMAC-SHA1, HMAC-RIPEMD-160, and HMAC-SHA2 MAC algorithms, and Diffie-Hellman, DSA, ECDSA, ECDH, Elgamal, and RSA public-key encryption algorithms.
All algorithms, security methods, and data encoding systems in cryptlib either comply with one or more national and international banking and security standards or are implemented and tested to conform to a reference implementation of a particular algorithm or security system. Compliance with national and international security standards is automatically provided when cryptlib is integrated into an application. These standards include ANSI X3.92, ANSI X3.106, ANSI X9.9, ANSI X9.17, ANSI X9.30-1, ANSI X9.30-2, ANSI X9.31-1, ANSI X9.42, ANSI X9.52, ANSI X9.55, ANSI X9.57, ANSI X9.62, ANSI X9.63, ANSI X9.73, ETSI TS 101 733, ETSI TS 101 861, ETSI TS 101 862, ETSI TS 102, FIPS PUB 46-2, FIPS PUB 46-3, FIPS PUB 74, FIPS PUB 81, FIPS PUB 113, FIPS PUB 180, FIPS PUB 180-1, FIPS PUB 186, FIPS PUB 198, ISO/IEC 8372, ISO/IEC 8731 ISO/IEC 8732, ISO/IEC 8824/ITU-T X.680, ISO/IEC 8825/ITU-T X.690, ISO/IEC 9797, ISO/IEC 10116, ISO/IEC 10118, ISO/IEC 15782, ITU-T X.842, ITU-T X.843, PKCS #1, PKCS #3, PKCS #5, PKCS #7, PKCS #9, PKCS #10, PKCS #11, PKCS #15, RFC 1319, RFC 1320, RFC 1321, RFC 1750, RFC 1991, RFC 2040, RFC 2104, RFC 2144, RFC 2202, RFC 2246, RFC 2268, RFC 2311 (cryptography-related portions), RFC 2312, RFC 2313, RFC 2314, RFC 2315, RFC 2437, RFC 2440, RFC 2459, RFC 2510, RFC 2511, RFC 2528, RFC 2560, RFC 2585, RFC 2630, RFC 2631, RFC 2632, RFC 2633 (cryptography-related portions), RFC 2634, RFC 2785, RFC 2876, RFC 2898, RFC 2984, RFC 2985, RFC 2986, RFC 3039, RFC 3058, RFC 3114, RFC 3126, RFC 3161, RFC 3174, RFC 3183, RFC 3211, RFC 3218, RFC 3261 (cryptography-related portions), RFC 3268, RFC 3274, RFC 3279, RFC 3280, RFC 3281, RFC 3369, RFC 3370, RFC 3447, RFC 3546, RFC 3565, RFC 3739, RFC 3770, RFC 3779, RFC 3851, RFC 3852, RFC 4055, RFC 4086, RFC 4108, RFC 4134, RFC 4210, RFC 4211, RFC 4231, RFC 4250, RFC 4251, RFC 4252, RFC 4253, RFC 4254, RFC 4256, RFC 4262, RFC 4279, RFC 4325, RFC 4334, RFC 4346, RFC 4366, RFC 4387, RFC 4419, RFC 4476, RFC 4648, RFC 4680, RFC 4681, and the Payment Card Industry (PCI) Data Security Standard (cryptography-related portions). In addition cryptlib can be used as an add-on security module to provide security services as per ISO/IEC 62351 for SCADA protocols such as IEC 60870-5, DNP 3.0, IEC 60870-6 (TASE.2 or ICCP), IEC 61850, and IEC 61334 (DLMS).
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.
(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).
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.
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.
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.
Since Cryptlib is open source software, you’re welcome to take the code and port it to any specialised OS that you require it to run on. The Cryptlib developers can offer assistance where possible. Anyone requiring a port is strongly encouraged to contact the developers, 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 mainframe environment).
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, application, etc etc etc, run the code and see.