4 ms·

It may be impossible to distinguish genuine bugs from bug-backdoors, which is why it's important to start developing crypto in safer frameworks and languages. C

by iwwr 13y ago

It may be impossible to distinguish genuine bugs from bug-backdoors, which is why it's important to start developing crypto in safer frameworks and languages. C considered harmful.

sillysaurus3 13y ago
The problem is that GCs are considered harmful to crypto code, though that may be changing with Go. We won't know for about 5 years whether it's trustworthy, and even then, the side channel threat posed by GC may be worth worrying about. Some big-name cryptographers have started implementing some useful crypto services in Go, so we'll see whether it catches on. EDIT: Is the JVM generally trusted by cryptographers? I just realized that TextSecure is java code. Is the side channel threat posed by GC not too serious, then?
- gsnedders 13y ago
  Rust provides memory safety without a GC, which seems more promising than anything else for this sort of application.
- pornel 13y ago
  C vs GC is a false dichotomy. There can be safer-than-C languages that don't use GC, e.g. you don't need GC for array bounds checking. You can use reference counting for more deterministic garbage collection.
  - sillysaurus3 13y ago
    Refcounting unfortunately fails for GC because it can't handle cyclic dependencies, e.g. object A references object B which references object A, now neither object will ever be freed even if nothing else references A or B.
    - anextio 13y ago
      Objective-C programmers have been using refcounting at scale for at least 2 decades. No problems here.
      - sillysaurus3 13y ago
        How is it possible to use refcounting for GC while also correctly handling cyclic references? EDIT: Objective-C doesn't solve the problem at all. (More precisely, it requires manual intervention by the programmer.) See http://stackoverflow.com/questions/6260256/what-kind-of-leaks-does-automatic-reference-counting-in-objective-c-not-prevent/6388601#6388601 http://stackoverflow.com/questions/6260256/what-kind-of-leak... From the article: "This occurs when one object has a strong pointer to another, but the target object has a strong pointer back to the original." Some backrground info on Objective-C's memory management: http://stackoverflow.com/questions/7874342/what-is-the-difference-between-objective-c-automatic-reference-counting-and-garb/7894809#7894809 http://stackoverflow.com/questions/7874342/what-is-the-diffe... It's an interesting approach to insert release calls at compile time. Maybe it's worth not solving the cyclic reference problem in exchange for determinism. Thank you for pointing that out.
      - mikeash 13y ago
        I wouldn't say "no problems here" at all. Memory management errors are extremely common in Objective-C code. This is true even with ARC. The problems can be solved, but they are certainly there. The question of cycles is even more pertinent with ARC, because it's easy to get used to letting the compiler do everything for you, and it's easy to miss an occasional leak of a cyclic object graph.
    - pornel 13y ago
      You don't need to automatically solve all the problems to get a safer language than C/C++. I don't think cyclic object graphs are needed to, say, respond to a TLS heartbeat without out-of-bounds reads.
- jerf 13y ago
  "The problem is that GCs are considered harmful to crypto code, though that may be changing with Go." I'm curious what about Go's GC leads you to say that? Is it that when you get a new chunk of bytes, they've been pre-zeroed? That's not specifically a characteristic of the GC but it's my best guess. Otherwise I don't know what it would be, which is why I ask.
  - sillysaurus3 13y ago
    I don't know enough about it to say anything more than "I noticed some big-name cryptographers have begun writing crypto services in Go, so maybe it's safe." Trusting expert cryptographers to make safe decisions and then waiting five years for cryptanalysis to catch up is probably a safe course of action. (Moreso the "wait five years for cryptographers to poke holes in it" part.) I remember some discussion on HN where someone mentioned that GCs pose a problem for secure code due to the non-deterministic nature of GC. There's apparently a nonzero chance of introducing a side-channel attack via GC. Until we're certain that chance is far closer to "zero" than "non-zero," we should either study that threat vector in detail or find a safer option. It would be horrible to switch to something which is then proven to be broken in some fundamental and unfixable way, such as a GC side channel attack.
