Being safe on the internet (was Re: Here we go again - ISP DPI, but is it interception?)
igb at batten.eu.org
Sat Aug 7 10:47:26 BST 2010
So, if I'm three weeks from starting a PhD in which the production of
a large slab of secure code (let us gloss over whether that's formally
secure or pragmatically secure), what toolchain should I use? I'm
guessing my favoured "first to reach for" tools at my advanced age of
C and Perl aren't cool, C++ horrifies me aesthetically, Java is dull.
I think it's time for a Lisp revival.
On 7 Aug 2010, at 07:07, Peter Tomlinson wrote:
> Tom Thomson wrote:
>> Roland Perry wrote:
>>> It seems to be worse than that... why are these products so
>>> to vulnerabilities? For example, one that used to occur over and
>>> again was "buffer overflow". Surely there must be programming (or
>>> management) techniques that could eliminate them entirely?
>> There are indeed appropriate techniques, but these techniques
>> involve either or both of using hardware which supports memory
>> management (as implemented by old-fashioned mainframe providers and
>> some old-fashioned mini-computer providers) and programming in
>> languages whose operational semantics requires bound checking and
>> separation of code and data. Systems using the technologies
>> developed in the late 1960s and the 1970s by companies such as
>> Burroughs, ICL, and even CTL could not have suffered from most of
>> the vulnerabilities that we see today.
> The memory stirs, taking me back to 1968 when I designed the very
> simple memory management hardware for the ICL 1904A (and in the
> process fixed an error in the 1906A's MMU). Took the software people
> another 2 years to get George 4 running. So that was old-fashioned,
> was it, Tom? It was state of the art then, in the commercial
> environment that soon after took a wrong turn...
More information about the ukcrypto