On Mon, 3 Nov 1997, Mix wrote:
Adam Back wrote:
Monty Cantsin writes:
The PGP source code is not the worst I've ever seen, but it's kind of odd.
I had a go at doing something with it (I'll let you know when I get it to work) -- I had the damnest job figuring out what was going on. The problem I found with understanding it were all of the nested functions called through vectors of functions and handler functions. Makes it hard to inspect what will happen without running the code under a debugger -- lots control flow is decided at run time.
So in other words, even though we have the source code we don't really have confidence that we can tell what it is doing.
There were only a few obscure points. Most of it can be determined from hex dumps of the files produced. I had public key management before I saw the source code. Since I have a version that does not use any PGP source, but PGP 5.x interoperates fully, I think I can tell precisely what it is doing.
Even though the source code is available, I don't think it has been studied all that carefully. For example, hardly anybody knew that the PGP 5.0 source had CAK features lurking in it. Or, remember that bug with the random number generator? As I recall (i.e., feel free to correct me), it was in Colin Plumb's code and he found it himself. This would imply that it got by whoever went over the code when it was released. Not reassuring.
There is that section for CAK in a future expansion note in Vol. 1 of the source. There is probably a note in the CP archives I posted eons ago, long before the 5.5 controversy spawned all the traffic about CAK. It was near the new passphrase hash which was one thing I could not figure out without the source.
C is a big part of the problem. Also, PGP was originally designed to operate on some fairly slow machines and they tried very hard to optimize the hell out of it. Now, however, cycles are a lot cheaper. I think we should give up speed for clarity. Slow code that we can really trust is better.
C is not part of the problem, people who aren't good at abstraction are. It would look even more horrid in modula-2(3?). If you have something go through three layers instead of one, it will be more complicated, for instance I did something more like: *hashstart[]() = {md5start,sha1start,ripemd160start}; instead of the layering. --- reply to tzeruch - at - ceddec - dot - com ---