Oh no, you're thinking, yet another cookie pop-up. Well, sorry, it's the law. We measure how many people read us, and ensure you see relevant ads, by storing cookies on your device. If you're cool with that, hit “Accept all Cookies”. For more info and to customize your settings, hit “Customize Settings”.

Review and manage your consent

Here's an overview of our use of cookies, similar technologies and how to manage them. You can also change your choices at any time, by hitting the “Your Consent Options” link on the site's footer.

Manage Cookie Preferences
  • These cookies are strictly necessary so that you can navigate the site as normal and use all features. Without these cookies we cannot provide you with the service that you expect.

  • These cookies are used to make advertising messages more relevant to you. They perform functions like preventing the same ad from continuously reappearing, ensuring that ads are properly displayed for advertisers, and in some cases selecting advertisements that are based on your interests.

  • These cookies collect information in aggregate form to help us understand how our websites are being used. They allow us to count visits and traffic sources so that we can measure and improve the performance of our sites. If people say no to these cookies, we do not know how many people have visited and we cannot monitor performance.

See also our Cookie policy and Privacy policy.

This article is more than 1 year old

Devs working to stop Go math error bugging crypto software

Programming language makes some fuzzy big numbers

Consider this an item for the watch-list, rather than a reason to hit the panic button: a math error in the Go language could potentially affect cryptographic libraries.

Security researcher Guido Vranken (who earlier this year fuzzed up some bugs in OpenVPN) found an exponentiation error in the Go math/big package.

Big numbers - particularly big primes - are the foundation of cryptography.

Vranken posted to the oss-sec mailing list that he found the potential issue during testing of a fuzzer he wrote that "compares the results of mathematical operations (addition, subtraction, multiplication, ...) across multiple bignum libraries”.

Vranken and Go developer Russ Cox agreed that the bug needs specific conditions to be manifest: “it only affects the case e = 1 with m != nil and a pre-allocated non-zero receiver.”

That's expanded in the post, by way of explanation: “For an exponent of 1, big.Int.Exp returns the correct value only for a 0 recipient, and an off-by-one result for all pre-allocated recipients.”

Readers can see the proof-of-concept in operation at the Go Playground here.

In Vranken's GitHub post, Cox commented:

“Most crypto code uses new(big.Int).Exp(x, y, m) instead of reusing receivers. Most crypto code is also written so that a modular exponentiation with an exponent of 1 is either completely impossible or exceedingly unlikely. We examined all the uses in the standard library and believe they are unaffected, for either the first or the second reason.”

He added that x/crypto, openpgp, and ssh are fine because they only use new(big.Int).Exp, but other packages like x/crypt/otr (an implementation in Go of the Off-The-Record messaging protocol) may need closer examination.

Vranken's big number fuzzer is here. ®

Similar topics

TIP US OFF

Send us news


Other stories you might like