[Botan-announce] Botan 1.4.2
Brought to you by:
randombit
|
From: Jack L. <ll...@ra...> - 2004-11-01 18:38:12
|
Botan 1.4.2 was released yesterday, forgot to send an announcement. A major flaw in the CRL handling code is fixed. If your application is making use of X.509 CRLs, I strongly suggest an upgrade -- 1.4.[01] and some versions of 1.2.x have a bug which causes them to silently fail to process CRL data, meaning revoked certificates will not be rejected. Obviously, if you don't use CRLs, this bug doesn't affect you. Also a number of portability problems have been fixed, including issues on Solaris, OpenBSD, and others. There are some issues remaining on System V-derived Unices; it seems GNU's install and SysV's install are don't support the same flags, and I didn't have time to work out a solution before the release. Finally, the Engine modules can now provide implementations for ciphers, hashes, and MACs in addition to public key operations. This will be useful for engines for devices like VIA's Padlock or the Hifn chips that provide DES/AES/SHA-1 as well as PK ops. The OpenSSL engine has been extended to provide some ciphers and hashes (RC4, DES, 3DES, AES, MD5, SHA-1, etc), though there are limitations due to OpenSSL's interface. For example, even if the OpenSSL engine is loaded, only ciphers "AES-128", "AES-192", and "AES-256" will be provided by OpenSSL; if you use plain "AES" it uses Botan's implementation. This is because in OpenSSL, the three AES key lengths are distinct EVP algorithms, and changing the EVP cipher in use on the fly is somewhat hard to code for. The new interface also allows Engines to provide full modes (ie, 3DES/CBC/PKCS7), but the OpenSSL engine doesn't suport this; I implemented it, and the code was sufficiently complicated and cumbersome that it wasn't worth it, considering that the gains are minimal compared to using Botan's filter objects with the OpenSSL provided primitives. However, it will be useful for pure hardware devices, as the overhead for a PCI message would make sending a single block at a time to a hardware chip prohibitive. Regards, Jack |