[Cryptography] Paranoia for a Monday Morning

Henry Baker hbaker1 at pipeline.com
Tue Oct 28 18:17:08 EDT 2014


At 01:58 PM 10/28/2014, Bill Frantz wrote:
>One of the strengths of Firefox is the large body of code that is in Javascript, a secure language.

Huh?!?  Just because Javascript has garbage-collection and array-bounds checking doesn't make it a 'secure' language.

As a long-time user of Lisp, I agree that GC & bounds-checking can improve security, but these features are only a start.  Compile-time type checking can help some more, but _removing_ features can help a lot more -- e.g., removing 'eval'.

[As an aside, the earliest Lisp Machines on the ethernet at MIT had an 'eval' server; no Bash shellshock needed!  On the other hand, some of the safest email & web servers were written in Lisp (w/o eval!), and some servers ran continuously for more than a year until electrical power failure forced a reboot.]

Perhaps the place where higher level languages help security the most is that they allow the programmer to not worry about so many low-level details, so that (s)he can allocate more effort towards making the whole program correct.  Of course, this depends critically upon having a well-tested implementation that gets the library functions correct.  For example, a mathematician utilizing the Macsyma symbolic algebra system found a bug in the Lisp Machine's bignum integer division routine several years after the Lisp Machines were placed into service.  [That sort of bug couldn't happen anymore in the 21st century, could it?]

The next place where errors creep in is during *optimization* -- usually for speed (gcc, anyone?).  Assumptions are made about the range of inputs, and generality is squeezed out of the code in order to gain performance.  Then some user provides an unexpected input, and we're off to the races.

To optimize without breaking something requires a language that is capable of precision targeting of semantics-preserving transformations.  For example, a particular loop can be unrolled by simply tagging it; a function call can be 'inlined' by simply tagging it; an expensive 'functional' function call can be memoized by simply tagging it, etc.  These tags don't affect the semantics -- i.e., the value computed -- but only the nature & amount of resources consumed in the computation.

Yes, I know that compiler people want all of this stuff to be automatic, but making optimizations like this automatic requires profiling data, which opens up a huge attack surface & side-channels.



More information about the cryptography mailing list