I'd like to second this; both the admiration for the very high quality of Crypto++, and the suggestion to branch 4.2 to allow minor user-contributed maintenance.
I understand and somewhat share the concern over compiler warnings. But given the diversity of compilers I'd put _much_ greater faith in the rich test & validation suite and the experience of the user community, which AFAIK has been overwhelmingly positive. (My experience certainly has been; zero problems here.) While 5.x has many great features (re-keying etc), the interface changes will unfortunately prevent me from using it for some time, simply because we'll have to change a lot of code, even though it's only in minor ways, and often improvements (e.g. eliminate our hacks to 4.2 for resetting IVs etc). Regards, Chris -----Original Message----- From: Shawn Masters [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 05, 2003 11:02 AM To: [EMAIL PROTECTED] Subject: RE: Regarding warnings 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]
