[tor-talk] Programming language for anonymity network

[Aymeric Vitte]

Without any hesitation: js + nodejs (note: I am not part of the node's team)

- the code is very reduced and transparent, difficult to backdoor 
including nodejs itself
- js is familiar but not trivial as many people think
- works on any platform, can even be browserified (see links below) --> 
note: that's not part of your criteria
- libraries are huge and great
- performances are great, especially with streams2 --> note: that's not 
part of your criteria
- security is ok, it can be affected by outside modules (like openssl), 
maybe the buffer model (which is not allocating memory upon creation for 
performances reasons) can be problematic but you can override native objects
- nodejs is easy to audit (assuming that modules like V8 can be 
audited), you can override node's functions/objects if you like
- your app is easy to audit, no compilation steps
- very easy to install, for contributions and use
- community is huge, nodejs is stable enough for production, the only 
small defect from my standpoint is that the upgrade process is sometimes 
not totally square for now.

Do you have links to your project?

Regards

Aymeric

-- 
Peersm : http://www.peersm.com
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms


Le 18/04/2014 10:26, Stevens Le Blond a écrit :
> 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:
>
> 1) Familiarity: The language should be familiar or easy to learn for
> most potential contributors, as we hope to build a diverse community
> that builds on and contributes to the code.
>
> 2) Maturity: The language implementation, tool chain and libraries
> should be mature enough to support a production system.
>
> 3) Language security: The language should minimize the risk of security
> relevant bugs like buffer overflows.
>
> 4) Security of runtime / tool chain: It should be hard to
> inconspicuously backdoor the tool chain and, if applicable, runtime
> environments.
>
> To give two concrete examples:
>
> Using the C language + deterministic builds is an attractive option with
> respect to 1), 2) and 4), but doesn't provide much regarding 3).
>
> 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.
>
> Given these criteria, what language would you choose and for what
> reasons? We would also appreciate feedback regarding our criteria.
>
> All the best,
> David, Nick, Peter, Stevens, and William
>
>
>