- Shish2k 13y ago
  > The problem is that GCs are considered harmful to crypto code Could a GC'ed language not just pause the GC thread while it executes a given block of code?

by iwwr 13y ago

It may be impossible to distinguish genuine bugs from bug-backdoors, which is why it's important to start developing crypto in safer frameworks and languages. C considered harmful.

sillysaurus3 13y ago

The problem is that GCs are considered harmful to crypto code, though that may be changing with Go. We won't know for about 5 years whether it's trustworthy, and even then, the side channel threat posed by GC may be worth worrying about. Some big-name cryptographers have started implementing some useful crypto services in Go, so we'll see whether it catches on. EDIT: Is the JVM generally trusted by cryptographers? I just realized that TextSecure is java code. Is the side channel threat posed by GC not too serious, then?

gsnedders 13y ago
Rust provides memory safety without a GC, which seems more promising than anything else for this sort of application.
pornel 13y ago
C vs GC is a false dichotomy. There can be safer-than-C languages that don't use GC, e.g. you don't need GC for array bounds checking. You can use reference counting for more deterministic garbage collection.
- sillysaurus3 13y ago
  Refcounting unfortunately fails for GC because it can't handle cyclic dependencies, e.g. object A references object B which references object A, now neither object will ever be freed even if nothing else references A or B.
  - anextio 13y ago
    Objective-C programmers have been using refcounting at scale for at least 2 decades. No problems here.
    - sillysaurus3 13y ago
      How is it possible to use refcounting for GC while also correctly handling cyclic references? EDIT: Objective-C doesn't solve the problem at all. (More precisely, it requires manual intervention by the programmer.) See http://stackoverflow.com/questions/6260256/what-kind-of-leaks-does-automatic-reference-counting-in-objective-c-not-prevent/6388601#6388601 http://stackoverflow.com/questions/6260256/what-kind-of-leak... From the article: "This occurs when one object has a strong pointer to another, but the target object has a strong pointer back to the original." Some backrground info on Objective-C's memory management: http://stackoverflow.com/questions/7874342/what-is-the-difference-between-objective-c-automatic-reference-counting-and-garb/7894809#7894809 http://stackoverflow.com/questions/7874342/what-is-the-diffe... It's an interesting approach to insert release calls at compile time. Maybe it's worth not solving the cyclic reference problem in exchange for determinism. Thank you for pointing that out.
    - mikeash 13y ago
      I wouldn't say "no problems here" at all. Memory management errors are extremely common in Objective-C code. This is true even with ARC. The problems can be solved, but they are certainly there. The question of cycles is even more pertinent with ARC, because it's easy to get used to letting the compiler do everything for you, and it's easy to miss an occasional leak of a cyclic object graph.
  - pornel 13y ago
    You don't need to automatically solve all the problems to get a safer language than C/C++. I don't think cyclic object graphs are needed to, say, respond to a TLS heartbeat without out-of-bounds reads.
jerf 13y ago
"The problem is that GCs are considered harmful to crypto code, though that may be changing with Go." I'm curious what about Go's GC leads you to say that? Is it that when you get a new chunk of bytes, they've been pre-zeroed? That's not specifically a characteristic of the GC but it's my best guess. Otherwise I don't know what it would be, which is why I ask.
- sillysaurus3 13y ago
  I don't know enough about it to say anything more than "I noticed some big-name cryptographers have begun writing crypto services in Go, so maybe it's safe." Trusting expert cryptographers to make safe decisions and then waiting five years for cryptanalysis to catch up is probably a safe course of action. (Moreso the "wait five years for cryptographers to poke holes in it" part.) I remember some discussion on HN where someone mentioned that GCs pose a problem for secure code due to the non-deterministic nature of GC. There's apparently a nonzero chance of introducing a side-channel attack via GC. Until we're certain that chance is far closer to "zero" than "non-zero," we should either study that threat vector in detail or find a safer option. It would be horrible to switch to something which is then proven to be broken in some fundamental and unfixable way, such as a GC side channel attack.
Shish2k 13y ago
> The problem is that GCs are considered harmful to crypto code Could a GC'ed language not just pause the GC thread while it executes a given block of code?