readme

cryptlib安全工具包

Changes in 3.3.2 release
========================

This release features numerous updates to the build mechanism and code to
handle new compiler versions, as well as workarounds for interoperability
problems with other implementations.  This version also features numerous
reliability and stability enhancements.

Changes in 3.3.1 release
========================

This release features ongoing minor updates and changes requested by users, as
well as updates to work with the (almost-) TR 24731 stdlib replacements in VS
2005.  This is mainly a cleanup and consolidation release after 3.3.0, however
one important reason to upgrade is that the pre-generated test keys will
expire shortly after the 3.3.1 release, which will produce warnings in the
self-test and self-test failures (X.509 certs have limited lifetimes due to
their expiry dates, and the code is warning that they're past their use-by
date).  cryptlib has to set some sort of expiry date for the keys because the
format requires it, but an unfortunate side-effect of this is that every now
and then the test keys needed for the self-test expire.  This release updates
the test keys for another few years.

Changes in 3.3 release
======================

This version of cryptlib is a minor-version stepping from the 3.2.x code base
to the 3.3.x code base.  Minor-version steppings are source-code compatible
with previous versions but not binary compatible.  This means that you need to
rebuild the app.calling cryptlib when you rebuild cryptlib.  In particular two
facilities that have been included for backwards-compatibility with code from
up to five years ago have now been removed: It's no longer possible to call
cryptPushData() with NULL pointers as an alternative to calling
cryptFlushData(), and the obsolete CRYPT_CERTINFO_CURRENT_xxx attributes,
which were mapped internally to the CRYPT_ATTRIBUTE_CURRENT_xxx attributes,
have been removed.

This release features more internal changes to handle internal consistency
checking, as well as fixes for a few minor issues arising from the 3.2.3
release.

Changes in 3.2.3 release
========================

This release features a considerable number of internal changes to clean up
some sections of the code that had grown beyond their original design, as well
as ongoing minor updates and changes requested by users.  This is mainly a
cleanup and consolidation release after 3.2.2.

Changes in 3.2.2 release
========================

The bignum code has been updated to the latest version, which is no less
ghastly than before but somewhat faster, particularly on x86 systems.

Changes in 3.2.1 release
========================

The zlib code has exhibited a number of security vulnerabilities, both in the
rather dated 1998-vintage zlib 1.1.x code and the much newer zlib 1.2.x code.
In order to avoid exposing cryptlib users to any new technology until it's
proven itself in the field, cryptlib has stayed with the old zlib code base,
which has avoided problems arising from the vulnerabilities found in the 1.2.x
code.  However, the 1.2.x code base does have a number of advantages over the
old 1.1.4 code, including better compression, much faster compression and
decompression, and significantly less memory consumption, particularly for
decompression.  Another potential problem with 1.1.4 is that there may be as
yet undiscovered problems in it that no-one's found yet because they're
concentrating on the newer 1.2.x instead.

Because zlib 1.2.x includes a significant rewrite of a fair portion of the
code, it's not possible to simply switch from one version of zlib to the other
at the flip of a compiler switch.  Based on user feedback, the preferred
behaviour is to have cryptlib move from the old 1.1.x to the current 1.2.x
code base, so cryptlib 3.2.1 uses zlib 1.2.3 (those values are pure
coincidence).  Users concerned about security issues should disable the
compression code (undefine USE_COMPRESSION in cryptini.h) unless it's actually
required.

Support of autoproxy configuration (under operating systems that implement
automatic network proxy discovery) has been added.  This includes support for
SOCKS-style HTTP proxies as well as the originally implemented HTTP-
application-gateway HTTP proxies.

Several minor portability issues in 3.2 have been fixed, among other things a
workaround for a problem in gcc 4.0 that prevented the code from compiling.

Changes in 3.2 release
======================

The version that would have been released as 3.11 has been released as 3.2 to
avoid version-numbering confusion. Future releases will use a three-digit
numbering scheme x.y.z, where each of x, y, and z will constitute a single
digit, to avoid confusion over whether the '11' in '3.11' is 11 or 0.11.

The network timeout handling has been split into distinct read and write
timeouts to allow more flexible configuration of network data handling,
typically very small read timeouts to ensure that cryptlib never blocks while
waiting for data, and slightly larger write timeouts to ensure that all data
is completely written when requested.

Client authentication for sessions that support this (only the secure data
sessions, SSH and SSL/TLS, use client authentication) has been changed
slightly.  In previous releases, cryptlib would always allow the client's
authentication and complete the handshake, leaving it to the caller to shut
down the session later on if there was a problem.  As of this release, server
sessions will return a CRYPT_ENVELOPE_RESOURCE in the same way that envelopes
do when you activate them, to indicate that you need to provide further
information in order to continue.  If you receive this status when you try to
activate a server session, you can read the user details via the
CRYPT_SESSINFO_USERNAME and CRYPT_SESSINFO_PASSWORD attributes, and either
comfirm the authentication by setting the CRYPT_SESSINFO_AUTHRESPONSE to true
or deny it by setting it to false.  You then re-activate the session, and
cryptlib will complete the handshake.  This allows you to check the
authentication details before allowing the handshake to continue.  If you'd
prefer the previous behaviour, just set CRYPT_SESSINFO_AUTHRESPONSE to true
before you activate the session and cryptlib will handle confirmation of
authentication itself.

