Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Microsoft Maintains Go Fork for FIPS 140-2 Support

github.com

Post reply on HN
Print view View original

11–20 of 21 posts

Re: Microsoft Maintains Go Fork for FIPS 140-2 Support

#11

Post by bitwize »

purpleidea wrote: post #6

If this doesn't also _add_ some "accidental" backdoor, I'd be surprised. Microsoft's security reputation is so flawed, that some parts simply must be intentional, or coerced. Don't use this repo. Very interesting TIL about golang at Microsoft. Thanks for sharing.

Jonathan Blow ranted about the susceptibility of open source to supply chain attacks from state actors, which discussion recently became germane again in light of the xz backdoor.

What he didn't discuss was how vulnerable proprietary vendors (including, but by no means limited to, Microsoft) are to "rubber-hose vulnerability injection".

Anyway, it's good to see Microsoft actually participating in the open source process.

Re: Microsoft Maintains Go Fork for FIPS 140-2 Support

#12

Post by SAI_Peregrinus »

tptacek wrote: post #7
purpleidea wrote: post #6

If this doesn't also _add_ some "accidental" backdoor, I'd be surprised. Microsoft's security reputation is so flawed, that some parts simply must be intentional, or coerced. Don't use this repo. Very interesting TIL about golang at Microsoft. Thanks for sharing.

It's built from source. You can just diff it. Of course, you don't have to, because they provide the patches. Don't use any FIPS branch of any platform, because FIPS is terrible. But the argument presented here seems facile.

FIPS is terrible, except that sometimes if you shout "FIPS 140 compliance for US gov contracts" enough into the corporate hierarchy you eventually get the budget to implement any security whatsoever, even though it's just FIPS.

If you're not trying to get US government contracts that require it, don't bother with FIPS. It mandates older algorithms; they're mostly secure enough but not as performant and there are a lot more footguns. FIPS 140-3 fixed a few, but not all.

Re: Microsoft Maintains Go Fork for FIPS 140-2 Support

#13

Post by gct »

metadat wrote: post #5

There used to be the GO FIPS branch: https://github.com/golang/go/tree/dev.boringcrypto/misc/bori... But it looks dead for some time. However https://github.com/golang-fips/go sprung up to take it's place. I wonder why microsoft prefers to maintain it's own in entirety rather than share a piece of the burden.

EEE

Re: Microsoft Maintains Go Fork for FIPS 140-2 Support

#14

Post by korginator »

You would be interested in this if you need the 'crypto' library to work in a FIPS 140-2 compliant way. You can switch on / off this mode by setting the runtime variable GOFIPS=1 before running your Go program [1]. Nice.

It looks like the Go community officially has no plans to support FIPS140-2 any time, so I'm glad to see this alternative.

[1] https://github.com/microsoft/go/tree/microsoft/main/eng/doc/...

Re: Microsoft Maintains Go Fork for FIPS 140-2 Support

#15

Post by YZF »

interroboink wrote: post #3

Does anyone with FIPS experience know what sort of changes are entailed by those requirements? This repo doesn't seem to list what sort of high-level/conceptual changes are involved. I could look at the diff, but that sounds exhausting :Þ

The general theme is that you need to be using approved ciphers and you need to have your key management code certified by some external entity. It is an exhausting process ;)

Re: Microsoft Maintains Go Fork for FIPS 140-2 Support

#16

Post by metadat »

gct wrote: post #13
metadat wrote: post #5

There used to be the GO FIPS branch: https://github.com/golang/go/tree/dev.boringcrypto/misc/bori... But it looks dead for some time. However https://github.com/golang-fips/go sprung up to take it's place. I wonder why microsoft prefers to maintain it's own in entirety rather than share a piece of the burden.

EEE

What?

Re: Microsoft Maintains Go Fork for FIPS 140-2 Support

#17

Post by camkego »

metadat wrote: post #16
gct wrote: post #13

Earlier quoted context omitted.

EEE

What?

From Wikipedia: https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis...

"Embrace, extend, and extinguish" (EEE),[1] also known as "embrace, extend, and exterminate",[2] is a phrase that the U.S. Department of Justice found[3] was used internally by Microsoft[4] to describe its strategy for entering product categories involving widely used open standards, extending those standards with proprietary capabilities, and using the differences to strongly disadvantage its competitors.

Please see the Wiki article for the full deal including footnotes.

Re: Microsoft Maintains Go Fork for FIPS 140-2 Support

#18

Post by cosmotic »

gct wrote: post #13
metadat wrote: post #5

There used to be the GO FIPS branch: https://github.com/golang/go/tree/dev.boringcrypto/misc/bori... But it looks dead for some time. However https://github.com/golang-fips/go sprung up to take it's place. I wonder why microsoft prefers to maintain it's own in entirety rather than share a piece of the burden.

EEE

It's not fair to say EEE in response to every apparently good thing Microsoft does.

Re: Microsoft Maintains Go Fork for FIPS 140-2 Support

#19

Post by dadrian »

SAI_Peregrinus wrote: post #12
tptacek wrote: post #7

Earlier quoted context omitted.

It's built from source. You can just diff it. Of course, you don't have to, because they provide the patches. Don't use any FIPS branch of any platform, because FIPS is terrible. But the argument presented here seems facile.

FIPS is terrible, except that sometimes if you shout "FIPS 140 compliance for US gov contracts" enough into the corporate hierarchy you eventually get the budget to implement any security whatsoever, even though it's just FIPS . If you're not trying to get US government contracts that require it, don't bother with FIPS. It mandates older algorithms; they're mostly secure enough but not as performant and there are a l…

There's a difference between FIPS approved algorithms, which are actually pretty broad and well-selected these days, and FIPS validated implementations, which are at best a PITA and often actively harmful. Very rarely do you actually need a FIPS-validated implementation.
Post reply on HN