[Cryptography] how reliably do audits spot backdoors?

[Jerry Leichter]

On Dec 28, 2013, at 5:04 AM, James A. Donald wrote:
>> I do it all in Java.  Once, when I did a port from Java to various
>> languages, it took 5 times longer to get it into C as opposed to various
>> OO languages (PHP, Perl).
> 
> Transating to C, you have to add your own memory management code, which is a large part of any C program, hence the much longer C translation times.
> 
> Modern C++ has some tools that substantially automate memory management and  type management, but you still have to think about memory management, while Java does it all for you.
It really depends on what you're doing.  Java only *appears* to do it all for you; while you can't get the traditional memory leak (memory to which no accessible pointers exist), you can easily build up piles of guck that's pointed to by hash table entries you forgot to clean up, for example.  And the GC doesn't help you with non-memory resources.  This is where destructors, if used carefully, can really pay off in C++:  You can guarantee (well, almost; there are some holes, but generally if you fall into them it's because you insisted on using some low-level features that are almost never needed and should be left to those who fully understand the implications) the complete cradle-to-grave semantics of types you define.  You can't do that in Java - you're left telling users they *must* call close() before they stop using function, which they forget to do - unless they remember to use a try/finally, which has an annoying scope definition requiring yet more restructuring of the code.  The new "try-with-resources" syntax *finally* improved the story here - it's new to Java 7 - but it still has its limitations.)

I've moved back and forth between Java and C++ over the last couple of years, and I find myself cursing whichever one I'm currently using and looking back fondly at the one I'm not.  :-(  (Though in fact I find much less of the "looking back fondly" at Java.)

> PHP notoriously tends to turn into spaghetti code,
PHP notoriously has *incomprehensible* semantics, and sometimes it seems that every other line of PHP code is a security hole.

> people keep copying and pasting the code, resulting in lots of lots of code pages that are similar but not identical.
This is a pattern I've seen in Java as well.  With one Java project I worked on, it seemed as if the (long-departed) developers understood the notion of abstraction by introducing a class, but were completely unfamiliar with the notion of abstraction by introducing a function.  So you had pages and pages of more-or-less identical bits of code, copied rather than made into a helper function.  Fixing a bug meant changing the same damn bit of code over and over again.  And then there were the 30 identical-looking functions - except that one of them did something just slightly different.  Man, can that leave you spinning your wheels trying to figure out what's going on.

> Translating Java into Perl is doubtless easy, but translating from Perl to Java ...  Perl is a write only language.
I maintained on rather large Perl program for a while.  I found Perl to be a bearable language if I simply ignored many of its "features".  I treated it as C with a nice set of string processing primitives, pretty much.  I'm sure a Perl expert would have been horrified by my code - but it worked, and over the years, as I and one other guy with a similar bent cleaned it up and reorganized it, it actually became reasonably understandable and maintainable.

Still, every time I finished doing some work on that code, I felt as if I should go wash my hands carefully.  :-)

> C++ has the wonderfully powerful template system.  Unfortunately, the template system is apt to produce gigantic error messages whose sheer size makes them difficult for anyone to comprehend.
The thing that's remarkable is that people didn't expect this.  It's been true of every macro processing language since the first ones were developed.

> But you can do things with templating that you cannot do in any other language except lisp.
Lisp macros are fundamentally different in kind.  They are, in general, more powerful; but there are certain kinds of things they just can't do.  (In particular, C++ templates have access to a pretty powerful static type system, whereas Lisp has no static type system for them to have access to.  So the areas of overlap between the kinds of things Lisp macros are used for and the kinds of things C++ templates are used for is fairly small.  Since Lisp has essentially no syntax, its macros mainly focus on providing one.  C++ has enough syntax to fill anyone's needs, so templates are more about semantics.  An approximation of the reality, but not that far off as a general statement.)

                                                        -- Jerry