7 ms·

This is a very interesting project as all our today's processors, even the Raspberryian ones, are multicores. I assume the author does not want to rewrite Open

by ktpsns 9y ago

This is a very interesting project as all our today's processors, even the Raspberryian ones, are multicores. 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? ;-)

williamaadams 9y ago
I think it's more interesting than that. This is a mixture of C and Lua code! 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.
- signa11 9y ago
  > ... redoing it as LuaJIT... is luajit supported on versions beyond 5.1 ? just wondering...
  - hwh 9y ago
    This is a strangely worded question. LuaJIT is compatible with PUC Lua 5.1. It will thus not run (without problems/tweaking) run code that is designed for Lua >= 5.2. However, the differences are not really big in practice. It is rather more likely that the new options (especially the FFI) that come with LuaJIT will lead to the most work when switching over. Not that they would be absolutely needed, but it just makes it all so much smoother and faster - which is probably the reason to switch to LuaJIT in the first place.
    - signa11 9y ago
      what a strangely worded response :) 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 interesting. imho, for something which might be living for a long time, considering using lua-jit might not be a good idea.
- mueslix 9y ago
  All the heavier processing is done in C already. Lua is only used for handling dis-/reconnects, rekeying and the likes. Hence I don't think LuaJIT would improve the performance much in this particular case.
extrapickles 9y ago
I’m not sure I would want to do crypto multithreaded in any language. Too easy to leak information via timing even with a single core.
- magnetic 9y ago
  Can you clarify what you mean? You seem to imply that using multiple threads is not a good idea, but then also express that not using multiple threads is also not a good idea. What's left?
  - austinshea 9y ago
    He's saying that it exacerbates an already complicated issue.
  - cm2187 9y ago
    I think encrypting independant packets on each thread is fine, what I believe he is refering to is encrypting a single packet on multiple threads. One of the many angles of attack against cryptography is side channel attacks, where for certain algorithms the path taken by the code depends on the value of the key/data. In which case you can leak some information by measuring the time it takes or power usage. Modern algorithms are carefully designed to not be path sensitive, which is hard enough when the algo executes on a single thread, but becomes really complex to manage on multiple threads. Just more opportunities to shoot oneself in the foot.
    - ktpsns 9y ago
      That's a fair argument, however we also want to exploit computational ressources. It's nothing new that clock speed stagnates but everything points to manycore architectures. Parallel crypto maybe hard but it is somewhat inevitable to research, investigate and implement.
      - krylon 9y ago
        Clock speed does not necessarily equal computational speed. I remember how ~15 years ago people predicted that single-core performance was not going to improve any longer, and that we would get more and more CPU cores over time. 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[1] more than two or four cores seem to be pointless, anyway, since they will sit idle most of the time. [1] 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.
inamberclad 9y ago
The rust people seem to shy away from rolling their own crypto.
- acct1771 9y ago
  Beside the non-zero amount of effort required, nobody wants to be the one responsible for bad crypto. Can't say I blame them.
dna_polymerase 9y ago
My goodness, you Rustlings. There are lots of people out there perfectly able to write safe and sound C code even handling crypto, networking and multithreading.
- lima 9y ago
  It's well established that writing safe and sound C code is an impossible feat (even OpenSSH had a number of memory corruption bugs in the past). Some people are better at it than others, yes. That doesn't mean we should drop everything, throw away our C code and rewrite ot in Rust, but the issue is real.
  - signa11 9y ago
    > ... throw away our C code and rewrite ot (sic) in Rust... 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.
  - hellohn123 9y ago
    > It's well established that writing safe and sound C code is an impossible feat 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.
0x0 9y ago
It's like the three major areas of programming where "things may appear to work but are in fact dangerously broken in hidden ways" converged. Compared to other software where the worst case is often crashing or not working, unproven crypto code bases might in fact appear to work (as in, traffic does appear to tunnel correctly), while in fact it could be broadcasting your private keys and plaintext data to anyone who comes knocking.

by ktpsns 9y ago

williamaadams 9y ago

I think it's more interesting than that. This is a mixture of C and Lua code! 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.

signa11 9y ago
> ... redoing it as LuaJIT... is luajit supported on versions beyond 5.1 ? just wondering...
- hwh 9y ago
  This is a strangely worded question. LuaJIT is compatible with PUC Lua 5.1. It will thus not run (without problems/tweaking) run code that is designed for Lua >= 5.2. However, the differences are not really big in practice. It is rather more likely that the new options (especially the FFI) that come with LuaJIT will lead to the most work when switching over. Not that they would be absolutely needed, but it just makes it all so much smoother and faster - which is probably the reason to switch to LuaJIT in the first place.
  - signa11 9y ago
    what a strangely worded response :) 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 interesting. imho, for something which might be living for a long time, considering using lua-jit might not be a good idea.
mueslix 9y ago
All the heavier processing is done in C already. Lua is only used for handling dis-/reconnects, rekeying and the likes. Hence I don't think LuaJIT would improve the performance much in this particular case.

extrapickles 9y ago

I’m not sure I would want to do crypto multithreaded in any language. Too easy to leak information via timing even with a single core.

magnetic 9y ago
Can you clarify what you mean? You seem to imply that using multiple threads is not a good idea, but then also express that not using multiple threads is also not a good idea. What's left?
- austinshea 9y ago
  He's saying that it exacerbates an already complicated issue.
- cm2187 9y ago
  I think encrypting independant packets on each thread is fine, what I believe he is refering to is encrypting a single packet on multiple threads. One of the many angles of attack against cryptography is side channel attacks, where for certain algorithms the path taken by the code depends on the value of the key/data. In which case you can leak some information by measuring the time it takes or power usage. Modern algorithms are carefully designed to not be path sensitive, which is hard enough when the algo executes on a single thread, but becomes really complex to manage on multiple threads. Just more opportunities to shoot oneself in the foot.
  - ktpsns 9y ago
    That's a fair argument, however we also want to exploit computational ressources. It's nothing new that clock speed stagnates but everything points to manycore architectures. Parallel crypto maybe hard but it is somewhat inevitable to research, investigate and implement.
    - krylon 9y ago
      Clock speed does not necessarily equal computational speed. I remember how ~15 years ago people predicted that single-core performance was not going to improve any longer, and that we would get more and more CPU cores over time. 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[1] more than two or four cores seem to be pointless, anyway, since they will sit idle most of the time. [1] 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.

inamberclad 9y ago

The rust people seem to shy away from rolling their own crypto.

acct1771 9y ago
Beside the non-zero amount of effort required, nobody wants to be the one responsible for bad crypto. Can't say I blame them.

dna_polymerase 9y ago

My goodness, you Rustlings. There are lots of people out there perfectly able to write safe and sound C code even handling crypto, networking and multithreading.

lima 9y ago
It's well established that writing safe and sound C code is an impossible feat (even OpenSSH had a number of memory corruption bugs in the past). Some people are better at it than others, yes. That doesn't mean we should drop everything, throw away our C code and rewrite ot in Rust, but the issue is real.
- signa11 9y ago
  > ... throw away our C code and rewrite ot (sic) in Rust... 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.
- hellohn123 9y ago
  > It's well established that writing safe and sound C code is an impossible feat 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.

0x0 9y ago

It's like the three major areas of programming where "things may appear to work but are in fact dangerously broken in hidden ways" converged. Compared to other software where the worst case is often crashing or not working, unproven crypto code bases might in fact appear to work (as in, traffic does appear to tunnel correctly), while in fact it could be broadcasting your private keys and plaintext data to anyone who comes knocking.