Re: [tor-talk] [liberationtech] Programming language for anonymity network

[michi1@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx]

Hi!

On 10:26 Fri 18 Apr     , Stevens Le Blond wrote:
> 
> Hello,
> 
> We are a team of researchers working on the design and implementation of
> a traffic-analysis resistant anonymity network and we would like to
> request your opinion regarding the choice of a programming language /
> environment. Here are the criteria:

It is interesting to see a team of researchers asking this question in
public. Developers usually have their own preferences about this already.

> ...
> 3) Language security: The language should minimize the risk of security
> relevant bugs like buffer overflows.

If you think about language security you may want to think about these things
too:

- Any garbage collection will introduce pauses to your program. The length of
these pauses will increase if the memory usage increases. This can easily
become a problem if your program requires either a lot of memory or real time
response. Traffic analysis resistance sounds like it requires both lots of
buffering and real time response (extra latency could effect traffic
patterns).

- Languages with a high layer of abstraction make lots of things easier. But
often these are things you should be careful with. For example string
operations: If you use them for data exchange, you can easily mess up when
escaping them (e.g. sql injection). Also, they are larger and slower to
manipulate than binary data.

- How the code gets is written makes a huge difference. Is your team paranoid
enough (in your case you need a *lot* of paranoia)? Do they care enough? Does
everybody know what they are doing? Does your organisation put security or
business first?

> 4) Security of runtime / tool chain: It should be hard to
> inconspicuously backdoor the tool chain and, if applicable, runtime
> environments.
> ...
> Java does better with respect to 3), however, it trades some of 3) and
> 4) as compared to C. Specifically, we are concerned that large runtimes
> may be difficult to audit. A similar argument may apply to other
> interpreted languages.

I do not think that the C toolchain is easy to audit either. I would just
focus on something which is open source and in wide use. In this case,
somebody who has a backdoor in the runtime or toolchain probably has a
backdoor to the system either way.

	-Michi
-- 
programing a layer 3+4 network protocol for mesh networks
see http://michaelblizek.twilightparadox.com
-- 
tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk