6 ms·

Nice and everything, but I somehow cannot imagine people massively jump over it. Maybe it's superstitious, I dunno… On the other hand, I undoubtedly agree that

by krick 13y ago

Nice and everything, but I somehow cannot imagine people massively jump over it. Maybe it's superstitious, I dunno… On the other hand, I undoubtedly agree that we should start making and deploying alternatives in more safe modern languages. In fact, I guess we should start step-by-step rewriting everything that's written in C/C++ and OpenSSL is a good thing to start with. I guess it's a good chance for Rust & friends.

gizmo686 13y ago
Crypto poses a unique challenge with the threat of timing attacks. A major benitif of using low level languages is that it is easier to assure that your code takes constant time regardless of the input.
- betterunix 13y ago
  With the downside being that things like Heartbleed become possible. Dealing with timing attacks in high-level code is not necessarily hard -- Haskell, for example, has strict evaluation.
- pmahoney 13y ago
  So what candidates are there? While C may make it possible to write code that avoids timing attacks, a quick glance at [1] shows one must avoid memcmp and array lookups based on secret data, neither of which would be prevented by the compiler, and both probably similarly easy mistakes as heartbleed. Can Rust compile to a shared lib the programs can use as easily as a C library? (I think the answer is "not yet", but I'm not sure? At least, I've seen projects for compiling Rust without any runtime library). Today I learned this is possible with Ada [2], but it seems there is some boilerplate to start/stop the runtime. Does Ada provide the necessary low-level control to implement crypto? Are there sufficiently strict dialects of C? NaCl [1] says "There are an increasing number of cases where the C implementations and assembly-language implementations are automatically generated from code that was actually written in another language, such as CAO or qhasm." CAO is a "a domain specific language for describing cryptographic software" [3], while qhasm [4] is a portable assembly seemingly not focused on safety. [1] http://nacl.cr.yp.to/internals.html http://nacl.cr.yp.to/internals.html [2] http://gcc.gnu.org/onlinedocs/gcc-3.4.3/gnat_ugn_unw/Creating-an-Ada-Library-to-be-Used-in-a-Non_002dAda-Context.html#Creating-an-Ada-Library-to-be-Used-in-a-Non_002dAda-Context http://gcc.gnu.org/onlinedocs/gcc-3.4.3/gnat_ugn_unw/Creatin... [3] [PDF] http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.113.8971&rep=rep1&type=pdf http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.113... [4] http://cr.yp.to/qhasm.html http://cr.yp.to/qhasm.html
  - ehsanu1 13y ago
    Can Rust compile to a shared lib the programs can use as easily as a C library? Yes it can! You use the `#[no_std]` if you wish to be rid of the runtime, and the `#[crate_type = "lib"]` for outputting shared libraries (or use the `--crate-type` compiler flag). Here's an older blog post on it, though the rust code there probably won't compile as-is with current Rust: http://bluishcoder.co.nz/2013/08/08/linking_and_calling_rust_functions_from_c.html http://bluishcoder.co.nz/2013/08/08/linking_and_calling_rust...
    - jnbiche 13y ago
      Unfortunately, this means giving up the powerful Rust standard library and threads. Fortunately, third-party devs are creating a "zero-runtime" standard library that can be used in situations like this, and in embedded programming: https://github.com/thestinger/rust-core https://github.com/thestinger/rust-core Right now, rust-core only provides basic collections and io, but more may be in the works. I suspect rust-core will eventually grow into a small but capable standard library.
      - kibwen 13y ago
        rust-core has been coasting along in maintenance mode for quite a while now, because it was only intended as a temporary stopgap. Nobody really wants to fragment the community with a third-party standard library. Instead, the Rust devs intend to restructure the standard library such that it has multiple profiles, and that you can jettison parts of it (such as the parts that require the runtime) without losing all of the other goodies. Here's the most recent RFC for doing so, filed yesterday: https://github.com/rust-lang/rfcs/pull/40/files https://github.com/rust-lang/rfcs/pull/40/files
        jnbiche 13y ago
        Oh, very cool. I was hoping something like this would emerge.
    - dbaupp 13y ago
