Add CNG crypto backend

[qmuntal]

This PR integrates https://github.com/microsoft/go-crypto-winnative as a Go backend.

Tips for the reviewers:

• The first commit is just adding the CNG backend as if it was 100% compatible with Go crypto. You can review this fast because it is the same as we already did for openssl and boring.
• The second commit adds a new CI job that builds and test Go using goexperiment=cngcrypto.
• The third commit is the important one. It contains all the hacks and fallbacks I had to do to fit CNG into Go.

As agreed, we will fallback to Go crypto when CNG does not implement an algorithm or a parameter required by Go. The complete list can be found at microsoft/go-crypto-winnative#4.

⚠️ I have not implemented a fallback for unsupported RSA key lengths. This is a special case, as CNG might want to restrict even more the supported key lengths based on the configured security provider or when running in FIPS mode. If we fallback to Go crypto in such case, we would be bypassing an important security policy.

I'll add an exhaustive documentation of what to expect and how to use CNG backend once this PR lands.

@dagood @jaredpar @chsienki how does goexperiment=cngcrypto resonates to you? People will understand that cngcrypto is the CNG Windows backend? Alternatives?

Closes #476

[dagood]

how does goexperiment=cngcrypto resonates to you? People will understand that cngcrypto is the CNG Windows backend? Alternatives?

I think it works--it parallels nicely with boringcrypto and opensslcrypto being named after the native library they use rather than the platform. Anyone who wants to use the mode should be looking in our docs and understand it fine from there. And even if someone sees it in the wild and doesn't understand, I was able to plop cngcrypto into a few search engines and see the Microsoft CNG docs at or near the top.

[jaredpar]

I like cngcrypto

I was able to plop cngcrypto into a few search engines and see the Microsoft CNG docs at or near the top.

This makes me like it more 😄

[dagood]

Here's what I was mentioning in the Go sync--the inversion:

 (!goexperiment.CNGCrypto || (len(priv.Primes) == 2 && hash != crypto.MD5SHA1))
!( goexperiment.CNGCrypto && (len(priv.Primes) != 2 || hash == crypto.MD5SHA1))

I think of the right side as a list of unsupported/fallback cases and it's quite a bit easier to read as positives rather than negatives:

• len(priv.Primes) == 2 && hash != crypto.MD5SHA1) "does every unsupported case not match"
• len(priv.Primes) != 2 || hash == crypto.MD5SHA1) "does any unsupported case match"

Maybe it's just me. I can certainly figure it out either way, so I'm happy to go with whatever makes the most sense for anyone else. 😄

[qmuntal]

Done! 0236a2e

[dagood]

LGTM, just a comment/doc suggestion and a question.

[dagood]

I think it's worth elaborating a bit here... my understanding from poking around is that this is because CNGCrypto has more fallbacks than boring/openssl, and I think this is saying that there are enough extra fallbacks that if we were to remove boring.Unreachable() from each of those code paths, Unreachable becomes useless. Is that right?

I assume it's also not worthwhile to make backend-specific Unreachable calls, so they can be tailored to the fallbacks necessary for each backend?

[qmuntal]

I give it another thought, and it was easier than expected to make backend-specific Unreachable calls:
358a6e6.