Hacker News Reader

Comment by sillysaurus3 | Hacker News Reader

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?

View on HN

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.

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.

Objective-C programmers have been using refcounting at scale for at least 2 decades.

No problems here.

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-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-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.

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.

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.

Rust provides memory safety without a GC, which seems more promising than anything else for this sort of application.

"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.

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.

> 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?

Reply on news.ycombinator.com