4 ms·

Note that you probably need to revoke your key if you used it on a 32-bit system and published anywhere close to 64M results. Busy SSL terminators or e.g. OAUTH

Note that you probably need to revoke your key if you used it on a 32-bit system and published anywhere close to 64M results. Busy SSL terminators or e.g. OAUTH signers might want to take note. I'm surprised to learn that Go did not already check the result of calculations; that's a pretty standard countermeasure, also to e.g. protect your private key on somewhat-unreliable hardware.

tptacek 11y ago
Not really surprising. This is a common bug, and people are looking for it much more aggressively over the last year. Even Nacl had one of these bugs! There was a carry propagation bug in OpenSSL/BoringSSL/LibreSSL just a few weeks ago.
- parfe 11y ago
  Are you rerferring to CVE-2015-3193? I believe it did not affect libressl
- hannob 11y ago
  The surprising thing is not the bug, it's that go didn't verify the result of the CRT calculation. That's a standard countermeasure (although not present everywhere, Florian Weimer recently did some work on patching implementations that were lacking this check). And nit: The OpenSSL bug didn't affect libressl (I discovered it, I checked for that).
  - tptacek 11y ago
    I stand corrected! Sorry about that.
  - ancarda 11y ago
    How do bugs that affect OpenSSL not affect LibreSSL? Surely any bugs that were fixed in LibreSSL would have been shared with OpenSSL, right? Or is it legacy code that was removed during the Valhalla cleanup?
    - hannob 11y ago
      The bug was introduced with an assembly optimization that got added to OpenSSL after LibreSSL forked the codebase.
    - deleted 11y ago
      [deleted]
    - masklinn 11y ago
      > Surely any bugs that were fixed in LibreSSL would have been shared with OpenSSL, right? Or is it legacy code that was removed during the Valhalla cleanup? hannob gave the reason, but bug could also be unwittingly removed by separate cleanup e.g. generic replacement of unsafe functions/practices by safer ones.
FiloSottile 11y ago
> I'm surprised to learn that Go did not already check the result of calculations Yeah. As the announcement says, it's coming in 1.6 and we (CloudFlare) backported it in our public tree, in case anyone else wants to use it: https://github.com/cloudflare/go/commits/go1.5.3-cloudflare1 https://github.com/cloudflare/go/commits/go1.5.3-cloudflare1
- rsc 11y ago
  There are tradeoffs here. I believe the reason for the omission originally was concerns along these lines: http://www.openwall.com/lists/oss-security/2014/07/10/5 http://www.openwall.com/lists/oss-security/2014/07/10/5
  - JoachimSchipper 11y ago
    Your link - which is interesting - concerns sanity check on private keys. I agree that such checks need to be implemented very carefully, since they handle highly-sensitive data. However, I was proposing verifying the signature - which involves only the public key and the signed data, neither of which are likely to be all that sensitive. (The situation is more subtle for RSA decryption.)

tptacek 11y ago

Not really surprising. This is a common bug, and people are looking for it much more aggressively over the last year. Even Nacl had one of these bugs! There was a carry propagation bug in OpenSSL/BoringSSL/LibreSSL just a few weeks ago.

parfe 11y ago
Are you rerferring to CVE-2015-3193? I believe it did not affect libressl
hannob 11y ago
The surprising thing is not the bug, it's that go didn't verify the result of the CRT calculation. That's a standard countermeasure (although not present everywhere, Florian Weimer recently did some work on patching implementations that were lacking this check). And nit: The OpenSSL bug didn't affect libressl (I discovered it, I checked for that).
- tptacek 11y ago
  I stand corrected! Sorry about that.
- ancarda 11y ago
  How do bugs that affect OpenSSL not affect LibreSSL? Surely any bugs that were fixed in LibreSSL would have been shared with OpenSSL, right? Or is it legacy code that was removed during the Valhalla cleanup?
  - hannob 11y ago
    The bug was introduced with an assembly optimization that got added to OpenSSL after LibreSSL forked the codebase.
  - deleted 11y ago
    [deleted]
  - masklinn 11y ago
    > Surely any bugs that were fixed in LibreSSL would have been shared with OpenSSL, right? Or is it legacy code that was removed during the Valhalla cleanup? hannob gave the reason, but bug could also be unwittingly removed by separate cleanup e.g. generic replacement of unsafe functions/practices by safer ones.

FiloSottile 11y ago

> I'm surprised to learn that Go did not already check the result of calculations Yeah. As the announcement says, it's coming in 1.6 and we (CloudFlare) backported it in our public tree, in case anyone else wants to use it: https://github.com/cloudflare/go/commits/go1.5.3-cloudflare1 https://github.com/cloudflare/go/commits/go1.5.3-cloudflare1

rsc 11y ago
There are tradeoffs here. I believe the reason for the omission originally was concerns along these lines: http://www.openwall.com/lists/oss-security/2014/07/10/5 http://www.openwall.com/lists/oss-security/2014/07/10/5
- JoachimSchipper 11y ago
  Your link - which is interesting - concerns sanity check on private keys. I agree that such checks need to be implemented very carefully, since they handle highly-sensitive data. However, I was proposing verifying the signature - which involves only the public key and the signed data, neither of which are likely to be all that sensitive. (The situation is more subtle for RSA decryption.)