I assume the author does not want to rewrite OpenVPN from the scratch. Because "Multithreading", "networking" and "cryptography" immediately raises the head bells when it comes to C. People write this in Rust nowadays, isn't it? ;-)
My first multi-core machine was an Athlon64 X2 with two cores running at 2GHz. Today, my work laptop (ThinkPad L540) has a dual-core CPU (plus 2-way SMT) running at 2.6 GHz (3.2 GHz with TurboBost). But single-core performance has improved notably. Not as much as was common in the 1990s, but still. And for most desktop systems more than two or four cores seem to be pointless, anyway, since they will sit idle most of the time.
 I am not talking about developer workstations, CAD machines or other high-end use cases, but the kind of machine where some office drone runs Outlook, Excel, and a web browser.
Now, I know just enough about cryptography to know I know nearly nothing about it, so maybe someone can put this into context: Wouldn't a multi threaded crypto implementation open up a whole bunch of new potential attacks?
The attacker now has a lot more possible outcomes depending on the number of threads handling that packet. I seems, on the surface, as if more threads add complexity to the attacker.
Debugging multithreaded code is much harder than single threaded, especially because of all the race conditions that can happen: it makes our brains burn hot from all the possible outcomes from identical runs run one after the other. My intuition would lead me to believe that this complexity is also now added to the attacker's side - but perhaps I'm missing something.
Timing attacks are somewhat annoying and noisy to conduct over the Internet, but you can measure the time a process takes with a resolution down to ~15ns. I bet there is all sorts of cross core cache errata that leaks more time than that.
Looking at it, I can imagine redoing it as LuaJIT and using ljsyscall to deal with the system calls on all platforms. Might be even more snappy.
is luajit supported on versions beyond 5.1 ? just wondering...
all i can get from your response is a 'yes' to my earlier affirmation
that luajit is compatible with Lua 5.1 honestly, responding to gp's
comment, i also found lua's embedding in this application quite
imho, for something which might be living for a long time, considering
using lua-jit might not be a good idea.
That doesn't mean we should drop everything, throw away our C code and rewrite ot in Rust, but the issue is real.
You make it sound like this is somehow particular to C.
I hold the opinion that when you're using such an open definition of "sound and safe" (e.g. code will never do anything that could reasonably called a "bug" from a user's perspective) it is impossible to write "safe and sound" code in any programming language.
But that is not really a problem with the language, but with the definition of the term "sound and safe".
If you use a more constrained definition of "sound and safe"; one that would actually allow you to write "correct" code in a language, then C code can just be as sound and safe as rust code or Coq. It really just depends on your definitions.
In a way I agree with what I believe the grandparent tried to say; one thing that consistently rubs me about the Rust community is that they oftem seem to be using a very constrained definition of "safe" when advertising that rust is a "safe language", but a very open definition of safe when proclaiming that more or less every other systems language is "unsafe". That may be true using their definition of safe, but is a bit of dirty PR trick.
well, to me at least, it seems a bit premature to compare the two languages at this juncture. rust is quite nascent, and doesn't have enough data points (imho) to make an objective comparison.
perhaps, when we have large code-bases available in rust doing safety+security critical applications (which might then be worthy targets) it might make more sense.
Click the little play button under the respective headings:
Danish: "fri uttal på danska [da]"
Swedish: "fri uttal på svenska [sv]"
Norwegian Bokmål: "fri uttal på bokmål [no]"
Anyway I don't know, it is definitely not the English r however.
But instead of painting positions and stuffing things in mouths, one can also exchange information about this by just using text. That's what I did in my comment. So, no joke whatsoever. Just a specific question about how to pronounce a specific sound exactly.
Also these days I switched to IPsec. I just get way better performance than with OpenVPN (I am talking about 600 Mbit/s vs 350Mbit/s). But it is quite a beast and you need to have some basic cryptographic knowledge for IPsec.
EDIT: Seems like my first question is only relevant if we are talking about powerful CPUs on both sides. If multicore on client <= single core on server, then this client makes sense.
This is probably the reason its not included by default in a lot of OSs whereas macOS, iOS, and I think Windows all have built in support for IPSEC. Yeah you can download an app, but there is no really good (free or paid) app for mac and the official iOS client sucks.
Multi threaded means payload that has already been through a crypto operation wouldn't need to block further crypto ops or wait for other crypto ops to be processed further (just one obvious example of a performance advantage). Also - plenty of people don't even use AES,even for those that do AES-NI offloads the actual AES operation,not things like CBC,GCM and CTR.