3 ms·

Since bitexploder asked, I'll add what I wrote on this on other forums. If it's about secrets or anonymity, make sure you always use a safe language that suppor

Since bitexploder asked, I'll add what I wrote on this on other forums. If it's about secrets or anonymity, make sure you always use a safe language that supports careful control and reasoning about both memory and CPU time. The reason is that this enables covert, channel analysis for vulnerabilities that leak secrets through storage and timing. It's why I wanted Freenet to ditch Java aside from the obvious reasons. It's also why GC languages such as Go are better not used. Although, memory management where programmer controls timing & it's simple to analyze might be used. Reference counting comes to mind. The other thing you want is proven, successful use in high-assurance systems. That is, systems that either didn't fail or provably couldn't in certain ways. These are almost all written in a subset of C or Ada/SPARK. The advantage of using those is you can combine them with a vast array of proprietary or open-source tooling to catch about any error you can think of if it's implementation. There's also formal specification and protocol analysis tools that combined with expert review can catch the rest. Rust, although a good choice for increased safety/security, doesn't have such tooling yet. That means they will get less correctness overall and over time vs MISRA-C or Ada/SPARK unless similar ecosystem in industry and CompSci emerges for Rust. That's why I recommend against it for high-assurance security for now. It does seem good for medium-assurance security where you want to knock out low hanging fruit in systems code. It will avoid serious errors in C while providing additional benefits with type system and other features. Ada 2012 + SPARK 2014 are the standard for safe systems since they systematically eliminate all kinds of errors with a consistent design and tooling with decades of field success. I haven't seen a direct comparison with Rust on each protection to see if it matches it already or not. The main advantages Rust has over them are its borrow-checker for temporal safety, more usable method for safe concurrency, and (best for last) highly-active community to provide libraries or help. Go has similar benefits if its GC works with your use case but a lower, learning curve & possibly lower efficiency. Due to ecosystem benefits, these are main two I'm recommending for medium assurance if Ada/SPARK are too much to learn.

wyager 10y ago
It's unlikely that the cost of whole-program side channel resistance is worth it for an application like Tor. Side-channel-resistant cryptography is almost certainly sufficient for most reasonable threat/cost models.
- nickpsecurity 10y ago
  You can limit it to the protocol layer. High-assurance security in military systems just used fixed-speed, fixed-timing transmission with covert channel analysis of setup, crypto operations, and error handling. Any problems at all violating key invariants cause fail-safe. Tor could do something similar. Still need a language that allows such analysis at least for those components being analyzed.
geofft 10y ago
You can use some analysis tools on Rust code, because it generates C-ABI-compatible objects; for instance, I'd expect that https://github.com/agl/ctgrind https://github.com/agl/ctgrind would work on Rust. Looking at the MISRA-C guidelines (or more specifically, a pirated copy - are these available legitimately to the public?), it seems like about half of them aren't problems in Rust, because it's warning you about stupid things in C that can't be fixed for legacy reasons, and half of them are things that could be caught with a linter / static analysis tool like https://github.com/Manishearth/rust-clippy https://github.com/Manishearth/rust-clippy . Do you think building something that implements as many of the MISRA-C checks as possible is useful progress towards the high-assurance Rust goal?
- nickpsecurity 10y ago
  I said MISRA-C combined with tooling. Many of the best tools using very, diverse methods start from a safer subset of C (eg MISRA-C) or need C itself. Such tools would have to be rewritten for use with Rust. Difficulty of that varies per tool but it's not happening for most right now.
ianopolous 10y ago
G'day Nick! Java is getting an AOT compiler in July (Graal, http://openjdk.java.net/jeps/295 http://openjdk.java.net/jeps/295) that will let you AOT compile parts, or all, of your program, including the JVM modules themselves. This would seem to leave the GC as the main source of side channel vulnerabilities. The GC itself will become more pluggable as well, with a pure Java implementation. What requirements would you put on a GC for side channel safety? (Ignoring the obvious just allocate a large heap and never GC anything, eventually just restarting the process when it runs out of heap). What if we had a fully concurrent, pauseless GC (e.g. Azul), would that change things? What other issues would remain in your opinion?
- Sanddancer 10y ago
  A concurrent GC running on a single processor machine is still going to pause. There are still other ways to get into situations where an attacker can cause the gc to kick in in ways where you can get information -- find a few CPU-heavy functions that nudge the GC to kick in when and where you want it. Harder, but even a background GC can wiggle into the foreground.
  - ianopolous 10y ago
    Even a statically compiled program run on a single core machine will pause because of the OS scheduler. Assuming we have a multicore cpu then one core can be dedicated to the GC.
    - nickpsecurity 10y ago
      Good you're thinking out the box. That pause might not be a problem, though. The pauses that are a problem when the malicious app can control the timing with an external observer seeing those manipulations. The OS scheduler is usually independent of secret processing. It's just doing it's own thing causing pauses that don't tell you about the secret itself. Theoretically, there could be an esoteric attack in some situation where an OS scheduler would accidentally leak somethinh or be activated to leak something. Not popping into mind righg now, though.
