Return to Answer

I think I can answer this question for the specific case of a crypto library written in Go---it is easy, and not at all hypothetical, because there already is a standalone TLS package, crypto/tls in Go that does not depend on any outside library.

Whilst with regard to typical buffer overflows, idiomatic Go is much safer than traditional C, Go offers the keen developer plenty of options to sidestep it---such as imitating C's pointer arithmetic through Go's unsafe.pointer. One wonders if one could agree not to use fragile code in a crytical piece of software.

Cryptography, of course, is exactly the kind of software using such fragile code, for good reasons. After all, the constant-time comparisons implemented in the Go package crypto.subtle do indeed require, and have, similarly dire warnings about careful use as those from unsafe. The only remaining question, really, is if any bug can still survive in such an environment.

As far as I can tell, Go indeed implements constant time comparisons of hash values correctly. I haven't bothered to even look if complicated hashes involving S-boxes are calculated in a constant-time fashion---nobody bothered putting them into a package with names such as subtle and warnings about how easy it is to break things, so I'm actually doubtful.

What I did check is that elliptic curve cryptography is not implemented in a constant-time fashion in Go. Nobody even seems to have considered trying in the least---the implementation calls many arbitrary-length integer functions not even designed for cryptographic use, and indeed using non-constant-time algorithms. When this kind of timing side-channel was recently shown to also happen in OpenSSL on one architecture, it was good enough for a paper demonstrating private key compromise.

The same, continuing situation exists in Go, on all architectures. And, well, it doesn't really seem anyone cares about such details as actually working crypto; the focus is just on readability and speed (well, and working in the way that the casual user and some unit tests are fooled by it, I guess). After all, why would you even bother choosing a suitable algorithm when the language already keeps you safe from most ways of introducing buffer overflows, and when choosing a correct algorithm risks ruining Google's assertion that TLS has become computationally cheap? Sarcasm aside, making the language responsible for catching our bugs will just mean all those bugs the language cannot catch for us will still be there.

Finally, libraries like OpenSSL have the advantages that timely bugfixes are a reasonable possibility. Whilst in principle the same is true for Go packages, once something becomes part of Go's core, like the TLS package, it does become affected by the release schedule. Obviously that can interfere with timely deployment of bugfixes. I suppose Go-1.3, due this summer, will certainly not fix the ECC timing issue even if it were recognized as the critical issue it is, given the feature freeze.

I think I can answer this question for the specific case of a crypto library written in Go---it is easy, and not at all hypothetical, because there already is a standalone TLS package, crypto/tls in Go that does not depend on any outside library.

Whilst with regard to typical buffer overflows, idiomatic Go is much safer than traditional C, Go offers the keen developer plenty of options to sidestep it---such as imitating C's pointer arithmetic through Go's unsafe.pointer. One wonders if one could agree not to use fragile code in a critical piece of software.

Cryptography, of course, is exactly the kind of software using such fragile code, for good reasons. After all, the constant-time comparisons implemented in the Go package crypto.subtle do indeed require, and have, similarly dire warnings about careful use as those from unsafe. The only remaining question, really, is if any bug can still survive in such an environment.

As far as I can tell, Go indeed implements constant time comparisons of hash values correctly. I haven't bothered to even look if complicated hashes involving S-boxes are calculated in a constant-time fashion---nobody bothered putting them into a package with names such as subtle and warnings about how easy it is to break things, so I'm actually doubtful.

What I did check is that elliptic curve cryptography is not implemented in a constant-time fashion in Go. Nobody even seems to have considered trying in the least---the implementation calls many arbitrary-length integer functions not even designed for cryptographic use, and indeed using non-constant-time algorithms. When this kind of timing side-channel was recently shown to also happen in OpenSSL on one architecture, it was good enough for a paper demonstrating private key compromise.

The same, continuing situation exists in Go, on all architectures. And, well, it doesn't really seem anyone cares about such details as actually working crypto; the focus is just on readability and speed (well, and working in the way that the casual user and some unit tests are fooled by it, I guess). After all, why would you even bother choosing a suitable algorithm when the language already keeps you safe from most ways of introducing buffer overflows, and when choosing a correct algorithm risks ruining Google's assertion that TLS has become computationally cheap? Sarcasm aside, making the language responsible for catching our bugs will just mean all those bugs the language cannot catch for us will still be there.

Finally, libraries like OpenSSL have the advantages that timely bugfixes are a reasonable possibility. Whilst in principle the same is true for Go packages, once something becomes part of Go's core, like the TLS package, it does become affected by the release schedule. Obviously that can interfere with timely deployment of bugfixes. I suppose Go-1.3, due this summer, will certainly not fix the ECC timing issue even if it were recognized as the critical issue it is, given the feature freeze.

