2 ms·

C adds a layer between your code and the system. It abstracts away memory layout, locations, as well as function call semantics, and a many other things. For ex

C adds a layer between your code and the system. It abstracts away memory layout, locations, as well as function call semantics, and a many other things. For example, given a C program, you will not be able to tell me with certainty that a variable will occupy memory on the stack, any of your particular processor registers, etc. Formally, C is a language to control the C Abstract Machine, as described in the standard. The sort of direct control one might look for is, as far as I know, only practically found in your processor's assembly language, and your operating system's collection of syscalls. I think Rust, Common Lisp, OCaml, D, Haskell, and other languages give you a lot of benefits that are simply not worth giving up in a new crypto library, like safety.

bandook_raja 9y ago
Rust doesn't even exist on a plethora of platforms which C targets. I have high hopes with D and give or take ~2 years, it'll be able to progress forward in lots of domains. Not sure about other languages.
- simias 9y ago
  One big long term advantage of Rust is that it leverages LLVM. Basically anywhere LLVM gets ported Rust follows. I could run Rust code on a PlayStation and PocketStation (although I had to cheat a bit on the former because LLVM doesn't support MIPS I). LLVM is not as widely ported as GCC (especially on older, deprecated hardware) but it's getting there. https://svkt.org/~simias/rustation/pockestation-rust.jpg https://svkt.org/~simias/rustation/pockestation-rust.jpg
- pjmlp 9y ago
  That is a matter of tooling, though. Until the early 90's C had hardly any meaning outside big expensive UNIX boxes. And it was already on its way out on Windows and OS/2, if it wasn't for the rise of FOSS software and its dependency on C.
  - SidiousL 9y ago
    I think it might be a bit more than that. As far as I can see, all the primitive data types in Rust have sizes which are multiples of eight. However, there are still architectures out there with 9 bit bytes, or 36-bit words. Maybe it's good that all the primitive data types have an explicit size (encoded in their name), but this comes at a cost (in case a byte is 9 bits long, one of the bits will effectively not be used). On the other hand, C and C++ are less explicit about the sizes of their data types so they can accommodate these more weird architectures more easily (and, if you need an explicit size, you can explicitly ask for it).
    - simias 9y ago
      You have a point but in general you wouldn't write "generic" C code on these exotic (by modern standards) architectures. So I guess if you wanted to port Rust to these systems you could introduce an i9 and an i36 and use that instead. I doubt you could get firefox and its dependencies to work on a CHAR_BIT == 9 system without some heavy modifications. I could be wrong though, it's not like I tried. In my experience most modern codebases tend to target POSIX systems (explicitly or implicitly). That gives you a subset of C to work with and makes your life easier. The exceptions are things like DSPs which can have rather non-standard layouts but you generally write very specific and unportable code for these anyway. Of course if you want to be completely portable you can't assume that CHAR_BIT == 8 or that you can convert back and forth between function and data pointers but in practice a lot of software relies on this. Even before stdint became part of the standard it was very common for programs and libraries to typedef their own "sized" integer types. It's the only reasonable way to deal with ints in C IMO, otherwise you can't assume that your ints are greater than 16bits (which is probably too tiny for many uses) so you're tempted to put "longs" everywhere. But then longs will be 64bits on modern architectures which could be overkill and reduce performance. So in theory those variable-size integer types are interesting but in practice they're basically useless because you end up making assumptions, one way or an other. I think it was a good idea for Rust to get rid of them.
- honestoHeminway 9y ago
  Any language that needs evangelists is clearly not able to progress on its own merits and archievments.
  - Ar-Curunir 9y ago
    What? You think other languages don't have "fan-people"? People who like Rust tend to like it very much, and it does provide a real solution to problems that C and C++ create, while providing a no-compromise performance story. So why wouldn't people talk about it?
  - oblio 9y ago
    Perl had evangelists, Ruby (on Rails) had evangelists, C++ had evangelists, Java had evangelists (some would say Java even had apostles and Messiahs...), almost every language has evangelists.
adwn 9y ago
> Haskell I think writing timing-attack resistant code in Haskell would be very hard to impossible, at least without writing very unidiomatic code (basically "C in Haskell"). I'm happy to be proven wrong, though.
- pjmlp 9y ago
  Writing unidiomatic code would still be compliant with the Haskell Language Report, compiled by an Haskell compiler and safer than plain C code.
- diegoperini 9y ago
  Honest question: What makes you think you can't mitigate? A̶ ̶t̶y̶p̶e̶s̶a̶f̶e̶ ̶c̶r̶y̶p̶t̶o̶ ̶t̶h̶a̶t̶ ̶m̶e̶a̶s̶u̶r̶e̶s̶ ̶i̶t̶s̶ ̶e̶x̶e̶c̶u̶t̶i̶o̶n̶ ̶t̶i̶m̶e̶ ̶a̶p̶p̶e̶n̶d̶e̶d̶ ̶w̶i̶t̶h̶ ̶a̶ ̶f̶i̶n̶a̶l̶ ̶d̶e̶l̶a̶y̶ ̶t̶i̶m̶e̶ ̶r̶e̶a̶d̶ ̶f̶r̶o̶m̶ ̶/̶d̶e̶v̶/̶u̶r̶a̶n̶d̶o̶m̶ ̶c̶a̶n̶ ̶s̶t̶i̶l̶l̶ ̶b̶e̶ ̶i̶d̶i̶o̶m̶a̶t̶i̶c̶.̶ It has to be monadic, that is for sure but abstracting a crypto algorithm as IO is actually treating it as a device which sounds like a safe metaphor. Edit: Whoah, why the hate? :(
  - loup-vaillant 9y ago
    I believe padding the timing always has been considered a bad idea. If you want to guarantee you won't exceed the timing, you probably have to take so much margin that your primitive becomes prohibitively slow. And I'm not even sure it would protect you against cache timing attacks. Simply put, there are easier and cheaper ways to guarantee timings. Perhaps Haskell is even capable of harnessing them. (I'm thinking of the usual "no secret dependent branches", and "no secret dependent indices".)
  - Ded7xSEoPKYNsDd 9y ago
    Random delays do not protect against timing attacks. Best thing it can do, is to force the attacker to collect a few more timing samples. (To the point where the the random noise averages itself out.)
- willtim 9y ago
x91823wu791 9y ago
This is an idiotic statement and typical meaningless HN lecturing. OCaml does not even have the basic integer types required for published algorithms.

bandook_raja 9y ago

Rust doesn't even exist on a plethora of platforms which C targets. I have high hopes with D and give or take ~2 years, it'll be able to progress forward in lots of domains. Not sure about other languages.

simias 9y ago
One big long term advantage of Rust is that it leverages LLVM. Basically anywhere LLVM gets ported Rust follows. I could run Rust code on a PlayStation and PocketStation (although I had to cheat a bit on the former because LLVM doesn't support MIPS I). LLVM is not as widely ported as GCC (especially on older, deprecated hardware) but it's getting there. https://svkt.org/~simias/rustation/pockestation-rust.jpg https://svkt.org/~simias/rustation/pockestation-rust.jpg
pjmlp 9y ago
That is a matter of tooling, though. Until the early 90's C had hardly any meaning outside big expensive UNIX boxes. And it was already on its way out on Windows and OS/2, if it wasn't for the rise of FOSS software and its dependency on C.
- SidiousL 9y ago
  I think it might be a bit more than that. As far as I can see, all the primitive data types in Rust have sizes which are multiples of eight. However, there are still architectures out there with 9 bit bytes, or 36-bit words. Maybe it's good that all the primitive data types have an explicit size (encoded in their name), but this comes at a cost (in case a byte is 9 bits long, one of the bits will effectively not be used). On the other hand, C and C++ are less explicit about the sizes of their data types so they can accommodate these more weird architectures more easily (and, if you need an explicit size, you can explicitly ask for it).
  - simias 9y ago
    You have a point but in general you wouldn't write "generic" C code on these exotic (by modern standards) architectures. So I guess if you wanted to port Rust to these systems you could introduce an i9 and an i36 and use that instead. I doubt you could get firefox and its dependencies to work on a CHAR_BIT == 9 system without some heavy modifications. I could be wrong though, it's not like I tried. In my experience most modern codebases tend to target POSIX systems (explicitly or implicitly). That gives you a subset of C to work with and makes your life easier. The exceptions are things like DSPs which can have rather non-standard layouts but you generally write very specific and unportable code for these anyway. Of course if you want to be completely portable you can't assume that CHAR_BIT == 8 or that you can convert back and forth between function and data pointers but in practice a lot of software relies on this. Even before stdint became part of the standard it was very common for programs and libraries to typedef their own "sized" integer types. It's the only reasonable way to deal with ints in C IMO, otherwise you can't assume that your ints are greater than 16bits (which is probably too tiny for many uses) so you're tempted to put "longs" everywhere. But then longs will be 64bits on modern architectures which could be overkill and reduce performance. So in theory those variable-size integer types are interesting but in practice they're basically useless because you end up making assumptions, one way or an other. I think it was a good idea for Rust to get rid of them.
honestoHeminway 9y ago
Any language that needs evangelists is clearly not able to progress on its own merits and archievments.
- Ar-Curunir 9y ago
  What? You think other languages don't have "fan-people"? People who like Rust tend to like it very much, and it does provide a real solution to problems that C and C++ create, while providing a no-compromise performance story. So why wouldn't people talk about it?
- oblio 9y ago
  Perl had evangelists, Ruby (on Rails) had evangelists, C++ had evangelists, Java had evangelists (some would say Java even had apostles and Messiahs...), almost every language has evangelists.

adwn 9y ago

> Haskell I think writing timing-attack resistant code in Haskell would be very hard to impossible, at least without writing very unidiomatic code (basically "C in Haskell"). I'm happy to be proven wrong, though.

pjmlp 9y ago
Writing unidiomatic code would still be compliant with the Haskell Language Report, compiled by an Haskell compiler and safer than plain C code.
diegoperini 9y ago
Honest question: What makes you think you can't mitigate? A̶ ̶t̶y̶p̶e̶s̶a̶f̶e̶ ̶c̶r̶y̶p̶t̶o̶ ̶t̶h̶a̶t̶ ̶m̶e̶a̶s̶u̶r̶e̶s̶ ̶i̶t̶s̶ ̶e̶x̶e̶c̶u̶t̶i̶o̶n̶ ̶t̶i̶m̶e̶ ̶a̶p̶p̶e̶n̶d̶e̶d̶ ̶w̶i̶t̶h̶ ̶a̶ ̶f̶i̶n̶a̶l̶ ̶d̶e̶l̶a̶y̶ ̶t̶i̶m̶e̶ ̶r̶e̶a̶d̶ ̶f̶r̶o̶m̶ ̶/̶d̶e̶v̶/̶u̶r̶a̶n̶d̶o̶m̶ ̶c̶a̶n̶ ̶s̶t̶i̶l̶l̶ ̶b̶e̶ ̶i̶d̶i̶o̶m̶a̶t̶i̶c̶.̶ It has to be monadic, that is for sure but abstracting a crypto algorithm as IO is actually treating it as a device which sounds like a safe metaphor. Edit: Whoah, why the hate? :(
- loup-vaillant 9y ago
  I believe padding the timing always has been considered a bad idea. If you want to guarantee you won't exceed the timing, you probably have to take so much margin that your primitive becomes prohibitively slow. And I'm not even sure it would protect you against cache timing attacks. Simply put, there are easier and cheaper ways to guarantee timings. Perhaps Haskell is even capable of harnessing them. (I'm thinking of the usual "no secret dependent branches", and "no secret dependent indices".)
- Ded7xSEoPKYNsDd 9y ago
  Random delays do not protect against timing attacks. Best thing it can do, is to force the attacker to collect a few more timing samples. (To the point where the the random noise averages itself out.)
willtim 9y ago

x91823wu791 9y ago

This is an idiotic statement and typical meaningless HN lecturing. OCaml does not even have the basic integer types required for published algorithms.