I've been using crypto++ now since version 3.X, and really haven't
had the concerns that you are expressing here. It has consistently stood up
to insult and injury from a host of directions and I don't seem to recall
ever seeing an issue that would have led to a security concern.
Now the 5 release was a major departure from an interface
perspective, and my colleagues and myself have not become comfortable with
it yet, but it is still based on the 4.X series in most key areas. I can
tell you that I have been inside and out of the 4.2 release that I find it
very easy to audit the portions of the code that I need to use. Also, I
have quite a bit of faith in it. I think you would be hard pressed to find
better quality code in another crypto library.
You raise an interesting point about the much higher level of
abstraction that Wei is trying for in 5.X and beyond. I do find it taking
longer to develop in 5.X for some tasks, and not any shorter for others.
The generic interfaces, while extremely powerful and well thought out, seem
to be too normalized in directions that are different then I would have
gone. Doesn't mean that they won't work, just that I wasn't thinking of
using it that way. Much of this comes from me being a 4.2 curmudgeon, but
it makes me wonder if 4.2 is just better suited for some development
projects.
I guess my question is, would it make sense to branch the 4.2
release in a maintained release for some time to come? Wei can continue to
expand and enhance 5.X and on, but we could make 4.2 an uber stable and
audited code base for those still using it. Then we could address concerns
like you have below without impeding future progress and a lively
development for a research grade toolkit.
Of course given the track record, Wei is going to tell me I'm just
not using 5.X correctly, point out the error of my ways and things will
continue as normal :-).
73,
Shawn
> -----Original Message-----
> From: Guy Smith [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, November 05, 2003 9:40 AM
> To: [EMAIL PROTECTED]
> Subject: Regarding warnings
>
> Because of the recent discussion about warnings in CryptoPP I decided to
> post my thoughts on the subject. For several months I have felt uneasy
> using CryptoPP for several reasons, one of which is the number of warnings
> that appear. Although the warnings have been innocuous (unreferenced
> formal
> parameters, mostly) the strict programmer in me always feels that any
> warnings at all are indicative of sloppy programming or (worse) sloppy
> design. They can also indicate incomplete software; I often have code in
> intermediate stages of development where I purposely insert code that will
> cause warnings so as to remind me that the software is unfinished
> (unreferenced formal parameters are useful indicators of function stubs,
> for
> example). However, these warnings should obviously be eliminated before
> code is released.
>
> Because CryptoPP is used for sensitive purposes I am increasingly
> convinced
> that the strict, conservative interpretation of warnings is vital.
> Cryptography is one of the few things we know how to do right (who am I
> quoting here?), so it doesn't make sense to accept software that isn't
> perfect. Additionally, from a confidence standpoint it doesn't help to
> have
> such crucial code spewing warnings to the developer; I am relying on this
> code to be secure. I cannot use code that is sloppy or unfinished.
>
> This brings me to my second concern about the library, which is its'
> extremely large size and opaqueness. While I normally appreciate
> comprehensive libraries, in the case of cryptography I have different
> concerns. My concern is to have a handful of primitive functions that I
> can
> access directly, which I can audit for reliability, and which are cleanly
> modularized. These requirements mean that what I want is a library that
> is
> NOT implemented using generic programming techniques. I am a big fan of
> generic programming in other endeavors (I use it every day) but one of
> its'
> big drawbacks is that it makes code harder to read. I simply don't have
> time to audit CryptoPP, and as a result I am VERY leary of using it. It
> is
> simply too complex for me to understand without devoting an unacceptably
> large amount of time to studying it (even two weeks would be too much).
> In
> fact, the number of warnings that appear when CryptoPP compiles indicates
> to
> me that even the people who are developing the library do not fully
> understand it.
>
> As a result of these concerns, I have been considering abandoning CryptoPP
> and either assembling a small, piecemeal library of just the primitives I
> need, or implementing my own library of primitives. The projects I am
> working on right now have extremely high security requirements, and I
> simply
> can't afford to have these kinds of doubts.
>
> I have raised these concerns because I appreciate the effort that has been
> put into CryptoPP, and I don't want to see that effort wasted because
> people
> lack faith in the code. As a real-world user of the library I currently
> feel that it is a bad choice; I will continue using it in the short term,
> but right now my plan is to migrate to something simpler and clearer
> within
> six months.
>
> Sincerely,
> Guy L. Smith
> Lead Developer
> [EMAIL PROTECTED]
