6 ms·

I hope LibreSSL gets the traction it needs in the coming months or years. There are great wins using it and it is worth to move over the FOSS stack to use Libre

I hope LibreSSL gets the traction it needs in the coming months or years. There are great wins using it and it is worth to move over the FOSS stack to use LibreSSL instead of OpenSSL and reduce the number security bugs we are facing today.

pjmlp 10y ago
Regardless how much love it gets, it will never be safe. https://groups.google.com/forum/m/#!msg/boring-crypto/48qa1kWignU/o8GGp2K1DAAJ https://groups.google.com/forum/m/#!msg/boring-crypto/48qa1k...
- qwertyuiop924 10y ago
  Yes, that's a valid argument, but if you think everybody will switch to Oberon any time soon, prepare to be disappointed. In any case, LSSL can be a heck of a lot safer than OSSL, and, in fact, already is.
  - pjmlp 10y ago
    Oberon ship has sailed long time ago. I still like it, but that is just a nostalgia thing. It was a great experience in the mid-90's, but a modern language in 2016 requires much more that what it offered, hence why I eventually got disappointed with Go's feature set. I would rather see Ada, SPARK, Swift, Rust, ATS, Idris, F*, Formal Methods or whatever else that ensures that our code runs on top of solid foundations.
    - qwertyuiop924 10y ago
      I'm not sure I entirely agree, but fair 'nuff. In any case, my point still stands: People aren't going to rewrite all that C code. The best we can hope for is for some UB to actually be standardized, so that the sociopaths who write the compilers are reigned in a bit.
      - pjmlp 10y ago
        I very much doubt it, as it goes against the C culture of micro-optimize each code line as it is written, without any feedback from a profiler because "the coder knows best!". Since I know C (1992), I have seen quite a few times people write code to go fast as they can and apply compiler optimization tricks for use cases where it hardly matters. Also many of the issues regarding UB go back to the early ANSI C days, when it was the wild west of C dialects outside UNIX and no vendor wanted to give up on their own extensions. As for C and C++ compiler writers view on UB: https://www.youtube.com/watch?v=yG1OZ69H_-o https://www.youtube.com/watch?v=yG1OZ69H_-o
        qwertyuiop924 10y ago
        I know perfectly well what their views are. I did describe them as sociopaths, remember? UB, to some degree, might be resonable. C-style nasal-demon UB, with propogating conditions so that you can't check for integer overflows reasonably is possible to live with, but insane. C's culture of hyper-optimization is ridiculous. Unfortunately, while Rust may well eat C++'s lunch, there's very little that is competitve with C at the same level of abstraction, so for some work (kernel development, perhaps, embedded systems, definately) it will remain significant for some time, if not outright dominant.
  - whyever 10y ago
    What about switching to Rust? https://github.com/ctz/rustls https://github.com/ctz/rustls
    - qwertyuiop924 10y ago
      Impressive, but I'm willing to bet nobody will want to rewrite all of open/libreSSL, one of the most popular cryptographic libraries out there, in Rust.
      - steveklabnik 10y ago
        https://crates.io/crates/ring https://crates.io/crates/ring , which is BoringSSL, being ported over. Eventually it'll be Rust and asm. (And is what rustls uses)
        qwertyuiop924 10y ago
        Well then, maybe. Consider me corrected.
    - pjmlp 10y ago
      Nice, thanks for point it out.
- agumonkey 10y ago
  I wish all the people djb alike could gather in a room and give gifts to the world.
- byuu 10y ago
  I've been hoping for a C/C++ compiler with no/limited undefined behavior for years. Sadly, the people writing compilers have lost touch with the people using them, so this is very unlikely to happen. But I have to say, if one is going to do this, then C isn't a good target. Especially for crypto, C lacks extremely useful semantics such as rotate-left, rotate-right, add-with-carry, subtract-with-borrow, etc. Things that would greatly accelerate libraries that work with 512-bit multiplies like DJB's Curve25519. And then there's useful math operators like power-of that could be added. You could also put requirements in there like "warn/error on variable-length divide" to catch surprise gotchas like x86 CPUs taking an indeterminate length of time to divide. In fact, constant-time execution could be a compile-time check. The key would be to keep it "as much C" as possible. Rust and co are going to face barriers by being so incredibly different from C.
  - thristian 10y ago
    The biggest problem Rust has with crypto is that the canonical compiler is built on LLVM, so no matter what a human writes, it'll get ground up by the optimizer and may turn into something quite different. Rust has an advantage in that it doesn't have the undefined-behaviour gotchas of modern C/C++, so LLVM won't optimize away all your sanity checks, but that's not a strong enough guarantee for crypto work—as you point out, you need strong control over assembly instructions to maintain constant-time execution.
    - dbaupp 10y ago
      That problem is true of practically any language, even C and C++, and the solution is the same (and well accepted) for all of them: write a small set of controlled primitives in raw assembly, and let the "high level" language compose them. Obviously using assembly forgoes safety for those pieces of code, but being primitives they've typically fairly small, and have straight-forward memory access patterns/behaviour.