Because the handshake is now controlled by the server rather than the client
(that is, cryptlib won't sit in a loop reading all data from the client, but
will return to the caller to await further input), it's possible that the
client will send further session-control information after the handshake has
completed.  To respond to any additional information that the client may send,
your server should try and pop client data before it sends any of its own
data.  If the server sends its data first, the client may interpret the
server's data as an (invalid) response to a request that it has in progress.
The manual contains more details on the new client authentication and server
data handling process.

Starting with releases after 3.2, the attribute cursor manipulation functions
will be unified so that they work identically for all container objects that
maintain lists of attributes (most of this interface is already available in
3.2 for forwards-compatibility reasons).  This means that the three attribute-
list mechanisms CRYPT_CERTINFO_CURRENT_EXTENSION,
CRYPT_CERTINFO_CURRENT_FIELD, and CRYPT_CERTINFO_CURRENT_COMPONENT (for
certificates), CRYPT_ATTRIBUTE_CURRENT_GROUP (formerly
CRYPT_ENVINFO_CURRENT_COMPONENT) for envelopes, and the future
CRYPT_ATTRIBUTE_CURRENT_GROUP for session objects will be folded into the
single mechanism CRYPT_ATTRIBUTE_CURRENT_GROUP, CRYPT_ATTRIBUTE_CURRENT, and
CRYPT_ATTRIBUTE_CURRENT_INSTANCE.  This provides both a unified, consistent
interface across the different object types and allows envelope and session
attributes to be handled in the same way as certificates currently are.  For
example under the older cryptlib 3.1 behaviour envelope signatures were
implicitly selected by reading the signature attribute, which changed the
current selection of the signature result and extra signature information
attributes.  From releases after this one envelope signature attributes are
grouped by signature, so selecting the first signature explicitly selects the
associated signature key, signature result, and extra signature information
attributes, selecting the second signature explicitly selects the associated
information for that, and so on.  In addition reading this information under
3.1 and earlier was something of a hunt-and-peck approach that required
reading each possible attribute in turn to see whether it was present.  The
attribute cursor interface allows each present attribute to be enumerated
using the attribute cursor, with cryptlib doing the work of sorting out what's
present and what isn't.  Finally, cryptlib 3.2 allows more session attributes
to be accessed by the caller, which requires the use of attribute cursors
since many of them are composite values or multi-valued attributes.

As part of this unification of mechanisms, the CRYPT_ENVINFO_CURRENT_COMPONENT
attribute has been renamed CRYPT_ATTRIBUTE_CURRENT_GROUP for compatibility
with future cryptlib releases.  For certificates, cryptlib 3.11 supports both
the legacy CRYPT_CERTINFO_CURRENT_xxx attributes and the new
CRYPT_ATTRIBUTE_CURRENT_xxx ones, so you can either keep using the
certificate-specific cursor attributes for now or move to the universal cursor
attributes for compatibility with future versions.  All that's necessary to
upgrade is a search and replace in your code to rename the attributes.  More
information on the unified attribute cursor mechanism is given in the
Introduction section of the manual.

The various situation-specific SSH attributes like
CRYPT_SESSINFO_SSH_SUBSYSTEM and CRYPT_SESSINFO_SSH_PORTFORWARD have been
replaced with more generic forms for compatibility with future cryptlib
versions, which allow more complete control over SSH channel types and
parameters.  See the manual for details on creating and controlling SSH
channels using the new attributes.

The SHA-2 algorithm is now enabled by default (previously it had to be
explicitly enabled via a compile-time option).  Note that this algorithm isn't
supported by most software and standards, so using it in anything other than
closed environments will lead to interoperability problems.  If you want to
use SHA-2, you should test it against any other software that you need to
interoperate with to ensure that it can handle this algorithm.

The Unix randomness slow poll now has an early-out mechanism that avoids the
full heavyweight slow poll if sufficient entropy is available without it.
This typically occurs on systems with both built-in randomness sources and
either a kernel statistics interface or an advanced /proc interface, which
provide the same data as the full slow poll at a fraction of the overhead.

Changes in 3.11 beta 1
======================

As noted in the 3.1 release notes, releases after 3.1 update the cryptlib 2.x
legacy functions cryptImport/ExportKey(Ex), cryptCreate/CheckSignature(Ex),
and cryptQueryObject to take a length parameter as their second argument.
These functions never took a length parameter in their original form because
they dealt 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 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.

In addition to the cryptlib 2.x legacy functions, two standard data-returning
functions cryptExportCert and the rarely-used cryptGetCertExtension now also
take a length parameter to specify the maximum buffer size.  This brings them
into line with the (updated) legacy functions, and allows cryptlib to perform
better checking of user-supplied parameters, particularly in the case of
languages like Visual Basic and Java where the mapping of language-native data
types to the blocks of memory used by a C-language library can be tricky.

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