Re: Pros and Cons of Crypto++

From: Ian S. Nelson (nelsonis_at_comcast.net)
Date: 12/11/03 

Date: Wed, 10 Dec 2003 17:05:15 -0700
To: Richard Jagodzinski <Richard_Jagodzinski@shaw.ca>

Richard Jagodzinski wrote:
> Hi, all
>
> I'd like to ask readers of the newsgroup their opinion of Wei Dai's
> Crypto++ library. I've used it previously but have reservations about
> the complexity of it's object oriented hierarchy.
>
> What I would like to know is:
>
> 1. Has any formal evaluation (aside from the FIPS 140-2 level 1
> validation given to version 5.0.4 binaries) has been done on the
> validity of the cryptographic functions? If not, does anyone have any
> direct experience of incorrect or questionable aspects of this library?

To my knowledge there hasn't been a formal correctness review. From my
own experience, once I waded through the classes and got it working, it
has always matched the output from other libraries on different
platforms, including OpenSSL and the BouncyCastle stuff on java. I've
only used the hashes and symmetric ciphers though. There are some test
vectors included for some of the ciphers and hashes and the code seems
to produce correct results. I haven't tried all of the ciphers though.

> 2. Would anyone know of any validation of the library from the point of
> view of security in the sense of software vulnerabilities?
>
> Any advice in this would be greatly appreciated, thank you.

This has been something I've wondered about, I assume you're talking
about the standard stack and buffer type attacks. Firstly, I don't want
to be overly critical, I like the library and use it, it seems to be
popular for attacks in some circles because of the complexity or lack of
documentation. The documentation is light but once you get it working
it does what you'd expect. That being said, with the amazing abundance
of C buffer overflows I'm a skeptic about libraries that are this
complex, there simply has to be security problems in them. It seems
like you should be able to isolate the cryptographic functions though,
unless you can create input that doesn't encode properly you should be
able to validate the input to the library and prevent the typical stack
and buffer issues. The other classes of problems would be how the
library deals with data, it's possible that a pass phrase could be
stored in memory that is swapped to disk or exposed in a core dump, I'm
fairly certain that Crypto++ doesn't do anything to try and prevent
those problems. I guess there are some other areas of concern where by
there might be a way to coerce Crypto++ to produce not so random
pseudo-random numbers or something, that code is a product of an input
seed though. If the input is good the output should be good, in theory.

FWIW, OpenSSL is written by people that are "focused on security" and
I'm not aware of any formal documentation on how they are solving those
problems (they are an off shoot of the OpenBSD project which also
doesn't have any auditing documentation that I know of) should a group
come up with some auditing documentation I wouldn't be surprised if
someone started going through Crypto++. OpenSSL has had some big holes
and I think it's safe to assume that the less popular libraries probably
do too. Maybe I haven't looked hard enough though. I don't know of any
free/opensource cryptographic libraries that have had a security review
like that with published documentation on what it was they reviewed
exactly and what they looked for.

Ian Nelson

Relevant Pages

  • Re: syscall interface into kernel
    ... I was hoping for documentation such as might be used by someone developing ... tracking the progress of kernel development over time, ... up a layer of complexity in the library itself, ... libraries are a continuing work in progress, ...
    (comp.os.linux.development.system)
  • Re: Standard Library Interest? (The Big Player ACT)
    ... No hypertext can help here. ... that documentation sitting on someone else's shelf didn't help me one ... There's nothing wrong with a "Fundamentals of the Conventional Ada ... > (It appears that container libraries such as Charles or Booch's ...
    (comp.lang.ada)
  • Re: Standard Library Interest? (The Big Player ACT)
    ... > documentation even come with the distribution? ... > hyperlink to the code after installation - or, more importantly, does ... the ARG in terms of documentation of whatever they included in an Ada ... you came across two libraries that do the same thing, ...
    (comp.lang.ada)
  • Re: JavaDocs vs. Tests (was: Interview)
    ... documentation for what the method actually does. ... Say we've got a function formatName which takes a Person object and gives you a string like "J. ... For libraries, it certainly makes sense, but for applications.. ... What's a bit weird is that in its released form, it *doesn't* have tests - the tests for it are actually tests for a demo app written on top of the library. ...
    (comp.lang.java.programmer)
  • Re: cpu overheating
    ... That's why you have graphics libraries on a headless server. ... Some of these things are required to conform to some standard or other expectation of functionality, but by and large, they're components without which things just won't *work*. ... A bare installation is still somewhere in the neighborhood of six or seven hundred megs (of which, around two hundred is manual pages, documentation, and string translations, vastly out sizing the "optional" dependencies), which is hardly unreasonable. ... Perhaps I mightn't even want to install the documentation. ...
    (Fedora)
Quantcast