- 10y ago
bitexploder 10y ago
I get the side channel concerns, but most developers make a mess of languages that let you control these things. A few, very few, people I trust to write in a language like C build tools I trust (Dan B, etc). I also think it is very hard to convince folks about side channel concerns. We have to live in the world we have too (e.g. Signal on an Android is better than not having it, etc.). When I document side channel issues in customer code there is almost some way higher priority issue they have to fix first, etc. But your advice is good for someone endeavoring to do a "correct" approach from the ground up. Thanks for the detailed thoughts though. This is the sort of thinking anyone who thinks "I will write a secure chat program" has to do ages before they start writing code.
hckr1292 10y ago
What are good resources for learning Ada/SPARK and MISRA-C?
- nickpsecurity 10y ago
  Those resource change quite a bit over time since it's both a small, legacy ecosystem and a constantly-changing, active ecosystem. I'd have to update my resources when my busy, busy schedules slow down. I plan to, though, on those two tech w/ guides & whatever FOSS tools I find. Just email me at address in my profile about it. I'll just save it in there so I can email it back to you once I'm up-to-date on the learning resources & tools available.

wyager 10y ago

It's unlikely that the cost of whole-program side channel resistance is worth it for an application like Tor. Side-channel-resistant cryptography is almost certainly sufficient for most reasonable threat/cost models.

nickpsecurity 10y ago
You can limit it to the protocol layer. High-assurance security in military systems just used fixed-speed, fixed-timing transmission with covert channel analysis of setup, crypto operations, and error handling. Any problems at all violating key invariants cause fail-safe. Tor could do something similar. Still need a language that allows such analysis at least for those components being analyzed.

geofft 10y ago

You can use some analysis tools on Rust code, because it generates C-ABI-compatible objects; for instance, I'd expect that https://github.com/agl/ctgrind https://github.com/agl/ctgrind would work on Rust. Looking at the MISRA-C guidelines (or more specifically, a pirated copy - are these available legitimately to the public?), it seems like about half of them aren't problems in Rust, because it's warning you about stupid things in C that can't be fixed for legacy reasons, and half of them are things that could be caught with a linter / static analysis tool like https://github.com/Manishearth/rust-clippy https://github.com/Manishearth/rust-clippy . Do you think building something that implements as many of the MISRA-C checks as possible is useful progress towards the high-assurance Rust goal?

nickpsecurity 10y ago
I said MISRA-C combined with tooling. Many of the best tools using very, diverse methods start from a safer subset of C (eg MISRA-C) or need C itself. Such tools would have to be rewritten for use with Rust. Difficulty of that varies per tool but it's not happening for most right now.

ianopolous 10y ago

G'day Nick! Java is getting an AOT compiler in July (Graal, http://openjdk.java.net/jeps/295 http://openjdk.java.net/jeps/295) that will let you AOT compile parts, or all, of your program, including the JVM modules themselves. This would seem to leave the GC as the main source of side channel vulnerabilities. The GC itself will become more pluggable as well, with a pure Java implementation. What requirements would you put on a GC for side channel safety? (Ignoring the obvious just allocate a large heap and never GC anything, eventually just restarting the process when it runs out of heap). What if we had a fully concurrent, pauseless GC (e.g. Azul), would that change things? What other issues would remain in your opinion?

Sanddancer 10y ago
A concurrent GC running on a single processor machine is still going to pause. There are still other ways to get into situations where an attacker can cause the gc to kick in in ways where you can get information -- find a few CPU-heavy functions that nudge the GC to kick in when and where you want it. Harder, but even a background GC can wiggle into the foreground.
- ianopolous 10y ago
  Even a statically compiled program run on a single core machine will pause because of the OS scheduler. Assuming we have a multicore cpu then one core can be dedicated to the GC.
  - nickpsecurity 10y ago
    Good you're thinking out the box. That pause might not be a problem, though. The pauses that are a problem when the malicious app can control the timing with an external observer seeing those manipulations. The OS scheduler is usually independent of secret processing. It's just doing it's own thing causing pauses that don't tell you about the secret itself. Theoretically, there could be an esoteric attack in some situation where an OS scheduler would accidentally leak somethinh or be activated to leak something. Not popping into mind righg now, though.
10y ago

bitexploder 10y ago

I get the side channel concerns, but most developers make a mess of languages that let you control these things. A few, very few, people I trust to write in a language like C build tools I trust (Dan B, etc). I also think it is very hard to convince folks about side channel concerns. We have to live in the world we have too (e.g. Signal on an Android is better than not having it, etc.). When I document side channel issues in customer code there is almost some way higher priority issue they have to fix first, etc. But your advice is good for someone endeavoring to do a "correct" approach from the ground up. Thanks for the detailed thoughts though. This is the sort of thinking anyone who thinks "I will write a secure chat program" has to do ages before they start writing code.

hckr1292 10y ago

What are good resources for learning Ada/SPARK and MISRA-C?

nickpsecurity 10y ago
Those resource change quite a bit over time since it's both a small, legacy ecosystem and a constantly-changing, active ecosystem. I'd have to update my resources when my busy, busy schedules slow down. I plan to, though, on those two tech w/ guides & whatever FOSS tools I find. Just email me at address in my profile about it. I'll just save it in there so I can email it back to you once I'm up-to-date on the learning resources & tools available.