I think I can answer this question for the specific case of a crypto library written in Go---it is easy, and not at all hypothetical, because there essentially is a TLS package, crypto/tls that does not depend on an outside library in it already.

Whilst with regard to typical buffer overflows, idiomatic Go is much safer than traditional C, Go offers the keen developer plenty of options to sidestep it---such as imitating C's pointer arithmetic through Go's unsafe.pointer. One wonders if one could agree not to use fragile code in a crytical piece of software.

Cryptography, of course, is exactly the kind of software using such fragile code, for good reasons. After all, the constant-time comparisons implemented in the Go package crypto.subtle do indeed require, and have, similarly dire warnings about careful use as those from unsafe. The only remaining question, really, is if any bug can still survive in such an environment.

As far as I can tell, Go indeed implements constant time comparisons of hash values correctly. I haven't bothered to even look if complicated hashes involving S-boxes are calculated in a constant-time fashion---nobody bothered putting them into a package with names such as subtle and warnings about how easy it is to break things, so I'm actually doubtful.

What I did check is that elliptic curve cryptography is not implemented in a constant-time fashion in Go. Nobody even seems to have considered trying in the least---the implementation calls many arbitrary-length integer functions not even designed for cryptographic use, and indeed using non-constant-time algorithms. When this kind of timing side-channel was recently shown to also happen in OpenSSL on one architecture, it was good enough for a paper demonstrating private key compromise.

The same, continuing situation exists in Go, on all architectures. And, well, it doesn't really seem anyone cares about such details as actually working crypto; the focus is just on readability and speed (well, and working in the way that the casual user and some unit tests are fooled by it, I guess). After all, why would you even bother choosing a suitable algorithm when the language already keeps you safe from most ways of introducing buffer overflows, and when choosing a correct algorithm risks ruining Google's assertion that TLS has become computationally cheap? Sarcasm aside, making the language responsible for catching our bugs will just mean all those bugs the language cannot catch for us will still be there.

Finally, libraries like OpenSSL have the advantages that timely bugfixes are a reasonable possibility. Whilst in principle the same is true for Go packages, once something becomes part of Go's core, like the TLS package, it does become affected by the release schedule. Obviously that can interfere with timely deployment of bugfixes. I suppose Go-1.3, due this summer, will certainly not fix the ECC timing issue even if it were recognized as the critical issue it is, given the feature freeze.

I think I can answer this question for the specific case of a crypto library written in Go---it is easy, and not at all hypothetical, because there already is a standalone TLS package, crypto/tls in Go that does not depend on any outside library.

Whilst with regard to typical buffer overflows, idiomatic Go is much safer than traditional C, Go offers the keen developer plenty of options to sidestep it---such as imitating C's pointer arithmetic through Go's unsafe.pointer. One wonders if one could agree not to use fragile code in a crytical piece of software.

Cryptography, of course, is exactly the kind of software using such fragile code, for good reasons. After all, the constant-time comparisons implemented in the Go package crypto.subtle do indeed require, and have, similarly dire warnings about careful use as those from unsafe. The only remaining question, really, is if any bug can still survive in such an environment.

As far as I can tell, Go indeed implements constant time comparisons of hash values correctly. I haven't bothered to even look if complicated hashes involving S-boxes are calculated in a constant-time fashion---nobody bothered putting them into a package with names such as subtle and warnings about how easy it is to break things, so I'm actually doubtful.

What I did check is that elliptic curve cryptography is not implemented in a constant-time fashion in Go. Nobody even seems to have considered trying in the least---the implementation calls many arbitrary-length integer functions not even designed for cryptographic use, and indeed using non-constant-time algorithms. When this kind of timing side-channel was recently shown to also happen in OpenSSL on one architecture, it was good enough for a paper demonstrating private key compromise.

The same, continuing situation exists in Go, on all architectures. And, well, it doesn't really seem anyone cares about such details as actually working crypto; the focus is just on readability and speed (well, and working in the way that the casual user and some unit tests are fooled by it, I guess). After all, why would you even bother choosing a suitable algorithm when the language already keeps you safe from most ways of introducing buffer overflows, and when choosing a correct algorithm risks ruining Google's assertion that TLS has become computationally cheap? Sarcasm aside, making the language responsible for catching our bugs will just mean all those bugs the language cannot catch for us will still be there.

Finally, libraries like OpenSSL have the advantages that timely bugfixes are a reasonable possibility. Whilst in principle the same is true for Go packages, once something becomes part of Go's core, like the TLS package, it does become affected by the release schedule. Obviously that can interfere with timely deployment of bugfixes. I suppose Go-1.3, due this summer, will certainly not fix the ECC timing issue even if it were recognized as the critical issue it is, given the feature freeze.

