1. 14
  1. 3

    Like with Freenet and Java, I’d be worried as a non-Erlang programmer about implementing Tor in that language. The reason is covert channels in storage or timing. Mitigating them requires tight control over memory or how long things take when observed. The GC-using languages screw up the memory part. The standard libraries can, too. The timing part might get really muddied with a concurrency-oriented language or anything with a JIT.

    On top of minimalism in a safe language, I always recommend a non-managed, deterministic language for implementing high-assurance software for these reasons. Tor is definitely in the category that needs high-assurance. Covert channels get more important in such software, esp network-visible.

    1. 3

      That’s one of the reason the crypto is called via FFI to C AFAIU. I think he even mentions that in passing. Others such as the SSL layer of mirage OS follow the same reasoning. And shimming around the critical C parts poses not much of a risk IMHO.

      1. 1

        The first part of that risk is the crypto operations themselves. Then, the protocol operations might tell you things. So, they traditionally got done the same way.