[botan-devel] Bug report in cvc_self.cpp (Re: Security Notification: Botan 1.10.8 + 1.11.9 released)

Uri Blumenthal uri at MIT.EDU
Fri Apr 11 16:06:27 EDT 2014

Update. Reporting a bug in cvc_self.cpp that exhibits itself when running the tests.

Botan-1.11.9 built with clang-3.4 with:
configure.py --with-boost --with-sqlite3 --with-zlib --with-bzip2 --with-lzma --with-gnump --with-openssl --with-boost-python --with-python-version=2.7 --prefix=/opt/local --enable-modules=cvc --cc=clang --disable-altivec

Last lines of output of “./botan-test” (I’ve inserted a few debugging prints in test_cvc()):

ECC all ok
ECDSA 11 tests all ok
ECDH 3 tests all ok
PK keygen 34 tests all ok
Entered test_cvc()
test_enc_gen_selfsigned(rng): about to call create_self_signed_cert()
Exception escaped test: Decoding error:  decoding failed
NIST X.509 path validation 71 tests all ok
TLS 4 tests all ok
Tests 1 FAILs

On Apr 11, 2014, at 0:59 , Uri Blumenthal <uri at MIT.EDU> wrote:
> Update.
> Botan-1.10.8 built with gcc-4.8.2: ./check runs fine, no errors.
> Botan-1.11.9 built with gcc-4.8.2 - “./botan-test” on my system immediately crashes with Signal 11. GDB says it’s in system::err::what(). Probably because all the libraries (including boost) are build with clang, and C++ is insanely sensitive to what compiler the library was built with.
> On Apr 11, 2014, at 0:35 , Uri Blumenthal <uri at MIT.EDU> wrote:
>> Both packages built with clang-3.4 on Mac OS X v10.9.2.
>> Botan-1.10.8 built with 
>> python configure.py --with-boost --with-zlib --with-bzip2 --with-gnump --with-openssl --with-boost-python --with-python-version=2.6 --prefix=/opt/local --enable-modules=cvc,cms --cc=clang --enable-sse2 --enable-ssse3 --enable-aes-ni --with-tr1=boost
>> "./check —test” fails. See the attached check-1.10.8.out.
>> Botan-1.11.9 built with
>> python configure.py --with-boost --with-sqlite3 --with-zlib --with-bzip2 --with-lzma --with-gnump --with-openssl --with-boost-python --with-python-version=2.6 --prefix=/opt/local --enable-modules=cvc --cc=clang --enable-sse2 --enable-ssse3 --enable-aes-ni 
>> ./botan cpuid
>> CPUID flags: sse2 ssse3 sse41 sse42 avx2 rdtsc bmi2 clmul aes_ni rdrand
>> “./botan-test" fails. See the attached botan-1.11.9.out.
>> It would be nice if these problems could be explained and a fix suggested.
>> Thanks!
>> <botan-test-1.11.9.out>
>> <check-1.10.8.out>
>> On Apr 10, 2014, at 20:10 , Jack Lloyd <lloyd at randombit.net> wrote:
>>> I've released new versions of Botan (1.10.8 and 1.11.9) fixing a serious bug in
>>> prime testing. A change in version 1.8.3 resulted in Miller-Rabin primality
>>> tests being done with a single random base rather than a sequence of such
>>> bases. Miller-Rabin is a probabilistic algorithm where the rate of failure
>>> (classifying a non-prime as prime) decreases as iterations increase, so having
>>> a single test is more or less the worst case scenario.
>>> What are the actual effects of this bug? There are two major cases: generating
>>> a new RSA key (or DSA or DH parameters), and testing an untrusted DH group
>>> provided by a third party (for instance during TLS DHE key exchange, where the
>>> server hands the client an arbitrary DH group). RSA generation should be safe;
>>> a proof (in http://www.math.dartmouth.edu/~carlp/PDF/paper88.pdf) shows that
>>> for *randomly* chosen n the probability of a false accept is quite low and and
>>> decreases rapidly as the size of the number increases, for instance with
>>> randomly chosen 600 bit numbers even a single test should fail no more often
>>> than 2^-75. In addition newly generated RSA keys are automatically checked for
>>> consistency (including checking the primes, meaning a second Miller-Rabin
>>> test), so in the event that a key was created with a non-prime factor, the self
>>> test would with high probability fail and the constructor would throw an
>>> exception.
>>> The case of DH parameter verification is rather bleaker, as obviously the value
>>> is chosen by the attacker, so about the best we can hope for is the base 3-in-4
>>> detection rate of Miller-Rabin: that is, 75% of the time we would detect this
>>> invalid prime, and 25% of the time we would not, and accept a composite as
>>> prime.
>>> I would like to thank Jeff Marrison for finding and reporting this issue.
>>> The only other change in 1.10.8 is a modification for HMAC, which now accepts
>>> keys as large as 512 bytes. This is primarily so PBKDF2 can accept very long
>>> passphrases.
>>> 1.11.9 has some changes to PKIX path validation; when validating we return a
>>> set of all the errors with the most severe error being provided as the primary
>>> result. This prevents a seemingly innocuous error (such as an expired
>>> certificate) from hiding an obviously serious error (such as an invalid
>>> signature). A bug that prevented OCSP from working with some common responders
>>> was also fixed. And implementations of HMAC_DRBG and the RFC 6979 deterministic
>>> nonce generator were added.
>>> As always download links are at http://botan.randombit.net/download.html
>>> My apologies on the mess. From the events of this week it appears I'm at least
>>> in good company.
>>> Jack
>>> _______________________________________________
>>> botan-devel mailing list
>>> botan-devel at randombit.net
>>> http://lists.randombit.net/mailman/listinfo/botan-devel
>> _______________________________________________
>> botan-devel mailing list
>> botan-devel at randombit.net
>> http://lists.randombit.net/mailman/listinfo/botan-devel
> _______________________________________________
> botan-devel mailing list
> botan-devel at randombit.net
> http://lists.randombit.net/mailman/listinfo/botan-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.randombit.net/pipermail/botan-devel/attachments/20140411/66c42fde/attachment-0001.html>

More information about the botan-devel mailing list