I think I can answer this question for the specific case of a crypto library written in Go---it is easy, and not at all hypothetical, because there essentially is a TLS package that does not depend on an outside library in it already.

Whilst with regard to typical buffer overflows, idiomatic Go is much safer than trafitional C, Go offers the keen developer plenty of options to sidestep it---such as imitating C's pointer arithmetic through Go's unsafe.pointer. One wonders if one could agree not to use fragile code in a crytical piece of software.

Cryptography, of course, is exactly the kind of software using such fragile code, for good reasons. After all, the constant-time comparisons implemented in the Go package crypto.subtle do indeed require, and have, similarly dire warnings about careful use as those from unsafe. The only remaining question, really, is if any bug can still survive in such an environment.

As far as I can tell, Go indeed implements constant time comparisons of hash values correctly. I haven't bothered to even look if complicated hashes involving S-boxes are calculated in a constant-time fashion---nobody bothered putting them into a package with names such as subtle and warnings about how easy it is to break things, so I'm actually doubtful.

What I did check is that elliptic curve cryptography is not implemented in a constant-time fashion in Go. Nobody even seems to have considered trying in the least---the implementation calls many arbitrary-length integer functions not even designed for cryptographic use, and indeed using non-constant-time algorithms. When this kind of timing side-channel was recently shown to also happen in OpenSSL on one architecture, it was good enough for a paper demonstrating private key compromise.

The same, continuing situation exists in Go, on all architectures. And, well, it doesn't really seem anyone cares about such details as actually working crypto; the focus is just on readability and speed (well, and working in the way that the casual user and some unit tests are fooled by it, I guess). After all, why would you even bother choosing a suitable algorithm when the language already keeps you safe from most ways of introducing buffer overflows, and when choosing a correct algorithm risks ruining Google's assertion that TLS has become computationally cheap? Sarcasm aside, making the language responsible for catching our bugs will just mean all those bugs the language cannot catch for us will still be there.

Finally, libraries like OpenSSL have the advantages that timely bugfixes are a reasonable possibility. Whilst in principle the same is true for Go packages, once something becomes part of Go's core, like the TLS package, it does become affected by the one-new-version-about-every-6-month policy. Bugs may just have to wait their turn to fit the pre-determined release schedule. So Go-1.3, due this summer, will certainly not fix the ECC timing issue even if people started to care, given the feature freeze.

I think I can answer this question for the specific case of a crypto library written in Go---it is easy, and not at all hypothetical, because there essentially is a TLS package, crypto/tls that does not depend on an outside library in it already.

Whilst with regard to typical buffer overflows, idiomatic Go is much safer than traditional C, Go offers the keen developer plenty of options to sidestep it---such as imitating C's pointer arithmetic through Go's unsafe.pointer. One wonders if one could agree not to use fragile code in a crytical piece of software.

Cryptography, of course, is exactly the kind of software using such fragile code, for good reasons. After all, the constant-time comparisons implemented in the Go package crypto.subtle do indeed require, and have, similarly dire warnings about careful use as those from unsafe. The only remaining question, really, is if any bug can still survive in such an environment.

As far as I can tell, Go indeed implements constant time comparisons of hash values correctly. I haven't bothered to even look if complicated hashes involving S-boxes are calculated in a constant-time fashion---nobody bothered putting them into a package with names such as subtle and warnings about how easy it is to break things, so I'm actually doubtful.

What I did check is that elliptic curve cryptography is not implemented in a constant-time fashion in Go. Nobody even seems to have considered trying in the least---the implementation calls many arbitrary-length integer functions not even designed for cryptographic use, and indeed using non-constant-time algorithms. When this kind of timing side-channel was recently shown to also happen in OpenSSL on one architecture, it was good enough for a paper demonstrating private key compromise.

The same, continuing situation exists in Go, on all architectures. And, well, it doesn't really seem anyone cares about such details as actually working crypto; the focus is just on readability and speed (well, and working in the way that the casual user and some unit tests are fooled by it, I guess). After all, why would you even bother choosing a suitable algorithm when the language already keeps you safe from most ways of introducing buffer overflows, and when choosing a correct algorithm risks ruining Google's assertion that TLS has become computationally cheap? Sarcasm aside, making the language responsible for catching our bugs will just mean all those bugs the language cannot catch for us will still be there.

Finally, libraries like OpenSSL have the advantages that timely bugfixes are a reasonable possibility. Whilst in principle the same is true for Go packages, once something becomes part of Go's core, like the TLS package, it does become affected by the release schedule. Obviously that can interfere with timely deployment of bugfixes. I suppose Go-1.3, due this summer, will certainly not fix the ECC timing issue even if it were recognized as the critical issue it is, given the feature freeze.