cryptlib Security FAQ

cryptlib’s high level of portability and configurability makes it ideal for use in embedded systems with limited resources or specialised requirements, including systems based on Altera NIOS, ARM7, ARM9, ARM TDMI, Coldfire, Fujitsu FR-V, Hitachi SuperH, MIPS IV, MIPS V, Motorola ColdFire, NEC V8xx series, NEC VRxxxx series, Panasonic/Matsushita AM33/AM34, PowerPC, PowerQUICC, Samsung CalmRISC, SH3, SH4, SPARC, SPARClite, StrongArm, TI OMAP, and Xilinx MicroBlaze processors, as well as a large range of licensed derivatives of these cores, too many and varied to enumerate here.

cryptlib doesn’t perform any floating-point operations and runs directly on processors without an FPU, and through its crypto HAL (hardware abstraction layer) capabilities can take advantage of on-chip or in-system cryptographic hardware capabilities and crypto cores where available, typically on some of the more advanced ARM, MIPS, and PPC cores.

The code is fully independent of any underlying storage or I/O mechanisms, and works just as easily with abstractions like named memory segments in flash memory as it does with standard key files on disk.  It has been deployed on embedded systems without any conventional I/O capabilities or dynamic memory allocation facilities, with proprietary operating system architectures and services including ATMs, printers, web-enabled devices, POS systems, embedded device controllers, and similar environments, and even in devices with no operating system at all (cryptlib runs on the bare metal).  It can also run independent of any form of operating system, and has been run on the bare metal in environments with minimal available resources, in effect functioning as a complete crypto operating system for the underlying hardware. This make cryplib an excellent choice for SCADA cyber security applications

Because cryptlib functions identically across all supported environments, it’s possible to perform application development in a full-featured development environment such as Windows or Unix and only when the application is complete and tested move it to the embedded system.  This flexibility saves countless hours of development time, greatly reducing the amount of time that needs to be spent with embedded systems debuggers or in-circuit emulators since most of the development and code testing can be done on the host system of choice.

Supported embedded environments include AMX, ChorusOS, eCos, FreeRTOS/OpenRTOS, uITRON, LynxOS, MQX, PalmOS, RTEMS, ThreadX, T-Kernel, uC/OS II, VDK, VxWorks, and XMK (alongside embedded forms of conventional operating systems).   If required, the cryptlib developers can provide assistance in moving the code to any new or unusual environments.

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.

All commercial users 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.

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.

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 nothing would be able to employ them even if they were present in cryptlib. That is, any data produced using these algorithms would be unusable by any other implementation.  In addition:

* Because these new mechanisms are barely supported by anything, it will be difficult or impossible to use them with crypto hardware such as HSMs or smartcards.

* The security benefits of using some of these new techniques is questionable. For example, standard PKCS #1 version 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 version 1.5 securely, rather than requiring a move to OAEP or PSS.

* 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 because of this problem.

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, or you can contact the cryptlib developers if you require the implementation of any custom protocols.

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 (random/mvs.c and random/vm.c), miscellaneous code tweaks here and there, and fixing up the JCL. The last two are pretty trivial, the only thing that requires any real work is the randomness polling.  The AS/400 situation is somewhat worse, to date there have been multiple ports performed but none have been released.

cryptlib runs on virtually all generally-used operating system platforms, including embedded OSes and RTOSes, however there are a small number of relatively rare 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 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 almost impossible to answer this question because it depends on the system that 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.

NB: These are representative times.  If you need a definitive figure for your exact hardware, OS, compiler, application, etc., – run the code and test it.