Speaking positvely for Java, only (and looking at others with interest). I recommend scratching these from your list: C (too slow), C++ (good try but too much legacy), Perl (too Unixy), PHP (as bad as Perl, and too webby). I don't know Ruby, Python, C# nor any of the newer contenders: Go, Clojure, Rust, etc.
On 18/04/2014 09:26 am, 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: > > 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. Java is probably the most taught language these days in University so it tends to be the one with most familiarity. Other languages are taught but every uni has its different lists and every student travels a different path. Java is as easy to learn as most of the standard OO languages. It's probably not as nice to program in as some of the more modern ones, I hear that C# is a better language, "Java done right," but it has no home outside MS. I think in terms of productivity there isn't likely much in it between any of the straight OO languages. Java tends to be the favourite base language in the finance world, so it tends to attract higher salaries, which is a good and a bad. In terms of the Open Source world this is a bad. > 2) Maturity: The language implementation, tool chain and libraries > should be mature enough to support a production system. Definitely mature, yes, especially for server operations. Where it is less well supported is for desktop operations. It is of course the Android language, but phones are split between Android and iPhone so you have a harsh choice there. > 3) Language security: The language should minimize the risk of security > relevant bugs like buffer overflows. Yes. Where the insecurity comes into play is niggles. Recent debates include being able to clean a password from a String (not really possible apparently). Also, having to use Native to access libraries like OpenSSL, or to access special OS features like IPC. Java believed that everything should be possible inside it, which was just sophistry and marketing. But compared to C and the like, Java is far safer. C/C++ is the sort of language where you have to have experts coding; Java is the sort of language where you can more comfortably relax and work with a wider group of people. > 4) Security of runtime / tool chain: It should be hard to > inconspicuously backdoor the tool chain and, if applicable, runtime > environments. Java does offer a library signing ability, but by far the most important aspect here is that it is your choice whether you pull in lots of libraries, in which case you're at their mercy. Or whether you constrain things tightly. I do not see any difference between Java here and the others I've worked with extensively (C, Perl, PHP). One big thing with Java is that crypto is generally thought to be pushed through a thing called the JCA/JCE. This is an abomination, which includes amongst other things a backdoor you could slip a tanker through. It is however completely possible to bypass it entirely and write your own systems. I do this, but it's not trivial work, you probably need a cryptoplumber on team. There is at least one library that is actively supported called BouncyCastle that has a non-JCE core library available, so to some extent, if you know your way around crypto, then you can cut&paste their stuff and get it up and going without losing much. > 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). Right. But historically where are the problems? Buffer overflows are the leading one. In the Java world, there are lots of bugs too, but look a bit more closely and you're find they are -- the vast majority -- in the applet space. OK, so don't do that. Actual bugs with the language are far and few between, actual security bugs with Java applications, also relatively rare. > 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. See the recent discussion on Apple/static/dynamic/openssl. For me, it all comes down to: how much are you prepared to write yourself? For example, my old Perl server used to use OpenPGP for signing of receipts. The Perl package hooked into some other CPAN thing to do the big number things. Which itself hooked into some C thing. Which did not work. After 2 weeks of trying to get this CPAN nightmare to do its basics, I gave up and rewrote the entire thing in Java, and also replaced all the OpenPGP signing with custom code. Took 2 months :( Lost. But it's also an investment, I'll never be at risk of some external crypto blah blah failing again. It's nothing really to do with which particular language, it's all to do with how much reliance you put on which other packages outside your control, and how much resource you've got when that reliance falls apart. > Given these criteria, what language would you choose and for what > reasons? We would also appreciate feedback regarding our criteria. I have practically chosen Java. However, it has only worked out by accident. In the earlier days we had expected it to dominate the desktop (so the marketing said) and not the server. So we chose Perl for the server. It turned out in reverse so we ended up having to rewrite. But the desktop domination failed, and Java looked like a dead duck there ... C++ ruled the waves. Until Android! And now we have a new lease of life! We're end to end, and we have the world's most important platform in native. So, circumstances outside control play a big part. Also, pick your market carefully. Your users will have a lot to say by what things they do. iang _______________________________________________ p2p-hackers mailing list [email protected] http://lists.zooko.com/mailman/listinfo/p2p-hackers
