FAQ

It’s 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.

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

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

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.

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.

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

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

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.

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.

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.