- krick 13y ago
  I may err, but I don't really think it's that big issue. First off, "low level" isn't exactly synonymous to "efficient machine-code", I guess we well can expect from languages like Rust to become both efficient and predictable after a while. In fact, every non-lazy well designed static typed language implementation makes it very much possible to write code that compiles in pretty predictable way, so you can control execution time as well. And the last, but not the least, timing attacks aren't chief vulnerability, really. If you expect a timing attack being real hazard you can randomize return time explicitly.
- dscrd 13y ago
  Isn't it then marvellous that Rust is (also) a low-level language?
- chopin 13y ago
  The problem is that a memory unsafe language leaves gaping holes. Protection against timing attacks doesn't help me if one can read my private keys (remotely!) with a simple Python script. Timing attacks at least require colocation in most cases and are much harder to implement and run for meaningful results. It's certainly worth thinking about how we can put memory problems to death in at least crypto code and imho C has proven to be a permanent problem in that regard. I am still a (interested) Haskell beginner but whenever this discussion comes up the first thing I think is "why not try this in Haskell?" and I never give a thought that I would do this in Java which is my everyday language (and reasonably memory safe).
  - jude- 13y ago
    "Timing attacks at least require colocation in most cases and are much harder to implement and run for meaningful results" Not true. It's long been known that timing attacks over a LAN are practical (replace LAN with intra-datacenter network). Relevant paper from 2003: https://crypto.stanford.edu/~dabo/papers/ssl-timing.pdf https://crypto.stanford.edu/~dabo/papers/ssl-timing.pdf
72deluxe 13y ago
Why rewrite C and C++ parts? Just because someone doesn't program properly in one language doesn't mean you need to rewrite everything written in that language. Bit like throwing the baby out with the bathwater.
- andreasvc 13y ago
  Because this type of mistake is easy to make in C and other programming languages make this class of bugs impossible. By moving the need for careful design from library to language implementation you get greater leverage in preventing bugs.
- cowbell 13y ago
  >Just because someone doesn't program properly It isn't just accidental errors you need to worry about. Obfuscated intentional errors are a problem too. If the language design prevents bugs that an NSA mole would try to slip in, then that is a very good reason to rewrite in a new language.

by krick 13y ago

gizmo686 13y ago

Crypto poses a unique challenge with the threat of timing attacks. A major benitif of using low level languages is that it is easier to assure that your code takes constant time regardless of the input.

