The original implementation used Crypto++ 4.2. It was easy to develop and integrate and worked well. It didn't, however, compile on AMD64, which was a show stopped.
The conversion from 4.2 to 5.2.1 was extremely painful. Unique among libraries I have used in 30 years of software development, version 5 was significantly incompatible with code developed for version 4, RSA keys generated with version 4 were in compatible with version 5, there was no documentation for the transition, the modularization was radically different, and there was virtually no documentation on version 5.
The conversion was, frankly, brutal, requiring reverse engineering on the version 5 code, maintaining parallel version 4 and 5 systems to trace the logic. When I finished the conversion, I found that the size of my product rpm had jumped from 3.5MB to almost 14MB without any change in functionality.
I have concluded, with regret, that I have to abandon Crypto++ in favor of more suitable libraries. Before I go, however, I would like to offer some unsolicited advice. I offer these in good faith. For calibration, I've been programming since my second year in high school in 1965 in assembly language on an IBM 7040. I've worked on a ARPAnet database machine when the net had 40 nodes. I've written a family of 4GLs (Datatrieve) and a relational database management system (Rdb/ELN) at DEC, started a company and wrote a commercial RDMS (Interbase) that morphed into an open source project (Firebird) 20 years later. I also have an application platform containing an RDMS, and Java virtual machine, a search engine, etc.
First, for any software system, upwards compatibility with new versions is paramount. Nobody likes to throw out working code, but worse, there is an implicit assumption that if one API is orphaned, the next API is also at risk, so if a major conversion is required, conversion to a more stable system is warranted.
Second, modularization is important. Nobody want to inherit 120K bytes of code to get a simple DES module that could be written in 10K. The Crypto++ version 5 RawDES class requires seckey.h which requires cryptlib.cpp which brings in virtually the entire library.
Third, the template-intensive structure is impenetrable. Give that there is no documentation or even examples, the only way to attack the library is to reverse engineer it. When most classes are structured as templates of multiple templates, the effort required is extreme; certainly more than can be expected of a tire-kicker.
If I were going to re-organize Crypto++, I would use an object rather than template model. In specific:
1. I would define an abstract class for each class of algorithm
2. I would encapsulate each algorithm in a single class implementing
its respective abstract class
3. I would define abstract classes for filters and sinks
4. I would layer filters and sinks on their abstract classes
5. I would layer modes on top of filters.The key is to make each class an encapsulation, interacting with other abstract classes. When all is said and done, the existing template interface and be reimplemented on an OO base. I would offer both the existing template interface for compatibility, but emphasize the OO abstract class model as the primary interface.
--
Jim Starkey Netfrastructure, Inc. 978 526-1376
