{"id":45186174,"url":"https://github.com/cryptlib/cryptlib","last_synced_at":"2026-02-20T11:01:46.269Z","repository":{"id":265227132,"uuid":"895479233","full_name":"cryptlib/cryptlib","owner":"cryptlib","description":"cryptlib security toolkit","archived":false,"fork":false,"pushed_at":"2026-02-15T16:08:10.000Z","size":24635,"stargazers_count":47,"open_issues_count":3,"forks_count":17,"subscribers_count":2,"default_branch":"main","last_synced_at":"2026-02-15T23:21:16.921Z","etag":null,"topics":["cryptography","eap-tls","eap-ttls","ocsp-client","ocsp-responder","peap","pgp","pkcs11","pkcs7","scep-client","scep-server","scvp","smime","ssh-client","ssh-server","timestamping","tls-client","tls12","tls13","x509"],"latest_commit_sha":null,"homepage":"","language":"C","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"other","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/cryptlib.png","metadata":{"files":{"readme":"README","changelog":null,"contributing":null,"funding":null,"license":"COPYING","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":"SECURITY.md","support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null,"notice":null,"maintainers":null,"copyright":null,"agents":null,"dco":null,"cla":null}},"created_at":"2024-11-28T09:35:53.000Z","updated_at":"2026-02-15T16:08:14.000Z","dependencies_parsed_at":null,"dependency_job_id":"44180255-5cb5-41f5-bf3b-4b5558cf396c","html_url":"https://github.com/cryptlib/cryptlib","commit_stats":null,"previous_names":["cryptlib/cryptlib"],"tags_count":1,"template":false,"template_full_name":null,"purl":"pkg:github/cryptlib/cryptlib","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/cryptlib%2Fcryptlib","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/cryptlib%2Fcryptlib/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/cryptlib%2Fcryptlib/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/cryptlib%2Fcryptlib/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/cryptlib","download_url":"https://codeload.github.com/cryptlib/cryptlib/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/cryptlib%2Fcryptlib/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":29648425,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-02-20T09:27:29.698Z","status":"ssl_error","status_checked_at":"2026-02-20T09:26:12.373Z","response_time":59,"last_error":"SSL_connect returned=1 errno=0 peeraddr=140.82.121.6:443 state=error: unexpected eof while reading","robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":false,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["cryptography","eap-tls","eap-ttls","ocsp-client","ocsp-responder","peap","pgp","pkcs11","pkcs7","scep-client","scep-server","scvp","smime","ssh-client","ssh-server","timestamping","tls-client","tls12","tls13","x509"],"created_at":"2026-02-20T11:01:45.549Z","updated_at":"2026-02-20T11:01:46.252Z","avatar_url":"https://github.com/cryptlib.png","language":"C","funding_links":[],"categories":[],"sub_categories":[],"readme":"Changes in 3.4.9 release\n========================\n\nThe TLS 1.3 code has received further updates based on deployment experience.\n\nThe TPM device interface has been rewritten to make it more portable across\ndifferent TPMs.\n\nOptional support for the X25519 and Ed25519 algorithms and corresponding\ncipher suites in TLS and SSH have been added.  These are disabled by default\nbecause of the very large amount of object code generated (the Curve25519\nmodule is the single largest one in all of cryptlib) and because the existing\nECDH/ECDSA functionality does the same thing in a fraction of the space.\n\nThe SSH server authentication handling has been locked down to restrict the\nfree-for-all that the RFC allows for.\n\nThe build process has been updated to take advantage of new capabilities and\ncode security features added in newer compilers.\n\nChanges in 3.4.8 release\n========================\n\nThe CRYPT_SESSINFO_SERVER_FINGERPRINT_SHA1 attribute for secure sessions has\nbeen changed to CRYPT_SESSINFO_SERVER_FINGERPRINT_SHA2 to reflect universal\nusage.\n\nChanges in 3.4.8 release\n========================\n\nThe minimum TLS version is now set to TLS 1.1.  This may cause problems with\nolder deployed implementations which often jumped from TLS 1.0 straight to TLS\n1.2, skipping TLS 1.1.  To change the minimum version back to TLS 1.0, change\nthe value in the protocolInfo structure at the end of session/tls.c.\n\nThe TLS 1.3 code has been updated based on deployment experience with 3.4.7 to\ndeal with issues with nonstandard TLS 1.3 implementations.\n\nWith this release, cryptlib 3.4.6, and by extension all earlier versions, have\nbeen end-of-life'd.\n\nChanges in 3.4.7 release\n========================\n\ncryptlib now supports SSH pre-authentication, which prevents SSH scanning\nattacks by blocking access before any part of the SSH handshake has occurred.\n\nSupport for custom crypto HALs has been extended so that it's now possible to\nplug in completely custom crypto to replace cryptlib's built-in crypto\nmechanisms.\n\ncryptlib now implements various EAP / RADIUS protocols combined with TLS,\nspecifically EAP-TLS, EAP-TTLS, and EAP-PEAP.  This allows the tunnelling of\narbitrary higher-level protocols like PAP, CHAP, and MS-CHAPv2 over the secure\nEAP TLS tunnel provided by cryptlib\n\nThe TLS server code now supports SNI-based virtual hosting so that it's\npossible to run multiple virtual servers on one IP address with the DNS host\nname being used to switch between them (the TLS client code has always\nsupported virtual hosting).\n\nSCVP client and server support has been added.  Note that SCVP is an\nextraordinarily complex, heavyweight, and ambiguously-specified mechanism for\ndoing a simple certificate check (see the cryptlib manual for details) and\nshould only be used if its use is mandated by interop agreements.\n\nTLS 1.3 support has been added but is disabled by default.  Despite its name,\nTLS 1.3 is a completely new protocol that runs alongside standard TLS and\ndoubles the size of the TLS stack if enabled.  In addition since a primary\ndesign goal for TLS 1.3 was to make the operations of large content providers\neasier (for example it relies on the client guessing a number of\ncharacteristics of the server, which works fine for Google clients connecting\nto nonstandard configurations in Google servers but less well for non-web-\nclient cases) it can lead to performance issues or interoperability problems\nwhere the client is unable to guess in advance what the server requires.\nUnless there's an external requirement for TLS 1.3 use it's recommended that\nusers continue with TLS 1.2.\n\nVarious attributes using the historic 'SSL' naming have been renamed to the\ncurrent term 'TLS', although the alternative SSL names are retained for the\ntime being for backwards compatibility.  This includes CRYPT_SESSION_SSL -\u003e\nCRYPT_SESSION_TLS, CRYPT_SESSION_SSL_SERVER -\u003e CRYPT_SESSION_TLS_SERVER, and\nCRYPT_SESSINFO_SSL_OPTIONS -\u003e CRYPT_SESSINFO_TLS_OPTIONS.  This backwards-\ncompatibility setting will be removed in a future version so any new code\nshould use the TLS naming rather than SSL naming.\n\nBeyond this the usual changes to enhance stability and code/data safety and\ndiagnose problems have been implemented.\n\nWith this release, cryptlib 3.4.5, and by extension all earlier versions, have\nbeen end-of-life'd.\n\nChanges in 3.4.6 release\n========================\n\nThis release adds support for 2FA for secure sessions, specifically TOTP\nauthentication as used by 1Password, Aegis Authenticator, Authy, Google\nAuthenticator, IBM Verify, LastPass Authenticator, Microsoft Authenticator,\nRed Hat FreeOTP, TOTP Authenticator, and many others.  Since this adds new\ncryptlib attributes for dealing with the 2FA process, code that uses cryptlib\nsessions will need to be recompiled to reflect the new attribute values.\n\nMost object types, and in particular certificate objects, now have extended\nerror information available as CRYPT_ATTRIBUTE_ERRORMESSAGE to match the\ninformation provided for other cryptlib objects.  In the case of certificates\nthis should make it easier to diagnose the often-complex reasons why\ncertificate checks fail.  More generally, CRYPT_ATTRIBUTE_ERRORMESSAGE should\nbe preferred over CRYPT_ATTRIBUTE_ERRORTYPE / CRYPT_ATTRIBUTE_ERRORLOCUS since\nthe text-form error message returns far more detailed information than the\nerror type code and locus do.  For debugging purposes, in the case of\ncertificate imports when cryptlib is built in debug mode it'll print the\nCRYPT_ATTRIBUTE_ERRORMESSAGE reason why a certificate import failed to the\ndebug output to help diagnose problems with certificates.\n\nOptional support for the ChaCha20 and Poly1305 algorithms and corresponding\ncipher suites in TLS have been added.  These are disabled by default because\nof the high level of difficulty in using them safely, don't enable these\nunless you know what you're doing.\n\nThe distinction between CRYPT_KEYSET_ODBC and CRYPT_KEYSET_DATABASE, present\nfor binary compatibility with very old cryptlib versions, has now been removed\nin that the two are mapped to the same value.  For new code, please use\nCRYPT_KEYSET_DATABASE since at some point the backwards-compatible definition\nCRYPT_KEYSET_ODBC will be removed.\n\nBeyond this the usual changes to enhance stability and code/data safety and\ndiagnose problems have been implemented.\n\nWith this release, cryptlib 3.4.4, and by extension all earlier versions, have\nbeen end-of-life'd.\n\nChanges in 3.4.5 release\n========================\n\nThis release now officially supports the WebSockets client/server\nimplementation that was added in 3.4.4.1 as a developmental feature.\n\nThe entropy-polling code has been improved to add polling of further entropy\nsources on different systems, including environmental monitoring such as\nthermal data, CPU instruction execution statistics, and similar low-level\nhardware-based information.\n\nSupport for hardware-based crypto outside of instruction/CPU-level support\nlike AES-NI and VIA Padlock has been added.  If present and enabled on the\nsystem, cryptlib will automatically use crypto hardware capabilities provided\nby CPUs such as Allwinner A-series, Marvell Kirkwood, NVIDIA Tegra, NXP i.MX,\nPowerPC, Rockchip RK-series, Qualcomm Snapdragon, Samsung Exynos, and TI OMAP.\n\nThe build process has been improved to take better advantage of system- and\ncompiler-specific capabilities, for example use of enhanced compiler\nfacilities like LLVM's SafeStack/CPI are now enabled if available, and\nparallel makes are supported on systems that support it.  In addition the\nautomatic detection and enabling of system facilities like hardware crypto and\nPKCS #11 devices has been improved.\n\nBeyond this, further changes to enhance stability and code/data safety and\ndiagnose problems interoperating with other systems have been implemented.\n\nWith this release, cryptlib 3.4.3, and by extension all earlier versions, have\nbeen end-of-life'd.\n\nChanges in 3.4.4.1 release\n==========================\n\nThis release updates the TLS cipher suite selection to deal with the problem\nthat several large Internet CDNs and service providers have recently chosen to\ndisable the standard PFS cipher suites, leaving only the rather unsafe RSA\nsuites available for use with older versions of TLS.\n\nIn addition this release contains a number of additional diagnostic\ncapabilities to identify interoperability problems with other crypto protocol\nimplementations.\n\nChanges in 3.4.4 release\n========================\n\nThis release adds support for TLS-LTS, fixing every (known) attack on TLS and\nproviding extra security against any future attacks (the previous addition of\nencrypt-then-MAC and extended master secret were part of this move).\n\nThis release also adds support for the final version of the SCEP standard,\nwhich replaces eighteen years worth of draft versions.\n\nPerformance in memory-constrained environments such as embedded devices has\nbeen improved, with additional configuration options to reduce memory usage to\nas little as 150-200K of code space for an SSH or TLS server.\n\nBeyond this, further changes to enhance stability and code/data safety have\nbeen implemented.\n\nWith this release, cryptlib 3.4.2, and by extension all earlier versions, have\nbeen end-of-life'd.\n\nChanges in 3.4.3 release\n========================\n\nThis release adds support for TLS encrypt-then-MAC, which fixes about fifteen\nyears' worth of oracle attacks against the SSL/TLS protocol, and TLS Extended\nMaster Secret, which fixes another collection of attacks.  It also adds\nsupport for the protocol-downgrade signalling cipher suite (SCSV), which helps\ndetect protocol-downgrade attacks.\n\nThe default build environment under Windows has been updated from VS 2010 to\nVS 2015, alongside the long-standing existing option to use VC++ 6.0.\n\nAll CRYPT_xxx_FINGERPRINT attributes now have explicit types as part of their\nnames in order to reduce confusion about their sizes.\nCRYPT_CERTINFO_FINGERPRINT is now CRYPT_CERTINFO_FINGERPRINT_SHA1 (the\nobsolete CRYPT_CERTINFO_FINGERPRINT_MD5 is no longer supported, as part of the\ngeneral removal of MD5 from circulation), and\nCRYPT_SESSINFO_SERVER_FINGERPRINT is now\nCRYPT_SESSINFO_SERVER_FINGERPRINT_SHA1.\n\nSupport for the obsolete and/or patented and/or insecure algorithms Blowfish,\nDES, RC2, RC5, Skipjack, MD2, MD4, MD5, HMAC-MD5, RIPEMD-160, and HMAC-RIPEMD\nhave been removed.\n\nThe SCEP implementation now supports both initialisation requests (protected\nby user name and password) and certificate update requests (protected by user\nname and signature).  Because of this you need to specify the SCEP request\ntype using the (slightly misnamed) CRYPT_SESSINFO_CMP_REQUESTTYPE attribute,\nwhich can be either CRYPT_REQUESTTYPE_INITIALISATION or\nCRYPT_REQUESTTYPE_CERTIFICATE.\n\nThe cryptlib keyset types CRYPT_KEYSET_ODBC and CRYPT_KEYSET_DATABASE have\nbeen unified under the name CRYPT_KEYSET_DATABASE, since they represented the\nsame thing.\n\nThe encryption mode CRYPT_MODE_OFB, which wasn't used in any known protocol,\nhas been removed, and replaced with CRYPT_MODE_GCM where available (in this\ncase only for AES).\n\nThe default key sizes used for PKC algorithms have been increased to provide a\nhigher margin of security.\n\nThe default hash algorithm used in various protocols is now SHA-2 rather than\nSHA-1.  Previous versions of cryptlib would automatically upgrade the hash\nalgorithm used to the strongest one supported by the peer if this was\ndetectable (for example by examining the hash algorithm used in the peer's\ncertificate), this version now makes SHA-2 the default.  Note that some\nprotocols that use hash algorithms employ them in the HMAC construct, which\nrenders them immune to standard attacks, so use of HMAC-SHA1 doesn't carry the\nsame concerns as use of pure SHA-1.\n\nAlongside the switch to SHA-2 as the default, support for the obsolete PGP2\nand SSLv3 protocols has been disabled.  If you need to work with them, you can\nenable them by building with USE_PGP2 or USE_SSL3, however these protocols are\nnow unsupported and the code for them will be removed in a future release.  In\nconjunction with this, support for the IDEA cipher, which is only used with\nPGP2, will also be removed.\n\ncryptlib now supports the Quantis quantum random number generator.  If you\nhave a quantum random number generator attached to your system, cryptlib will\nautomatically identify it and use it as an additional source of entropy for\nkey generation.\n\nWith this release, cryptlib 3.4.1, and by extension all earlier versions, have\nbeen end-of-life'd.\n\nChanges in 3.4.2 release\n========================\n\nThis is a maintenance release that adds better text-string diagnostics for a\nnumber of operations, fixing a long-standing PGP authenticated-encryption\ninteroperability issue that was obscure enough that no-one's ever noticed,\nincreasing compatibility (meaning adding lots of bug-workarounds) with\nMicrosoft's NDES SCEP server, providing more flexible handling of a variety of\nrarely-used protocol options and capabilities added at the request of users,\nand the usual ongoing updates for OSes and compiler versions.\n\nWith this release, cryptlib 3.4, and by extension all earlier versions, have\nbeen end-of-life'd.\n\nChanges in 3.4.1 release\n========================\n\nThis is a maintenance release for new OS and compiler versions, and\nspecifically VS 2010, which has trouble with the VS 2005 project files that\nwere included in previous releases.  Apart from various code updates, it adds\nclient-side SSL/TLS session resumption alongside the existing server-side\nsession resumption.\n\nWith this release, cryptlib 3.3.3, and by extension all earlier versions, have\nbeen end-of-life'd.\n\nChanges in 3.4 release\n======================\n\nThis version of cryptlib is a minor-version stepping from the 3.3.x code base\nto the 3.4.x code base.  Minor-version steppings are source-code compatible\nwith previous versions but not binary compatible.  This means that you need to\nrebuild the application calling cryptlib when you move to cryptlib 3.4.0 in\norder to add support for new attributes introduced for the post-3.3 API. In\naddition the cryptGenerateKeyAsync()/cryptAsyncQuery()/cryptAsyncCancel()\nfunctions, deprecated since 2007, have been removed for the 3.4 API change,\nand the transparent rewriting of CRYPT_CERTINFO_SUBJECTNAME and\nCRYPT_CERTINFO_ISSUERNAME selection commands to the pre-2007 form has been\ndisabled.\n\nThis release features the usual ongoing updates for new OS and compiler\nversions.  One significant update is direct support for x86-64 under 64-bit\nversions of Windows (this previously required a custom build), with the 64-bit\ntarget in the project file building a cl64.dll that's analogous to the 32-bit\ncl32.dll.\n\nThe TLS code has been updated to add support for TLS 1.2.  Since TLS 1.2 uses\ncryptographic mechanisms that are gratuitously incompatible with any other\nversion of SSL or TLS, the default version that cryptlib will advertise in a\nhandshake remains TLS 1.1.  If you want to use TLS 1.2 you need to explicitly\nenable it as described in the manual.  Note that because of the incompatible\nchanges made in TLS 1.2 there is (two years after its introduction) still very\nlittle support for it among vendors.  Expect interoperability problems.\n\nThis version of cryptlib implements RFC 5083 authenticated encryption.  PKCS\n#15 private keys are now protected in this manner (private-key data from older\nversions of cryptlib can still be read, but newer keys will be protected with\nfull authenticated encryption).  In addition data enveloped using\nCRYPT_FORMAT_CRYPTLIB will automatically use authenticated encryption while\nother formats (CRYPT_FORMAT_CMS, CRYPT_FORMAT_SMIME) will stay with\nunauthenticated encryption for compatibility with existing implementations.\nYou can enable authenticated encryption for the other formats (or turn it off\nfor the cryptlib format) as described in the manual.\n\nElliptic-curve cryptography is now supported, both at the low-level crypto\nmechanism level and in high-level protocols like X.509, SSL/TLS, S/MIME, and\nSSH.  To enable it, define USE_ECDH and/or USE_ECDSA in misc/config.h when you\nbuild cryptlib.\n\nCertificate fingerprints using SHA-2 and the future SHA-3 (when it's\nfinalised) is now supported with CRYPT_CERTINFO_FINGERPRINT_SHA2 and\nCRYPT_CERTINFO_FINGERPRINT_SHAng (use of the latter will return a\nCRYPT_ERROR_NOTAVAIL, it's only present as a placeholder for future releases).\n\nSupport for the Internet routing resource PKI (RPKI) has been added, see the\nmanual for details.\n\ncryptlib 3.4.0 has been updated to use zlib 1.2.4, the first zlib update in\nfive years.  As always, users concerned about security issues should disable\nthe compression code (undefine USE_COMPRESSION in misc/config.h) unless it's\nactually required.\n\nSeveral ambiguous attributes have been removed or renamed to make their role\nclearer.  For the keyset types, CRYPT_KEYSET_PLUGIN and\nCRYPT_KEYSET_PLUGIN_STORE have been removed since these have always been\nhandled identically to CRYPT_KEYSET_DATABASE and CRYPT_KEYSET_DATABASE_STORE.\nFor the error attributes, CRYPT_ATTRIBUTE_INT_ERRORCODE has been removed since\nthis wasn't very useful outside of cryptlib and\nCRYPT_ATTRIBUTE_INT_ERRORMESSAGE has been renamed CRYPT_ATTRIBUTE_ERRORMESSAGE\nto reflect its role alongside CRYPT_ATTRIBUTE_ERRORTYPE and\nCRYPT_ATTRIBUTE_ERRORLOCUS.\n\nWith this release, cryptlib 3.3.2, and by extension all earlier versions, have\nbeen end-of-life'd.\n\nChanges in 3.3.3 release\n========================\n\nThis is another maintenance release with updates for new compiler versions and\nOS releases, as well as code changes to handle upgrades to newer hash\nalgorithms in the SHA-2 family for protocols that previously used SHA-1.  In\naddition the Windows DLL version included with the release is now built with\nVS 2005 instead of VC 6, since it's unlikely that there are any systems left\nthat don't have the runtime libraries needed for this.\n\nA number of rarely-used facilities that, due to their complexity, have a large\nattack surface or considerable potential for abuse, have been disabled by\ndefault in this release.  These are DNS SRV, LDAP, string-format X.500 DNs,\nand SSH subsystems and channel multiplexing.  If you really require any of\nthese you can enable them as described in \"Optional cryptlib Components\" in\nthe manual.  You should only enable these facilities if you absolutely need\nthem, and your security guarantee is void if you do.\n\nThere's one small change made to the handling of certificate attribute\nselection, currently all attributes except certificate subject and issuer\nnames are selected with 'cryptSetAttribute( cryptCert,\nCRYPT_CERTINFO_CURRENT_ATTRIBUTE, \u003cattribute-type\u003e )' while the certificate\nsubject and issuer names are selected with 'cryptSetAttribute( cryptCert,\nCRYPT_CERTINFO_SUBJECTNAME, CRYPT_UNUSED )' (this is done for historical\nreasons because the subject and issuer names aren't X.509 certificate\nextensions and so exist in a different space than standard certificate\nextensions, putting them outside the reach of the standard attribute cursor\nmechanisms).\n\nThis version of cryptlib now allows issuer and subject names to be selected in\nthe same way as other attributes, 'cryptSetAttribute( cryptCert,\nCRYPT_CERTINFO_CURRENT_ATTRIBUTE, CRYPT_CERTINFO_SUBJECTNAME )'.  The previous\nmethod is still supported for backwards-compatibility purposes, but for\nforwards compatibility you should search your code for occurrences of\nCRYPT_CERTINFO_SUBJECTNAME/ISSUERNAME and switch the attributes around to use\nthe new form.  To alert you to cases where you're using the old way of doing\nthings, the debug build of cryptlib will thrown an exception if it detects\nthis (the standard build will continue to function as before, it's only the\ndebug build that will notify you of the superseded usage).\n\nWith this release, cryptlib 3.3.1, and by extension all earlier versions, have\nbeen end-of-life'd.\n\nChanges in 3.3.2 release\n========================\n\nThis release features numerous updates to the build mechanism and code to\nhandle new compiler versions, as well as workarounds for interoperability\nproblems with other implementations.  This version also features various\nreliability and stability enhancements.\n\nWith this release, cryptlib 3.3, and by extension all earlier versions, have\nbeen end-of-life'd.\n\nChanges in 3.3.1 release\n========================\n\nThis release features ongoing minor updates and changes requested by users, as\nwell as updates to work with the (almost-) TR 24731 stdlib replacements in VS\n2005.  This is mainly a cleanup and consolidation release after 3.3.0, however\none important reason to upgrade is that the pre-generated test keys will\nexpire shortly after the 3.3.1 release, which will produce warnings in the\nself-test and self-test failures (X.509 certificates have limited lifetimes\ndue to their expiry dates, and the code is warning that they're past their\nuse-by date).  cryptlib has to set some sort of expiry date for the keys\nbecause the format requires it, but an unfortunate side-effect of this is that\nevery now and then the test keys needed for the self-test expire.  This\nrelease updates the test keys for another few years.\n\nChanges in 3.3 release\n======================\n\nThis version of cryptlib is a minor-version stepping from the 3.2.x code base\nto the 3.3.x code base.  Minor-version steppings are source-code compatible\nwith previous versions but not binary compatible.  This means that you need to\nrebuild the application calling cryptlib when you rebuild cryptlib.  In\nparticular two facilities that have been included for backwards-compatibility\nwith code from up to five years ago have now been removed: It's no longer\npossible to call cryptPushData() with NULL pointers as an alternative to\ncalling cryptFlushData(), and the obsolete CRYPT_CERTINFO_CURRENT_xxx\nattributes, which were mapped internally to the CRYPT_ATTRIBUTE_CURRENT_xxx\nattributes, have been removed.\n\nThis release features more internal changes to handle internal consistency\nchecking, as well as fixes for a few minor issues arising from the 3.2.3\nrelease.\n\nChanges in 3.2.3 release\n========================\n\nThis release features a considerable number of internal changes to clean up\nsome sections of the code that had grown beyond their original design, as well\nas ongoing minor updates and changes requested by users.  This is mainly a\ncleanup and consolidation release after 3.2.2.\n\nChanges in 3.2.2 release\n========================\n\nThe bignum code has been updated to the latest version, which is no less\nghastly than before but somewhat faster, particularly on x86 systems.\n\nChanges in 3.2.1 release\n========================\n\nThe zlib code has exhibited a number of security vulnerabilities, both in the\nrather dated 1998-vintage zlib 1.1.x code and the much newer zlib 1.2.x code.\nIn order to avoid exposing cryptlib users to any new technology until it's\nproven itself in the field, cryptlib has stayed with the old zlib code base,\nwhich has avoided problems arising from the vulnerabilities found in the 1.2.x\ncode.  However, the 1.2.x code base does have a number of advantages over the\nold 1.1.4 code, including better compression, much faster compression and\ndecompression, and significantly less memory consumption, particularly for\ndecompression.  Another potential problem with 1.1.4 is that there may be as\nyet undiscovered problems in it that no-one's found yet because they're\nconcentrating on the newer 1.2.x instead.\n\nBecause zlib 1.2.x includes a significant rewrite of a fair portion of the\ncode, it's not possible to simply switch from one version of zlib to the other\nat the flip of a compiler switch.  Based on user feedback, the preferred\nbehaviour is to have cryptlib move from the old 1.1.x to the current 1.2.x\ncode base, so cryptlib 3.2.1 uses zlib 1.2.3 (those values are pure\ncoincidence).  Users concerned about security issues should disable the\ncompression code (undefine USE_COMPRESSION in cryptini.h) unless it's actually\nrequired.\n\nSupport of autoproxy configuration (under operating systems that implement\nautomatic network proxy discovery) has been added.  This includes support for\nSOCKS-style HTTP proxies as well as the originally implemented HTTP-\napplication-gateway HTTP proxies.\n\nSeveral minor portability issues in 3.2 have been fixed, among other things a\nworkaround for a problem in gcc 4.0 that prevented the code from compiling.\n\nChanges in 3.2 release\n======================\n\nThe version that would have been released as 3.11 has been released as 3.2 to\navoid version-numbering confusion. Future releases will use a three-digit\nnumbering scheme x.y.z, where each of x, y, and z will constitute a single\ndigit, to avoid confusion over whether the '11' in '3.11' is 11 or 0.11.\n\nThe network timeout handling has been split into distinct read and write\ntimeouts to allow more flexible configuration of network data handling,\ntypically very small read timeouts to ensure that cryptlib never blocks while\nwaiting for data, and slightly larger write timeouts to ensure that all data\nis completely written when requested.\n\nClient authentication for sessions that support this (only the secure data\nsessions, SSH and SSL/TLS, use client authentication) has been changed\nslightly.  In previous releases, cryptlib would always allow the client's\nauthentication and complete the handshake, leaving it to the caller to shut\ndown the session later on if there was a problem.  As of this release, server\nsessions will return a CRYPT_ENVELOPE_RESOURCE in the same way that envelopes\ndo when you activate them, to indicate that you need to provide further\ninformation in order to continue.  If you receive this status when you try to\nactivate a server session, you can read the user details via the\nCRYPT_SESSINFO_USERNAME and CRYPT_SESSINFO_PASSWORD attributes, and either\nconfirm the authentication by setting the CRYPT_SESSINFO_AUTHRESPONSE to true\nor deny it by setting it to false.  You then re-activate the session, and\ncryptlib will complete the handshake.  This allows you to check the\nauthentication details before allowing the handshake to continue.  If you'd\nprefer the previous behaviour, just set CRYPT_SESSINFO_AUTHRESPONSE to true\nbefore you activate the session and cryptlib will handle confirmation of\nauthentication itself.\n\nBecause the handshake is now controlled by the server rather than the client\n(that is, cryptlib won't sit in a loop reading all data from the client, but\nwill return to the caller to await further input), it's possible that the\nclient will send further session-control information after the handshake has\ncompleted.  To respond to any additional information that the client may send,\nyour server should try and pop client data before it sends any of its own\ndata.  If the server sends its data first, the client may interpret the\nserver's data as an (invalid) response to a request that it has in progress.\nThe manual contains more details on the new client authentication and server\ndata handling process.\n\nStarting with releases after 3.2, the attribute cursor manipulation functions\nwill be unified so that they work identically for all container objects that\nmaintain lists of attributes (most of this interface is already available in\n3.2 for forwards-compatibility reasons).  This means that the three attribute-\nlist mechanisms CRYPT_CERTINFO_CURRENT_EXTENSION,\nCRYPT_CERTINFO_CURRENT_FIELD, and CRYPT_CERTINFO_CURRENT_COMPONENT (for\ncertificates), CRYPT_ATTRIBUTE_CURRENT_GROUP (formerly\nCRYPT_ENVINFO_CURRENT_COMPONENT) for envelopes, and the future\nCRYPT_ATTRIBUTE_CURRENT_GROUP for session objects will be folded into the\nsingle mechanism CRYPT_ATTRIBUTE_CURRENT_GROUP, CRYPT_ATTRIBUTE_CURRENT, and\nCRYPT_ATTRIBUTE_CURRENT_INSTANCE.  This provides both a unified, consistent\ninterface across the different object types and allows envelope and session\nattributes to be handled in the same way as certificates currently are.  For\nexample under the older cryptlib 3.1 behaviour envelope signatures were\nimplicitly selected by reading the signature attribute, which changed the\ncurrent selection of the signature result and extra signature information\nattributes.  From releases after this one envelope signature attributes are\ngrouped by signature, so selecting the first signature explicitly selects the\nassociated signature key, signature result, and extra signature information\nattributes, selecting the second signature explicitly selects the associated\ninformation for that, and so on.  In addition reading this information under\n3.1 and earlier was something of a hunt-and-peck approach that required\nreading each possible attribute in turn to see whether it was present.  The\nattribute cursor interface allows each present attribute to be enumerated\nusing the attribute cursor, with cryptlib doing the work of sorting out what's\npresent and what isn't.  Finally, cryptlib 3.2 allows more session attributes\nto be accessed by the caller, which requires the use of attribute cursors\nsince many of them are composite values or multi-valued attributes.\n\nAs part of this unification of mechanisms, the CRYPT_ENVINFO_CURRENT_COMPONENT\nattribute has been renamed CRYPT_ATTRIBUTE_CURRENT_GROUP for compatibility\nwith future cryptlib releases.  For certificates, cryptlib 3.11 supports both\nthe legacy CRYPT_CERTINFO_CURRENT_xxx attributes and the new\nCRYPT_ATTRIBUTE_CURRENT_xxx ones, so you can either keep using the\ncertificate-specific cursor attributes for now or move to the universal cursor\nattributes for compatibility with future versions.  All that's necessary to\nupgrade is a search and replace in your code to rename the attributes.  More\ninformation on the unified attribute cursor mechanism is given in the\nIntroduction section of the manual.\n\nThe various situation-specific SSH attributes like\nCRYPT_SESSINFO_SSH_SUBSYSTEM and CRYPT_SESSINFO_SSH_PORTFORWARD have been\nreplaced with more generic forms for compatibility with future cryptlib\nversions, which allow more complete control over SSH channel types and\nparameters.  See the manual for details on creating and controlling SSH\nchannels using the new attributes.\n\nThe SHA-2 algorithm is now enabled by default (previously it had to be\nexplicitly enabled via a compile-time option).  Note that this algorithm isn't\nsupported by most software and standards, so using it in anything other than\nclosed environments will lead to interoperability problems.  If you want to\nuse SHA-2, you should test it against any other software that you need to\ninteroperate with to ensure that it can handle this algorithm.\n\nThe Unix randomness slow poll now has an early-out mechanism that avoids the\nfull heavyweight slow poll if sufficient entropy is available without it.\nThis typically occurs on systems with both built-in randomness sources and\neither a kernel statistics interface or an advanced /proc interface, which\nprovide the same data as the full slow poll at a fraction of the overhead.\n\nChanges in 3.11 beta 1\n======================\n\nAs noted in the 3.1 release notes, releases after 3.1 update the cryptlib 2.x\nlegacy functions cryptImport/ExportKey(Ex), cryptCreate/CheckSignature(Ex),\nand cryptQueryObject to take a length parameter as their second argument.\nThese functions never took a length parameter in their original form because\nthey dealt with encoded signature/key exchange data, for which it's always\npossible to determine the length by parsing it.  However, this makes checking\nof user-supplied parameters difficult - cryptlib always knows how much output\nit'll produce, but it can't be sure that the user wants (or expects) that much\noutput, particularly if they've forgotten to perform a length check before\nexporting a key or creating a signature.  In order to avoid this problem,\nreleases after 3.1 make this minor API change, which fixes the last of the old\ncryptlib 2.x functions.  Since most people use the higher-level API functions,\nthis change shouldn't affect the majority of users.\n\nIn addition to the cryptlib 2.x legacy functions, two standard data-returning\nfunctions cryptExportCert and the rarely-used cryptGetCertExtension now also\ntake a length parameter to specify the maximum buffer size.  This brings them\ninto line with the (updated) legacy functions, and allows cryptlib to perform\nbetter checking of user-supplied parameters, particularly in the case of\nlanguages like Visual Basic and Java where the mapping of language-native data\ntypes to the blocks of memory used by a C-language library can be tricky.\n\nChanges in 3.1 release\n======================\n\nThe final release contains mostly minor tweaks based on user feedback from the\n3.1 final betas, with no noticeable external changes.  Internally, the HTTP\nengine has been significantly improved, TLS 1.1 is now supported (although at\nrelease time there were no other known implementations of this to test\nagainst), the BeOS port has been re-done to handle the current state of the OS\nusing GNU development tools instead of the original Be ones (thanks to Simon\nTaylor for providing access to his system to do the work on), and the\nperpetual tweaking of the networking subsystem to handle OS-specific quirks\nhas continued.\n\nChanges in 3.1 beta 5\n=====================\n\nThis release contains an extensive rewrite of the network-layer code to handle\nvarious quirks and system-specific peculiarities in sockets implementations.\nFor this reason it's strongly recommended that if you're using secure sessions\nor networking, you move to this version as quickly as possible.  In addition\nthe code is now IPv6-enabled as part of the rewrite.  In connection with this,\nit's now possible to specify connect and network timeouts at the per-session\nlevel rather than only as a cryptlib-wide option. To do this, set the timeout\nvalue giving a specific session as the target object rather than CRYPT_UNUSED\nfor all of cryptlib:\n\n  cryptSetAttribute( cryptSession, CRYPT_OPTION_NET_TIMEOUT, timeout );\n\nAll of the session objects now provide extensive text diagnostics of errors\nvia the CRYPT_ATTRIBUTE_INT_ERRORMESSAGE attribute.  This means that if a\nsession encounters a problem in communicating with another system, the\nextended error message will usually provide additional information that goes\nbeyond the standard error code.\n\nSupport for SSHv2 subsystems such as SFTP has been added via the\nCRYPT_SESSINFO_SSH_SUBSYSTEM attribute, and support for SSL/TLS with shared\nkeys (e.g. passwords) has been added.  This allows secure SSL with mutual\nauthentication of both client and server, without the need for either\nexpensive server certificates or the complexity of client certificates.  In\naddition the shared-key mechanism is significantly faster than operations\ninvolving certificates and private keys, and places far less load on both\nclient and server.\n\nThe CRYPT_OPTION_CERT_OBLIVIOUS option introduced in beta 4 has been changed\nfrom a simple boolean value to a multivalued option\nCRYPT_OPTION_CERT_COMPLIANCELEVEL, which indicates the level of checking\napplied to certificates.  This ranges from CRYPT_COMPLIANCELEVEL_OBLIVIOUS\n(almost no checking except for the signature) through to\nCRYPT_COMPLIANCELEVEL_PKIX_FULL (full compliance with PKIX certificate\nstandards).  The default is CRYPT_COMPLIANCELEVEL_STANDARD, which provides a\nreduced level of checking for compliance with other certificate software.\n\nThe CRYPT_ERROR_BUSY status has been renamed to CRYPT_ERROR_TIMEOUT to make it\nmore consistent with conditions like network timeouts, which is where it most\ncommonly occurs.\n\nSome of the database keyset types have been renamed to make the names more\nconsistent.  The three types are now CRYPT_KEYSET_ODBC for databases accessed\nthrough an ODBC interface, CRYPT_KEYSET_DATABASE for databases with the\nbackend-specific interface code compiled into cryptlib, and\nCRYPT_KEYSET_PLUGIN for databases accessed via the cryptlib database plugin\ninterface.  The CRYPT_KEYSET_DATABASE type can be selected in the usual manner\nat compile time with the USE_xxx compile options, see the manual for more\ndetails on databases and compile options.\n\nChanges in 3.1 beta 4\n=====================\n\nThe changes in this release are mostly to fix a variety of minor problems that\ncropped up in beta 3 related to portability across different systems.  One\nnotable change is the inclusion of the CRYPT_OPTION_CERT_OBLIVIOUS\nconfiguration option.  This option is present in order to allow cryptlib to\nhandle the large number of broken certificates in use.  Enabling this option\n(setting it to TRUE) will cause cryptlib to ignore all certificate extensions\nexcept key usage and the CA flag, making it compatible with other PKI\nsoftware.  A future version of cryptlib will replace this option with a\nmultivalue selection allowing a choice of checking ranging from very little\n(in order to be compatible with existing software and to process existing\ncertificates) through to full PKIX compliance (which will, however, reject a\nlarge number of certificates in use today).\n\nChanges in 3.1 beta 3\n=====================\n\nThe way in which GeneralNames and DNs in GeneralNames are selected has\nchanged.  Until now GeneralNames were selected with:\n\n  cryptSetAttribute( cryptCert, attributeID, CRYPT_UNUSED );\n\nwhich selected the GeneralName with the given attributeID and also updated the\nattribute cursor.  Selecting the DN within the GeneralName required a second\nselection to specify the DN.  This special-case behaviour was inconsistent\nwith the way other attributes were handled, and caused some confusion for\nusers, as well as obscuring the fact that the attribute cursor was being\nupdated as it would be for an explicit attribute selection.  Beta 3 changes\nthe selection mechanism so that it matches that used for all other attributes:\n\n  cryptSetAttribute( cryptCert, CRYPT_CERTINFO_CURRENT_EXTENSION,\n                     attributeID );\n\n(or whatever alternative attribute cursor mechanism is preferred).  In\naddition, it's no longer necessary to perform a two-stage select for DNs in\nGeneralNames, since these are now implicitly selected by selecting the\nGeneralName that contains them.  This means that handling of GeneralName\nattributes is now consistent with all other attribute types.\n\nBecause GeneralNames are now automatically selected, you need to be careful\nwhen working with a DN such as the certificate subject name after selecting a\nGeneralName, since a GeneralName contains its own DN which will be the one\nthat's accessed after selecting the GeneralName.  For example if you set an\nemail address (which is part of the GeneralName), this will select the\nGeneralName, and any subsequent DN accesses will refer to the DN inside the\nGeneralName rather than the subject name DN.  It's good practice to move back\nto the subject name with:\n\n  cryptSetAttribute( cryptCert, CRYPT_CERTINFO_SUBJECTNAME,\n                     CRYPT_UNUSED );\n\nafter working with a GeneralName to make sure that you're referring to the\ncorrect DN.\n\nMicrosoft broke the Jet (MS Access) database engine at around SP4 (opinions on\nthe exact time vary).  This version, or newer versions, may be installed\nautomatically when applying service packs or installing other software\n(different broken versions of Jet are installed in Win2K SP2 and SP3, for\nexample, and it's built into Windows XP).  The symptoms are that when running\nthe self-test you'll get an error message \"Cannot open any more tables\" even\nthough no tables are open, or more seriously a deadlock inside the VC++\nruntime file access routines.  The details of this problem are discussed in\nMicrosoft Knowledge Base Article 304536, Microsoft Knowledge Base Article\n282010, and Microsoft Knowledge Base Article 239114.\n\nThe Microsoft-recommended fix is to upgrade to Jet SP6.  This typically\nrequires downloading and installing the SP6 upgrade from the Microsoft\nDownload Centre, simply installing recent MDAC components won't work since\nthere were no Jet components included after MDAC 2.5 SP2, and installing\nOffice XP or Access 2002 may not work either since the setup programs only\nupdate system files in certain situations and to a certain level.  On the\nother hand Jet SP6 may not install unless it detects an appropriate service\npack level on the system.\n\nNon-Microsoft advice is to downgrade to a version of Jet at SP3 or earlier by\nreplacing msjetoledb40.dll and msjet40.dll with files from JET OLE DB SP3,\nsince even the latest version (SP6) still appears to exhibit these problems.\nA better solution is to avoid the use of Jet entirely, and in particular you\nshould *never* use Jet in a production environment since it's far too buggy\nand unstable to trust live data to (it was probably named Jet because it both\nsucks and blows).\n\nChanges in 3.1 beta 2\n=====================\n\nThe last two type names that didn't follow the pattern xxx_TYPE, CRYPT_ALGO\nand CRYPT_MODE, have now been brought into line with the other names, so you\nneed to change the type names to CRYPT_ALGO_TYPE and CRYPT_MODE_TYPE if you're\nusing them in your code.\n\nSSHv2 server support is now present.\n\nPKCS #11 devices can now be auto-detected by specifying the device name as\n\"[Autodetect]\" if the device name isn't known.\n\nPre-connected network sockets can be supplied to sessions as the\nCRYPT_SESSINFO_NETWORKSOCKET attribute, rather than having cryptlib\nconnect/disconnect the socket itself.\n\nThe PKCS #15 format has had various features added to it over time (see the\nnote for 3.0 beta 1), cryptlib has supported these in a read-only manner,\nmeaning that it creates keysets that are as backwards-compatible as possible\nwith old versions of the code that used earlier versions of PKCS #15.  In\norder to make some features like certificate update in a keyset possible, it's\nnecessary to write keyset fields from newer versions of PKCS #15.  All betas\nafter this one will write these newer fields in order to enable advanced\nfeatures of PKCS #15.  Anyone still using very old betas should upgrade to a\ncurrent version in order to take advantage of the advanced features supported\nby newer-format PKCS #15 keysets.\n\nChanges in 3.1 beta 1\n=====================\n\nBeta 1 includes support for PGP and OpenPGP, which is handled in standard\nenvelope fashion with a data format of CRYPT_FORMAT_PGP.  Note that there are\na number of incompatible and semi-compatible variants of PGP in existence,\nwith the major types being PGP 2.x, PGP 5.x, NAI PGP, GPG, and the ckt PGP\nbuilds, and many interesting lesser variations such as the disastry builds\nthat take PGP 2.x and update it to support OpenPGP ciphers without actually\nbeing OpenPGP.  An overview of different PGP versions can be found at\nhttp://rmarq.pair.com/pgp/, and detailed information on incompatibilities can\nbe found at http://www.spywarewarrior.com/uiuc/pgp-summ.htm.  cryptlib has\nbeen tested against most normal versions of PGP, but there will certainly be\nversions out there that produce data that cryptlib can't read (one example\nbeing a version that uses random key IDs in encrypted data in order to obscure\nwho the data is encrypted for, which also makes it impossible to decrypt with\nany normal PGP version).  If you run into something produced by one of these\noddball versions, please send me a copy so that I can determine whether it's\nworth adding custom code to support it.\n\nThe PGP data format imposes a number of restrictions on the standard\nenveloping process, which include:\n\n - Use of nested signed data is discouraged unless you add an intermediate\n   layer of encryption, since PGP doesn't directly handle nested signatures.\n - When signing data, the nested content type can only be the default (data)\n   for the reason given above.\n - It's not possible to mix password and public-key key exchange actions in\n   the same message.  Similarly, it's not possible to have more than one\n   password key exchange action in one message.\n - Handling of separate hashing for detached signatures is somewhat peculiar\n   and requires special care.\n\nChanges in 3.0 release\n======================\n\ncryptlib 3.1 will introduce a new function cryptFlushData() to replace the\ncurrent practice of calling cryptPushData() will all-null parameters, a change\nrequired for languages like Delphi and VB that don't handle C null pointers\ntoo well.  This function is already present in 3.0 for forwards-compatibility\npurposes, it's recommended that you update your code to call cryptFlushData()\nin place of cryptPushData() with null parameters (although the existing\ncryptPushData() mechanism will still work).\n\nThe Unix randomness-gathering code will now check for and use EGD/PRNGD if\nthey're available.\n\nThe requirement that cryptlib be built via a network share under Windows has\nbeen removed.\n\nHTTP keyset access (CRYPT_KEYSET_HTTP) formerly required that the keyset be\nopened without a name being given, with the full URL being specified as the\nkey ID to retrieve keys.  This was both somewhat inconsistent with the other\nkeyset types, and didn't work well with persistent connections, for example\nwhere multiple certificates were being read from a single server.  This has\nbeen changed so that the server URL is given when the keyset is opened as it\nis for other keyset types, and a key ID is given when reading individual keys.\nWhen reading keys with a fixed URL (with no per-key ID), the special ID\n\"[none]\" can be used to indicate that the server URL points directly at the\ncertificate.  In the simplest case the previous usage:\n\n  cryptKeysetOpen( \u0026cryptKeyset, CRYPT_UNUSED, CRYPT_KEYSET_HTTP, NULL,\n                   CRYPT_KEYOPT_READONLY );\n  cryptGetPublicKey( cryptKeyset, \u0026cryptCert, CRYPT_KEYID_NAME,\n                     \"http://www.server.com/cert.der\" );\n\nnow becomes:\n\n  cryptKeysetOpen( \u0026cryptKeyset, CRYPT_UNUSED, CRYPT_KEYSET_HTTP,\n                   \"http://www.server.com/cert.der\", CRYPT_KEYOPT_READONLY );\n  cryptGetPublicKey( cryptKeyset, \u0026cryptCert, CRYPT_KEYID_NAME,\n                     \"[none]\" );\n\nReading multiple certificates, for example via a CGI interface on the server,\nis done with:\n\n  cryptKeysetOpen( \u0026cryptKeyset, CRYPT_UNUSED, CRYPT_KEYSET_HTTP,\n                   \"http://www.server.com/certstore.cgi\",\n                   CRYPT_KEYOPT_READONLY );\n  cryptGetPublicKey( cryptKeyset, \u0026cryptCert, CRYPT_KEYID_NAME,\n                     \"user1\" );\n  cryptGetPublicKey( cryptKeyset, \u0026cryptCert, CRYPT_KEYID_NAME,\n                     \"user2\" );\n  cryptGetPublicKey( cryptKeyset, \u0026cryptCert, CRYPT_KEYID_NAME,\n                     \"user3\" );\n\nChanges in 3.0 final beta\n=========================\n\nThe cryptlib 3.0 final release divides the network timeout parameter into two\nparts, a CRYPT_OPTION_NET_CONNECTTIMEOUT which is applied during the\nconnection setup process and a CRYPT_OPTION_NET_TIMEOUT which is applied\nduring reads and writes (although in practice writes are almost always\ninstantaneous).  This means that it's now possible to avoid nonblocking I/O if\nrequired.\n\nUse of SSL/TLS client certificates is now enabled.\n\nThe final version of the S/MIME PasswordRecipientInfo (PWRI) RFC contained a\nchange in the way the key wrap algorithm is identified.  The cryptlib final\nrelease produces a PWRI that follows the final RFC, but will also read the\nolder format produced by earlier versions of cryptlib.  If it's necessary to\ngenerate PWRI data in the old format, you can change the \"#if 1\" in\nkeymgmt/asn1objs.c to \"#if 0\" to produce the older format.\n\nSupport for extended CMP user configurability via PKIUser objects has been\nadded, this allows user details to be pre-configured at the CA rather than\nrequiring the user to know them.\n\nChanges in 3.0 beta 6\n=====================\n\nBeta 6 reduces the plethora of key generation functions by allowing the\nkeysize to be specified in the more standard way of setting the corresponding\nattribute rather than having extraneous ...Ex() versions of the function that\nparallel the standard form.  If you were previously using the standard or\nasynchronous ...Ex() functions:\n\n\tcryptGenerateKeyEx( cryptContext, keySize );\n\nyou can change to the newer form with a simple cut and paste:\n\n\tcryptSetAttribute( cryptContext, CRYPT_CTXINFO_KEYSIZE, keySize );\n\tcryptGenerateKey( cryptContext );\n\nThe table format for certificate stores has changed slightly to accommodate the\nrequirements of CMP servers (specifically the fact that they can cause things\nto fail at inopportune moments), in order to handle this you need to recreate\nthe cert store (drop the previous table and create a new one with\nCRYPT_KEYOPT_CREATE), if you need to move information across then create a new\ntable and insert into \u003cnewTable\u003e select * from \u003coldTable\u003e to copy the existing\ncertificates across.  The newly-created table will support the storing of\nextra information needed to handle restarts during CMP operations.\n\nSupport for the proposed AES algorithm is now included.  Since this hasn't\nbeen finalised by NIST yet, it is strongly recommended that you not use it\nuntil the AES FIPS has been published.  cryptlib will implement the form\npresented in the final FIPS, which may be incompatible with the current\nversion.\n\nSSL and TLS support (both client and server) is now enabled, thanks to\nendergone Zwiebeltuete for his help in getting this going.\n\nChanges in 3.0 beta 5\n=====================\n\nBeta 5 removes the configuration options CRYPT_OPTION_FIXSTRINGS and\nCRYPT_OPTION_CHECKENCODING since they shouldn't be needed any more as the\nASN.1 code has been modified to handle all but the most broken certificates\nout there.\n\nUnder Unix the library is now called libcl rather than libcrypt to reduce\nproblems with naming conflicts on some systems.\n\nSupport for the creation of one-step certificates that automatically work for\nany purpose has been added and is enabled by setting the certificate's\nCRYPT_CERTINFO_XYZZY attribute, more details are given in the manual.\n\nOCSP, TSP, and SSH server support is now enabled (this complements the OCSP,\nTSP, and SSH client support added in beta 3 and beta 4).\n\nChanges in 3.0 beta 4\n=====================\n\nBeta 4 removes the need to use the TCP4U library for the network interface and\nshould now have networking enabled automatically on Unix and Windows systems.\nWith the enhanced networking support comes support for SSH secure sessions and\nCMP (Certificate Mismanagement Protocol).\n\nThe creation of arbitrary-format DN's containing any sort of component in any\norder or combination is now supported via the CRYPT_CERTINFO_DN attribute.\n\nChanges in 3.0 beta 3\n=====================\n\nBeta 3 required one unfortunate change to the object creation functions which\ninvolves the addition of a parameter that specifies the user who is to own the\nobject.  For cryptlib 3.0 this means that as the second parameter for the\nobject creation functions (cryptCreateContext, cryptKeysetOpen,\ncryptCreateEnvelope, etc etc) you should specify CRYPT_UNUSED for forwards\ncompatibility with cryptlib 3.1 and later releases.  The user parameter has\nexisted since the first 3.0 releases but until now has been hidden beneath the\ncryptlib API, unfortunately it's necessary to un-hide this parameter, which is\nrequired by certain 3.1 features such as the CA management functionality.\n\nThe use of multiple certificates with the same DN/email address but different\nkey usage types is now supported (previous versions treated the appearance of\nmultiple certificates issued to the same person as a duplicate cert problem,\neither interpretation is valid but popular opinion seems to be that the beta 3\nbehaviour is better).  In order to support this in public key keysets you need\nto recreate them (drop the previous table and create a new one with\nCRYPT_KEYOPT_CREATE), if you need to move certificates across then create a\nnew table and insert into \u003cnewTable\u003e select * from \u003coldTable\u003e to copy the\nexisting certificates across.  The newly-created table will support the\nstoring of multiple identical certificates.\n\nIn order to take advantage of this capability with encrypted enveloping, you\nneed to add the recipient's public key with the CRYPT_ENVINFO_RECIPIENT option\nthat will allow cryptlib to automatically select the most appropriate\ncertificate.  The selection of an appropriate signature checking certificate\nis handled automatically.\n\nHandling of detached signatures with externally-supplied hash values is now\nsupported, see the manual for details.  This allows signature checking for\narbitrary data without it having to be hashed via the envelope.\n\nCertificate revocation checking via OCSP is now supported if you can manage to\nfind an OCSP responder anywhere.  Timestamping of signatures is also\nsupported, although you'll have even less chance of locating a TSA than an\nOCSP responder.\n\nSupport for mSQL has been dropped since MySQL is now GPL'd and provides far\nmore functionality than mSQL (even cryptlib 2.x was pushing the limits of\nmSQL, with cryptlib 3.x it's not really sufficient any more).\n\nChanges in 3.0 beta 2\n=====================\n\nBeta 2 has three minor API changes over beta 1 that are intended to clarify\nareas that have caused problems for users in the past.\n\nThe first change is that the third, usually unnecessary, parameter for\ncryptCreateContext() has been eliminated:\n\n  cryptCreateContext( \u0026cryptContext, cryptAlgo );\n\nOnly the conventional-encryption algorithms required the encryption mode\nparameter, the default is CBC but if another value is required you can specify\nit using the CRYPT_CTXINFO_MODE attribute:\n\n  cryptSetAttribute( cryptContext, CRYPT_CTXINFO_MODE, cryptMode );\n\nThis attribute isn't required for anything except conventional encryption\nalgorithms, and even then it's only required for the use of encryption modes\nother than the default mode of CBC.  This change simplifies the creation of\ncontexts, since there's no longer any need to juggle CRYPT_USE_DEFAULT,\nCRYPT_MODE_PKC, CRYPT_MODE_NONE, or any of the other special cases that were\nused for algorithms that don't have different encryption modes.\n\nThe second change (which probably won't affect most users since it's rather\nobscure) is that previously when loading raw public keys with the\nCRYPT_PKCINFO_RSA or CRYPT_PKCINFO_DLP structure the attribute used was\nCRYPT_CTXINFO_KEY and the length was given as CRYPT_UNUSED.  This required a\nnumber of special-case checks in the code and made error-checking of user-\nsupplied data impossible because it wasn't possible to determine how much data\nwas being passed in.\n\nIn beta 2 this attribute now follows the pattern for every other attribute in\nthat it's necessary to give the structure size (i.e. sizeof(\nCRYPT_PKCINFO_xxx)) as the length parameter rather than CRYPT_UNUSED.  In\naddition the attribute for key components is now CRYPT_CTXINFO_KEY_COMPONENTS\nto make explicit the fact that what's being loaded is a composite structure\ncontaining multiple components and not just a single byte string as with\nCRYPT_CTXINFO_KEY.\n\nSimilarly, the length parameter when using cryptEncrypt()/cryptDecrypt() for\npublic-key encryption is now the key/data length in bytes rather than\nCRYPT_UNUSED, following the standard pattern of requiring an actual length\nrather than using magic values.\n\nThe third change is that the functionality of cryptCreateEnvelopeEx() has been\nfolded into cryptCreateEnvelope(), which now takes a second parameter\nspecifying the type of envelope to create\n\n  cryptCreateEnvelope( \u0026cryptEnvelope, formatType );\n\nThe envelope buffer size can optionally be specified with the\nCRYPT_ATTRIBUTE_BUFFERSIZE attribute once the envelope has been created:\n\n  cryptSetAttribute( cryptEnvelope, CRYPT_ATTRIBUTE_BUFFERSIZE, size );\n\nalthough this should only be necessary in special cases when enveloping\nlarger-than-usual data quantities.  This change both simplifies the interface\nand makes it easier for cryptlib to efficiently handle resources, since it can\nallocate a small envelope buffer when enveloping begins rather than having to\ncreate a one-size-fits-all one on envelope creation.\n\nIn addition to these changes, beta 2 includes the ability to read the label\nfor the private key which is required for de-enveloping data, so you can use\nthe key name in prompts when asking the user for a password.  You can do this\nwith:\n\n  char label[ CRYPT_MAX_TEXTSIZE + 1 ];\n  int labelLength;\n\n  cryptGetAttributeString( cryptEnvelope, CRYPT_ENVINFO_PRIVATEKEY_LABEL,\n                           label, \u0026labelLength );\n  label[ labelLength ] = '\\0';\n\nSee the manual for more information on this.\n\nChanges in 3.0 beta 1\n=====================\n\ncryptlib 3.0 features a large number of improvements over 2.1, the most\nvisible one being that there is now a unified object model that applies to all\ncryptlib objects, so that the old object-type-specific functions like\ncryptGetCertComponentString() and cryptSetEnvelopeComponentNumeric() have been\nreplaced by cryptSetAttribute(), which works across all object types.  This\nmeans that cryptlib 3.0 has a much simpler interface than 2.1 did (even with\nall the features added in 3.0, the manual is 25 pages shorter than the 2.1\nmanual).\n\nBackwards compatibility with 2.1 is maintained through the use of the 2.1\ninclude file capi.h, which contains macros that map the 3.0 functions and\nattributes back to 2.1 versions.  Three of the more obscure functions don't\ntranslate cleanly, these are documented at the start of capi.h.  If you've got\nexisting 2.1 code then it should work with 3.0 with a recompile.\n\nThis is a beta release of the code, some sections are still subject to change\nbecause the standards they are based on haven't been finalised yet. The most\nobvious one is the PKCS #15 keyset format, when the cryptlib code was frozen\nthe PKCS #15 file format existed only in an informal manner so that some of\nthe data formatting used by cryptlib is speculative and will probably change\nwhen the standard stabilises.  What this means in practice is that you\nshouldn't store any long-term keys in file keysets since the format will have\nto change in the future to track changes in the standard.\n\nTo a lesser extent, the compressed-data and password-protected-data formats\nare based on S/MIME drafts that may also be changed at some point.\n\nFinally, the AS/400, MVS, and VM/CMS versions have somewhat specialised\nrequirements (some of this is covered in the manual), please contact me before\ntrying to do anything with these versions.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fcryptlib%2Fcryptlib","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fcryptlib%2Fcryptlib","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fcryptlib%2Fcryptlib/lists"}