betterunix 13y ago
With the downside being that things like Heartbleed become possible. Dealing with timing attacks in high-level code is not necessarily hard -- Haskell, for example, has strict evaluation.
pmahoney 13y ago
So what candidates are there? While C may make it possible to write code that avoids timing attacks, a quick glance at [1] shows one must avoid memcmp and array lookups based on secret data, neither of which would be prevented by the compiler, and both probably similarly easy mistakes as heartbleed. Can Rust compile to a shared lib the programs can use as easily as a C library? (I think the answer is "not yet", but I'm not sure? At least, I've seen projects for compiling Rust without any runtime library). Today I learned this is possible with Ada [2], but it seems there is some boilerplate to start/stop the runtime. Does Ada provide the necessary low-level control to implement crypto? Are there sufficiently strict dialects of C? NaCl [1] says "There are an increasing number of cases where the C implementations and assembly-language implementations are automatically generated from code that was actually written in another language, such as CAO or qhasm." CAO is a "a domain specific language for describing cryptographic software" [3], while qhasm [4] is a portable assembly seemingly not focused on safety. [1] http://nacl.cr.yp.to/internals.html http://nacl.cr.yp.to/internals.html [2] http://gcc.gnu.org/onlinedocs/gcc-3.4.3/gnat_ugn_unw/Creating-an-Ada-Library-to-be-Used-in-a-Non_002dAda-Context.html#Creating-an-Ada-Library-to-be-Used-in-a-Non_002dAda-Context http://gcc.gnu.org/onlinedocs/gcc-3.4.3/gnat_ugn_unw/Creatin... [3] [PDF] http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.113.8971&rep=rep1&type=pdf http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.113... [4] http://cr.yp.to/qhasm.html http://cr.yp.to/qhasm.html
- ehsanu1 13y ago
  Can Rust compile to a shared lib the programs can use as easily as a C library? Yes it can! You use the `#[no_std]` if you wish to be rid of the runtime, and the `#[crate_type = "lib"]` for outputting shared libraries (or use the `--crate-type` compiler flag). Here's an older blog post on it, though the rust code there probably won't compile as-is with current Rust: http://bluishcoder.co.nz/2013/08/08/linking_and_calling_rust_functions_from_c.html http://bluishcoder.co.nz/2013/08/08/linking_and_calling_rust...
  - jnbiche 13y ago
    Unfortunately, this means giving up the powerful Rust standard library and threads. Fortunately, third-party devs are creating a "zero-runtime" standard library that can be used in situations like this, and in embedded programming: https://github.com/thestinger/rust-core https://github.com/thestinger/rust-core Right now, rust-core only provides basic collections and io, but more may be in the works. I suspect rust-core will eventually grow into a small but capable standard library.
    - kibwen 13y ago
      rust-core has been coasting along in maintenance mode for quite a while now, because it was only intended as a temporary stopgap. Nobody really wants to fragment the community with a third-party standard library. Instead, the Rust devs intend to restructure the standard library such that it has multiple profiles, and that you can jettison parts of it (such as the parts that require the runtime) without losing all of the other goodies. Here's the most recent RFC for doing so, filed yesterday: https://github.com/rust-lang/rfcs/pull/40/files https://github.com/rust-lang/rfcs/pull/40/files
      - jnbiche 13y ago
        Oh, very cool. I was hoping something like this would emerge.
  - dbaupp 13y ago
krick 13y ago
I may err, but I don't really think it's that big issue. First off, "low level" isn't exactly synonymous to "efficient machine-code", I guess we well can expect from languages like Rust to become both efficient and predictable after a while. In fact, every non-lazy well designed static typed language implementation makes it very much possible to write code that compiles in pretty predictable way, so you can control execution time as well. And the last, but not the least, timing attacks aren't chief vulnerability, really. If you expect a timing attack being real hazard you can randomize return time explicitly.
dscrd 13y ago
Isn't it then marvellous that Rust is (also) a low-level language?
chopin 13y ago
The problem is that a memory unsafe language leaves gaping holes. Protection against timing attacks doesn't help me if one can read my private keys (remotely!) with a simple Python script. Timing attacks at least require colocation in most cases and are much harder to implement and run for meaningful results. It's certainly worth thinking about how we can put memory problems to death in at least crypto code and imho C has proven to be a permanent problem in that regard. I am still a (interested) Haskell beginner but whenever this discussion comes up the first thing I think is "why not try this in Haskell?" and I never give a thought that I would do this in Java which is my everyday language (and reasonably memory safe).
- jude- 13y ago
  "Timing attacks at least require colocation in most cases and are much harder to implement and run for meaningful results" Not true. It's long been known that timing attacks over a LAN are practical (replace LAN with intra-datacenter network). Relevant paper from 2003: https://crypto.stanford.edu/~dabo/papers/ssl-timing.pdf https://crypto.stanford.edu/~dabo/papers/ssl-timing.pdf

72deluxe 13y ago

Why rewrite C and C++ parts? Just because someone doesn't program properly in one language doesn't mean you need to rewrite everything written in that language. Bit like throwing the baby out with the bathwater.

andreasvc 13y ago
Because this type of mistake is easy to make in C and other programming languages make this class of bugs impossible. By moving the need for careful design from library to language implementation you get greater leverage in preventing bugs.
cowbell 13y ago
>Just because someone doesn't program properly It isn't just accidental errors you need to worry about. Obfuscated intentional errors are a problem too. If the language design prevents bugs that an NSA mole would try to slip in, then that is a very good reason to rewrite in a new language.