3 ms·

> in an environment where security is important with my present day knowledge of the pitfalls of C it would likely be the last language I would pick Note howev

by acqq 7y ago

> in an environment where security is important with my present day knowledge of the pitfalls of C it would likely be the last language I would pick Note however that even the those languages promoted as "safer" and "better" at the end typically use the C implementations of cryptographic routines (or avoid their own "safe" rules exactly when producing such a code which then ends up being "just C in disguise"). I see then some "wrappers" but at the end... it's still C (or assembly) that does the job. As far as I'm aware, nobody managed to produce both the "safety" and everything else necessary to the point to be the "best" solution for real-life use cases.

Dylan16807 7y ago
I bet that's almost entirely based on preferring the devil you know. Trying to write C without side channels is a ridiculously fragile affair. Many high level languages aren't suited to it, but that doesn't mean C is suited to it. Nobody should be using C for that kind of code either. Assembly maybe. The good answer is a language that can handle arrays safely and also make guarantees about what's actually executed.
codetrotter 7y ago
> or avoid their own "safe" rules exactly when producing such a code which then ends up being "just C in disguise" The point with being able to do this though is that sometimes you really do need to use unsafe code, but you still get to isolate the unsafe parts of your codebase from the safe parts of it, and you do so in a way that is defined by the language itself rather than in an ad-hoc way. The language and the compiler enforces safety for the rest of your codebase, which in most cases makes up the vast majority of the codebase, and for the unsafe parts of the codebase where it doesn’t, you have a much more limited and clearly defined surface of code that you and everyone else looking at the code will know that needs to be handled with extra care, and which can and should be audited extra thoroughly.
- mikepurvis 7y ago
  And in the specific case of cryptographically secure code, you may well need to be paying attention to extremely low level details like the number of instructions being executed on different branches, the states of various buffers and caches, etc. It may well be that it doesn't make sense to expose control over these things to the high level layer where it's irrelevant 99% of the time.

by acqq 7y ago

Dylan16807 7y ago

I bet that's almost entirely based on preferring the devil you know. Trying to write C without side channels is a ridiculously fragile affair. Many high level languages aren't suited to it, but that doesn't mean C is suited to it. Nobody should be using C for that kind of code either. Assembly maybe. The good answer is a language that can handle arrays safely and also make guarantees about what's actually executed.

codetrotter 7y ago

> or avoid their own "safe" rules exactly when producing such a code which then ends up being "just C in disguise" The point with being able to do this though is that sometimes you really do need to use unsafe code, but you still get to isolate the unsafe parts of your codebase from the safe parts of it, and you do so in a way that is defined by the language itself rather than in an ad-hoc way. The language and the compiler enforces safety for the rest of your codebase, which in most cases makes up the vast majority of the codebase, and for the unsafe parts of the codebase where it doesn’t, you have a much more limited and clearly defined surface of code that you and everyone else looking at the code will know that needs to be handled with extra care, and which can and should be audited extra thoroughly.

mikepurvis 7y ago
And in the specific case of cryptographically secure code, you may well need to be paying attention to extremely low level details like the number of instructions being executed on different branches, the states of various buffers and caches, etc. It may well be that it doesn't make sense to expose control over these things to the high level layer where it's irrelevant 99% of the time.