Botan 1.7.19 has been released with several new features for random number generation, as well as significant optimizations for the Turing stream cipher.
This release adds a new class, AutoSeeded_RNG, which takes care of all necessary seeding operations as well as deallocating resources properly upon exit. AutoSeeded_RNG by default uses a new PRNG class HMAC_RNG, which is based on the design by Hugo Krawczyk described in his paper On Extract-then-Expand Key Derivation Functions and an HMAC-based KDF. This design is probably more secure than the previous Randpool class (which is still available in 1.7.19), and seems to be much faster than Randpool on x86-64. It uses two HMAC instances, one as a randomized extractor, which is fed all RNG input (entropy polling data), and is used to generate keys for a PRF (based on a second HMAC instance). By default HMAC/SHA-256 is used as the PRF, and HMAC/SHA-512 is used as the extractor (this is a combination specifically recommended by Krawczyk in the paper).
I am not aware of any specific security vulnerabilities in Botan's Randpool design. However, unlike Randpool, HMAC_RNG's design is based on a relatively firm theoretical foundation, which seems quite attractive. Within the cryptographic community there is much quibbling about if, for instance, the random oracle model is that useful a tool, and more generally if models can tell us anything. My take on this is that the value of the model is in inverse correlation with how many assumptions it makes. Early uses of the random oracle model 'proved' the security of OAEP, with the assumption that a cryptographic hash function like SHA-1 will act as a random oracle or random function. However this is patently untrue, since nearly all hash functions are based on the Merkle-Damgard construction, which provides for several generic attacks that do not depend on breaking the cryptographic hash function at all (for instance the well known length extension attacks, and Joux's multicollision attack). In contrast, the HMAC KDF relies on much less 'brittle' assumptions, in particular about HMAC's ability to act as a pseudorandom function, for which relatively sound proofs exist.
In other changes, the implementation of the stream cipher Turing has been significantly optimized, and is as much as 30% faster, depending on the compiler and processor - it can process up to 430 MiB per second on a 2.4 GHz Intel Core2 Q6600, though only 300 MiB per second with GCC 4.3 (which is still 60 MiB/s faster than it had been). This was done primarily by removing one layer of indirection in the core indexing code, which allows most compilers to generate significantly better code.
Posted 2008/11/06 in releases; no comments
< New Benchmarks for Botan 1.7.18 | Botan In Feature Freeze for 1.8.0 >