bcl32.lib (6656, 2003-12-28)
bn\alpha.s (57887, 2002-02-05)
bn\bn-elf.s (38304, 2002-02-05)
bn\bn-out.s (38368, 2002-02-05)
bn\bn-sol.s (38304, 2002-02-05)
bn\bn-win32.asm (32768, 2002-02-05)
bn\bn-win32.obj (5442, 2002-02-09)
bn\bn.h (22378, 2003-11-18)
bn\bn_add.c (7308, 2000-12-08)
bn\bn_asm.c (19338, 2003-11-17)
bn\bn_ctx.c (4936, 2003-11-17)
bn\bn_div.c (11034, 2003-11-14)
bn\bn_exp.c (20445, 2000-12-08)
bn\bn_exp2.c (10635, 2000-12-01)
bn\bn_gcd.c (14423, 2001-04-09)
bn\bn_lcl.h (15035, 2003-11-17)
bn\bn_lib.c (19345, 2003-11-17)
bn\bn_mod.c (10088, 2001-04-09)
bn\bn_mont.c (9997, 2003-11-17)
bn\bn_mul.c (19058, 2003-05-28)
bn\bn_prime.h (15256, 2000-02-17)
bn\bn_recp.c (7122, 2003-11-17)
bn\bn_shift.c (5723, 2000-12-01)
bn\bn_sqr.c (7779, 2001-09-05)
bn\bn_word.c (5580, 2002-10-15)
bn\ia64.S (42581, 2002-02-05)
bn\mips3.s (37614, 2002-02-05)
bn\pa-risc2.s (48374, 2002-02-05)
bn\sparcv8.S (28245, 1999-07-25)
bn\sparcv8plus.S (32603, 2002-02-05)
certinst.dsp (3998, 2003-02-24)
certinst.dsw (539, 2000-03-02)
cert\cert.h (43942, 2003-12-06)
cert\certattr.h (11884, 2003-09-13)
cert\certcget.c (54996, 2003-12-12)
cert\certchk.c (55088, 2003-12-12)
cert\certchn.c (55413, 2003-12-20)
cert\certcset.c (59852, 2003-11-29)
cert\certdn.c (49245, 2003-12-20)
cert\certechk.c (29245, 2003-11-27)
... ...
Changes due in post-3.1 versions
================================
Releases after 3.1 will update the cryptlib 2.1 legacy functions
cryptImport/ExportKey and cryptCreate/CheckSignature to take a length
parameter as their third argument. These functions never took a length
parameter in their original form because they deal with encoded signature/key
exchange data, for which it's always possible to determine the length by
parsing it. However, this makes checking of user-supplied parameters
difficult - cryptlib always knows how much output it'll produce, but it can't
be sure that the user wants (or expects) that much output, particularly if
they've forgotten to perform a length check before exporting a key or creating
a signature. In order to avoid this problem, releases after 3.1 will make
this minor API change, which fixes the last of the old cryptlib 2.x functions.
Since most people use the higher-level API functions, this change shouldn't
affect the majority of users.
Changes in 3.1 release
======================
The final release contains mostly minor tweaks based on user feedback from the
3.1 final betas, with no noticeable external changes. Internally, the HTTP
engine has been significantly improved, TLS 1.1 is now supported (although at
release time there were no other known implementations of this to test
against), the BeOS port has been re-done to handle the current state of the OS
using GNU development tools instead of the original Be ones (thanks to Simon
Taylor for providing access to his system to do the work on), and the
perpetual tweaking of the networking subsystem to handle OS-specific quirks
has continued.
Changes in 3.1 beta 5
=====================
This release contains an extensive rewrite of the network-layer code to handle
various quirks and system-specific peculiarities in sockets implementations.
For this reason it's strongly recommended that if you're using secure sessions
or networking, you move to this version as quickly as possible. In addition
the code is now IPv6-enabled as part of the rewrite. In connection with this,
it's now possible to specify connect and network timeouts at the per-session
level rather than only as a cryptlib-wide option. To do this, set the timeout
value giving a specific session as the target object rather than CRYPT_UNUSED
for all of cryptlib:
cryptSetAttribute( cryptSession, CRYPT_OPTION_NET_TIMEOUT, timeout );
All of the session objects now provide extensive text diagnostics of errors
via the CRYPT_ATTRIBUTE_INT_ERRORMESSAGE attribute. This means that if a
session encounters a problem in communicating with another system, the
extended error message will usually provide additional information that goes
beyond the standard error code.
Support for SSHv2 subsystems such as SFTP has been added via the
CRYPT_SESSINFO_SSH_SUBSYSTEM attribute, and support for SSL/TLS with shared
keys (e.g. passwords) has been added. This allows secure SSL with mutual
authentication of both client and server, without the need for either
expensive server certificates or the complexity of client certificates. In
addition the shared-key mechanism is significantly faster than operations
involving certificates and private keys, and places far less load on both
client and server.
The CRYPT_OPTION_CERT_OBLIVIOUS option introduced in beta 4 has been changed
from a simple boolean value to a multivalued option
CRYPT_OPTION_CERT_COMPLIANCELEVEL, which indicates the level of checking
applied to certificates. This ranges from CRYPT_COMPLIANCELEVEL_OBLIVIOUS
(almost no checking except for the signature) through to
CRYPT_COMPLIANCELEVEL_PKIX_FULL (full compliance with PKIX certificate
standards). The default is CRYPT_COMPLIANCELEVEL_STANDARD, which provides a
reduced level of checking for compliance with other certificate software.
The CRYPT_ERROR_BUSY status has been renamed to CRYPT_ERROR_TIMEOUT to make it
more consistent with conditions like network timeouts, which is where it most
commonly occurs.
Some of the database keyset types have been renamed to make the names more
consistent. The three types are now CRYPT_KEYSET_ODBC for databases accessed
through an ODBC interface, CRYPT_KEYSET_DATABASE for databases with the
backend-specific interface code compiled into cryptlib, and
CRYPT_KEYSET_PLUGIN for databases accessed via the cryptlib database plugin
interface. The CRYPT_KEYSET_DATABASE type can be selected in the usual manner
at compile time with the USE_xxx compile options, see the manual for more
details on databases and compile options.
Changes in 3.1 beta 4
=====================
The changes in this release are mostly to fix a variety of minor problems that
cropped up in beta 3 related to portability across different systems. One
notable change is the inclusion of the CRYPT_OPTION_CERT_OBLIVIOUS
configuration option. This option is present in order to allow cryptlib to
handle the large number of broken certificates in use. Enabling this option
(setting it to TRUE) will cause cryptlib to ignore all certificate extensions
except key usage and the CA flag, making it compatible with other PKI
software. A future version of cryptlib will replace this option with a
multivalue selection allowing a choice of checking ranging from very little
(in order to be compatible with existing software and to process existing
certiificates) through to full PKIX compliance (which will, however, reject a
large number of certificates in use today).
Changes in 3.1 beta 3
=====================
The way in which GeneralNames and DNs in GeneralNames are selected has
changed. Until now GeneralNames were selected with:
cryptSetAttribute( cryptCert, attributeID, CRYPT_UNUSED );
which selected the GeneralName with the given attributeID and also updated the
attribute cursor. Selecting the DN within the GeneralName required a second
selection to specify the DN. This special-case behaviour was inconsistent
with the way other attributes were handled, and caused some confusion for
users, as well as obscuring the fact that the attribute cursor was being
updated as it would be for an explicit attribute selection. Beta 3 changes
the selection mechanism so that it matches that used for all other attributes:
cryptSetAttribute( cryptCert, CRYPT_CERTINFO_CURRENT_EXTENSION,
attributeID );
(or whatever alternative attribute cursor mechanism is preferred). In
addition, it's no longer necessary to perform a two-stage select for DNs in
GeneralNames, since these are now implicitly selected by selecting the
GeneralName that contains them. This means that handling of GeneralName
attributes is now consistent with all other attribute types.
Because GeneralNames are now automatically selected, you need to be careful
when working with a DN such as the certificate subject name after selecting a
GeneralName, since a GeneralName contains its own DN which will be the one
that's accessed after selecting the GeneralName. For example if you set an
email address (which is part of the GeneralName), this will select the
GeneralName, and any subsequent DN accesses will refer to the DN inside the
GeneralName rather than the subject name DN. It's good practice to move back
to the subject name with:
cryptSetAttribute( cryptCert, CRYPT_CERTINFO_SUBJECTNAME,
CRYPT_UNUSED );
after working with a GeneralName to make sure you're referring to the correct
DN.
Microsoft broke the Jet (MS Access) database engine at around SP4 (opinions on
the exact time vary). This version, or newer versions, may be installed
automatically when applying service packs or installing other software
(different broken versions of Jet are installed in Win2K SP2 and SP3, for
example, and it's built into Windows XP). The symptoms are that when running
the self-test you'll get an error message "Cannot open any more tables" even
though no tables are open, or more seriously a deadlock inside the VC++
runtime file access routines. The details of this problem are discussed in
Microsoft Knowledge Base Article 304536, Microsoft Knowledge Base Article
282010, and Microsoft Knowledge Base Article 239114.
The Microsoft-recommended fix is to upgrade to Jet SP6. This typically
requires downloading and installing the SP6 upgrade from the Microsoft
Download Centre, simply installing recent MDAC components won't work since
there were no Jet components included after MDAC 2.5 SP2, and installing
Office XP or Access 2002 may not work either since the setup programs only
update system files in certain situations and to a certain level. On the
other hand Jet SP6 may not install unless it detects an appropriate service
pack level on the system.
Non-Microsoft advice is to downgrade to a version of Jet at SP3 or earlier by
replacing msjetoledb40.dll and msjet40.dll with files from JET OLE DB SP3,
since even the latest version (SP6) still appears to exhibit these problems. A
better solution is to avoid the use of Jet entirely, and in particular you
should *never* use Jet in a production environment since it's far too buggy
and unstable to trust live data to (it was probably named Jet because it both
sucks and blows).
Changes in 3.1 beta 2
=====================
The last two type names that didn't follow the pattern xxx_TYPE, CRYPT_ALGO
and CRYPT_MODE, have now been brought into line with the other names, so you
need to change the type names to CRYPT_ALGO_TYPE and CRYPT_MODE_TYPE if you're
using them in your code.
SSHv2 server support is now present.
PKCS #11 devices can now be auto-detected by specifying the device name as
"[Autodetect]" if the device name isn't known.
Pre-connected network sockets can be supplied to sessions as the
CRYPT_SESSINFO_NETWORKSOCKET attribute, rather than having cryptlib
connect/disconnect the socket itself.
The PKCS #15 format has had various features added to it over time (see the
note for 3.0 beta 1), cryptlib has supported these in a read-only manner,
meaning that it creates keysets that are as backwards-compatible as possible
with old versions of the code that used earlier versions of PKCS #15. In
order to make some features like certificate update in a keyset possible, it's
necessary to write keyset fields from newer versions of PKCS #15. All betas
after this one will write these newer fields in order to enable advanced
features of PKCS #15. Anyone still using very old betas should upgrade to a
current version in order to take advantage of the advanced features supported
by newer-format PKCS #15 keysets.
Changes in 3.1 beta 1
=====================
Beta 1 includes support for PGP and OpenPGP, which is handled in standard
envelope fashion with a data format of CRYPT_FORMAT_PGP. Note that there are
a number of incompatible and semi-compatible variants of PGP in existence,
with the major types being PGP 2.x, PGP 5.x, NAI PGP, GPG, and the ckt PGP
builds, and many interesting lesser variations such as the disastry builds
that take PGP 2.x and update it to support OpenPGP ciphers without actually
being OpenPGP. An overview of different PGP versions can be found at
http://rmarq.pair.com/pgp/, and detailed information on incompatibilities can
be found at http://home.arcor.de/kraven/pgp/pgpindex.html. cryptlib has been
tested against most normal versions of PGP, but there will certainly be
versions out there that produce data that cryptlib can't read (one example
being a version that uses random key IDs in encrypted data in order to obscure
who the data is encrypted for, which also makes it impossible to decrypt with
any normal PGP version). If you run into something produced by one of these
oddball versions, please send me a copy so that I can determine whether it's
worth adding custom code to support it.
The PGP data format imposes a number of restrictions on the standard enveloping
process, which include:
- Use of nested signed data is discouraged unless you add an intermediate
layer of encryption, since PGP doesn't directly handle nested signatures.
- When signing data, the nested content type can only be the default (data)
for the reason given above.
- It's not possible to mix password and public-key key exchange actions in
the same message. Similarly, it's not possible to have more than one
password key exchange action in one message.
- Handling of separate hashing for detached signatures is somewhat peculiar
and requires special care.
Changes in 3.0 release
======================
cryptlib 3.1 will introduce a new function cryptFlushData() to replace the
current practice of calling cryptPushData() will all-null parameters, a change
required for languages like Delphi and VB that don't handle C null pointers
too well. This function is already present in 3.0 for forwards-compatibility
purposes, it's recommended that you update your code to call cryptFlushData()
in place of cryptPushData() with null parameters (although the existing
cryptPushData() mechanism will still work).
The Unix randomness-gathering code will now check for and use EGD/PRNGD if
they're available.
The requirement that cryptlib be built via a network share under Windows has
been removed.
HTTP keyset access (CRYPT_KEYSET_HTTP) formerly required that the keyset be
opened without a name being given, with the full URL being specified as the key
ID to retrieve keys. This was both somewhat inconsistent with the other keyset
types, and didn't work well with persistent connections, for example where
multiple certificates were being read from a single server. This has been
changed so that the server URL is given when the keyset is opened as it is for
other keyset types, and a key ID is given when reading individual keys. When
reading keys with a fixed URL (with no per-key ID), the special ID "[none]" can
be used to indicate that the server URL points directly at the certificate. In
the simplest case the previous usage:
cryptKeysetOpen( &cryptKeyset, CRYPT_UNUSED, CRYPT_KEYSET_HTTP, NULL,
CRYPT_KEYOPT_READONLY );
cryptGetPublicKey( cryptKeyset, &cryptCert, CRYPT_KEYID_NAME,
"http://www.server.com/cert.der" );
now becomes:
cryptKeysetOpen( &cryptKeyset, CRYPT_UNUSED, CRYPT_KEYSET_HTTP,
"http://www.server.com/cert.der", CRYPT_KEYOPT_READONLY );
cryptGetPublicKey( cryptKeyset, &cryptCert, CRYPT_KEYID_NAME,
"[none]" );
Reading multiple certificates, for example via a CGI interface on the server,
is done with:
cryptKeysetOpen( &cryptKeyset, CRYPT_UNUSED, CRYPT_KEYSET_HTTP,
"http://www.server.com/certstore.cgi",
CRYPT_KEYOPT_READONLY );
cryptGetPublicKey( cryptKeyset, &cryptCert, CRYPT_KEYID_NAME,
"user1" );
cryptGetPublicKey( cryptKeyset, &cryptCert, CRYPT_KEYID_NAME,
"user2" );
cryptGetPublicKey( cryptKeyset, &cryptCert, CRYPT_KEYID_NAME,
"user3" );
Changes in 3.0 final beta
=========================
The cryptlib 3.0 final release divides the network timeout parameter into two
parts, a CRYPT_OPTION_NET_CONNECTTIMEOUT which is applied during the connection
setup process and a CRYPT_OPTION_NET_TIMEOUT which is applied during reads and
writes (although in practice writes are almost always instantaneous). This
means that it's now possible to avoid nonblocking I/O if required.
Use of SSL/TLS client certificates is now enabled.
The final version of the S/MIME PasswordRecipientInfo (PWRI) RFC contained a
change in the way the key wrap algorithm is identified. The cryptlib final
release produces a PWRI that follows the final RFC, but will also read the
older format produced by earlier versions of cryptlib. If it's necessary to
generate PWRI data in the old format, you can change the "#if 1" in
keymgmt/asn1objs.c to "#if 0" to produce the older format.
Support for extended CMP user configurability via PKIUser objects has been
added, this allows user details to be pre-configured at the CA rather than
requiring the user to know them.
Changes in 3.0 beta 6
=====================
Beta 6 reduces the plethora of key generation functions by allowing the keysize
to be specified in the more standard way of setting the corresponding attribute
rather than having extraneous ...Ex() versions of the function that parallel
the standard form. If you were previously using the standard or asynchronous
...Ex() functions:
cryptGenerateKeyEx( cryptContext, keySize );
you can change to the newer form with a simple cut and paste:
cryptSetAttribute( cryptContext, CRYPT_CTXINFO_KEYSIZE, keySize );
cryptGenerateKey( cryptContext );
The table format for certificate stores has changed slightly to accomodate the
requirements of CMP servers (specifically the fact that they can cause things
to fail at inopportune moments), in order to handle this you need to recreate
the cert store (drop the previous table and create a new one with
CRYPT_KEYOPT_CREATE), if you need to move information across then create a new
table and insert into
select * from to copy the existing
certificates across. The newly-created table will support the storing of extra
information needed to handle restarts during CMP operations.
Support for the proposed AES algorithm is now included. Since this hasn't been
finalised by NIST yet, it is strongly recommended that you not use it until the
AES FIPS has been published. cryptlib will implement the form presented in the
final FIPS, which may be incompatible with the current version.
SSL and TLS support (both client and server) is now enabled, thanks to
endergone Zwiebeltuete for his help in getting this going.
Changes in 3.0 beta 5
=====================
Beta 5 removes the configuration options CRYPT_OPTION_FIXSTRINGS and
CRYPT_OPTION_CHECKENCODING since they shouldn't be needed any more as the ASN.1
code has been modified to handle all but the most broken certificates out
there.
Under Unix the library is now called libcl rather than libcrypt to reduce
problems with naming conflicts on some systems.
Support for the creation of one-step certificates that automatically work for
any purpose has been added and is enabled by setting the certificate's
CRYPT_CERTINFO_XYZZY attribute, more details are given in the manual.
OCSP, TSP, and ssh server support is now enabled (this complements the OCSP,
TSP, and ssh client support added in beta 3 and beta 4).
Changes in 3.0 beta 4
=====================
Beta 4 removes the need to use the TCP4U library for the network interface and
should now have networking enabled automatically on Unix and Windows systems.
With the enhanced networking support comes support for ssh secure sessions and
CMP (Certificate Mismanagement Protocol).
The creation of arbitrary-format DN's containing any sort of component in any
order or combination is now supported via the CRYPT_CERTINFO_DN attribute.
Changes in 3.0 beta 3
=====================
Beta 3 required one unfortunate change to the object creation functions which
involves the addition of a parameter that specifies the user who is to own the
object. For cryptlib 3.0 this means that as the second parameter for the
object creation functions (cryptCreateContext, cryptK ... ...