pjmlp 10y ago

Regardless how much love it gets, it will never be safe. https://groups.google.com/forum/m/#!msg/boring-crypto/48qa1kWignU/o8GGp2K1DAAJ https://groups.google.com/forum/m/#!msg/boring-crypto/48qa1k...

qwertyuiop924 10y ago
Yes, that's a valid argument, but if you think everybody will switch to Oberon any time soon, prepare to be disappointed. In any case, LSSL can be a heck of a lot safer than OSSL, and, in fact, already is.
- pjmlp 10y ago
  Oberon ship has sailed long time ago. I still like it, but that is just a nostalgia thing. It was a great experience in the mid-90's, but a modern language in 2016 requires much more that what it offered, hence why I eventually got disappointed with Go's feature set. I would rather see Ada, SPARK, Swift, Rust, ATS, Idris, F*, Formal Methods or whatever else that ensures that our code runs on top of solid foundations.
  - qwertyuiop924 10y ago
    I'm not sure I entirely agree, but fair 'nuff. In any case, my point still stands: People aren't going to rewrite all that C code. The best we can hope for is for some UB to actually be standardized, so that the sociopaths who write the compilers are reigned in a bit.
    - pjmlp 10y ago
      I very much doubt it, as it goes against the C culture of micro-optimize each code line as it is written, without any feedback from a profiler because "the coder knows best!". Since I know C (1992), I have seen quite a few times people write code to go fast as they can and apply compiler optimization tricks for use cases where it hardly matters. Also many of the issues regarding UB go back to the early ANSI C days, when it was the wild west of C dialects outside UNIX and no vendor wanted to give up on their own extensions. As for C and C++ compiler writers view on UB: https://www.youtube.com/watch?v=yG1OZ69H_-o https://www.youtube.com/watch?v=yG1OZ69H_-o
      - qwertyuiop924 10y ago
        I know perfectly well what their views are. I did describe them as sociopaths, remember? UB, to some degree, might be resonable. C-style nasal-demon UB, with propogating conditions so that you can't check for integer overflows reasonably is possible to live with, but insane. C's culture of hyper-optimization is ridiculous. Unfortunately, while Rust may well eat C++'s lunch, there's very little that is competitve with C at the same level of abstraction, so for some work (kernel development, perhaps, embedded systems, definately) it will remain significant for some time, if not outright dominant.
- whyever 10y ago
  What about switching to Rust? https://github.com/ctz/rustls https://github.com/ctz/rustls
  - qwertyuiop924 10y ago
    Impressive, but I'm willing to bet nobody will want to rewrite all of open/libreSSL, one of the most popular cryptographic libraries out there, in Rust.
    - steveklabnik 10y ago
      https://crates.io/crates/ring https://crates.io/crates/ring , which is BoringSSL, being ported over. Eventually it'll be Rust and asm. (And is what rustls uses)
      - qwertyuiop924 10y ago
        Well then, maybe. Consider me corrected.
  - pjmlp 10y ago
    Nice, thanks for point it out.
agumonkey 10y ago
I wish all the people djb alike could gather in a room and give gifts to the world.
byuu 10y ago
I've been hoping for a C/C++ compiler with no/limited undefined behavior for years. Sadly, the people writing compilers have lost touch with the people using them, so this is very unlikely to happen. But I have to say, if one is going to do this, then C isn't a good target. Especially for crypto, C lacks extremely useful semantics such as rotate-left, rotate-right, add-with-carry, subtract-with-borrow, etc. Things that would greatly accelerate libraries that work with 512-bit multiplies like DJB's Curve25519. And then there's useful math operators like power-of that could be added. You could also put requirements in there like "warn/error on variable-length divide" to catch surprise gotchas like x86 CPUs taking an indeterminate length of time to divide. In fact, constant-time execution could be a compile-time check. The key would be to keep it "as much C" as possible. Rust and co are going to face barriers by being so incredibly different from C.
- thristian 10y ago
  The biggest problem Rust has with crypto is that the canonical compiler is built on LLVM, so no matter what a human writes, it'll get ground up by the optimizer and may turn into something quite different. Rust has an advantage in that it doesn't have the undefined-behaviour gotchas of modern C/C++, so LLVM won't optimize away all your sanity checks, but that's not a strong enough guarantee for crypto work—as you point out, you need strong control over assembly instructions to maintain constant-time execution.
  - dbaupp 10y ago
    That problem is true of practically any language, even C and C++, and the solution is the same (and well accepted) for all of them: write a small set of controlled primitives in raw assembly, and let the "high level" language compose them. Obviously using assembly forgoes safety for those pieces of code, but being primitives they've typically fairly small, and have straight-forward memory access patterns/behaviour.