Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Cross-Platform Cryptography document #1471

Open
wants to merge 17 commits into
base: microsoft/main
Choose a base branch
from
40 changes: 22 additions & 18 deletions eng/doc/CrossPlatformCryptography.md
Original file line number Diff line number Diff line change
@@ -1,15 +1,8 @@
# Cross-Platform Cryptography in Microsoft Go

Cryptographic operations in Microsoft Go are delegated to the operating system (OS) libraries. This dependency has advantages:
Cryptographic operations in Microsoft Go are delegated to the operating system (OS) libraries in some conditions.

* Go apps benefit from OS reliability. Keeping cryptography libraries safe from vulnerabilities is a high priority for OS vendors. To do that, they provide updates that system administrators should be applying.
* Go apps have access to FIPS-validated algorithms if the OS libraries are FIPS-validated.

> [!NOTE]
> Starting with Go 1.24, Go will also be FIPS 140-3 compliant, see https://github.com/golang/go/issues/69536.
> If the only reason you are using Microsoft Go is for FIPS 140-3 compliance, you should consider using Microsoft Go 1.24 or later.

Go apps will fall back to native Go implementations if the OS libraries doesn't support the algorithm.
Go apps will fall back to native Go implementations if the OS libraries don't support the algorithm.
This article identifies the features that are supported on each platform.

This article assumes you have a working familiarity with cryptography in Go.
Expand All @@ -20,19 +13,30 @@ Microsoft Go supports the following platforms:

### Windows

On Windows, Microsoft Go uses the [Cryptography API: Next Generation](https://learn.microsoft.com/en-us/windows/win32/seccng/cng-portal) library, CNG from now on, for cryptographic operations.
On Windows, Microsoft Go uses the [CNG library (Cryptography API: Next Generation)](https://learn.microsoft.com/en-us/windows/win32/seccng/cng-portal) for cryptographic operations.
CNG is available since Windows Vista and Windows Server 2008 and it doesn't require any additional installation nor configuration.

### Linux

On Linux, Microsoft Go uses the [OpenSSL crypto library](https://docs.openssl.org/3.0/man7/crypto/), OpenSSL from now on, for cryptographic operations.
On Linux, Microsoft Go uses the [OpenSSL crypto library](https://docs.openssl.org/3.0/man7/crypto/) for cryptographic operations.
OpenSSL is normally available on Linux distributions, but it may not be installed by default.
If it is not installed, you can install it using the package manager of your distribution.

OpenSSL 3 implements all the cryptographic algorithms using [Providers](https://docs.openssl.org/3.0/man7/crypto/#providers).
Microsoft Go officially supports the built-in providers and the [SymCrypt provider](https://github.com/microsoft/SymCrypt-OpenSSL), SCOSSL from now on.
The minimum SCOSSL version required is v1.6.1.
The following tables assume that the SCOSSL provider is used together with the built-in providers.
Microsoft Go officially supports the built-in providers and [SCOSSL (SymCrypt provider for OpenSSL)](https://github.com/microsoft/SymCrypt-OpenSSL) v1.6.1 or later.
SCOSSL is expected to be used with the default built-in provider enable as a fallback (which is the case when using [Azure Linux 3](https://github.com/microsoft/AzureLinux)).
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
SCOSSL is expected to be used with the default built-in provider enable as a fallback (which is the case when using [Azure Linux 3](https://github.com/microsoft/AzureLinux)).
SCOSSL is expected to be used with the default built-in provider enabled as a fallback (which is the case when using [Azure Linux 3](https://github.com/microsoft/AzureLinux)).


## Table legend

The following table legend is used to indicate the level of support for each cryptographic algorithm:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For some reason it seems odd to say a table uses a legend--they both use the same symbols, but the tables don't really "use" the legend directly, to me.

Suggested change
The following table legend is used to indicate the level of support for each cryptographic algorithm:
The following legend describes the symbols used in the tables to indicate the level of support for each cryptographic algorithm:


| Symbol | Meaning |
|--------|--------------------------------------------------------------------------------------------------------------------|
| ✔️ | Supported, possibly with minor limitations that don't require user action when using the latest Go and OS versions |
| ⚠️ | Supported with limitations that require user action |
Comment on lines +35 to +36
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the only time the doc mentions "user", and I think without a title like "FIPS 140-2 User Guide", it might be misinterpreted to mean that the dev's program will require some input from their end users. (Which doesn't make sense vs. a correct interpretation, but seems worth clarifying.)

Maybe the right fix is to actually update the intro to mention that this is a user guide for cryptography in Microsoft Go, to make "user" contextualized throughout the whole doc. (So maybe this can wait until this doc fully takes the place of the user guide.)

| ❌ | Not supported |

When an algorithm is not supported or the limitations are not met, Microsoft Go will fall back to the Go implementation.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
When an algorithm is not supported or the limitations are not met, Microsoft Go will fall back to the Go implementation.
When an algorithm is not supported or the limitations are exceeded, Microsoft Go will fall back to the Go implementation.


## Hash and Message Authentication Algorithms

Expand Down Expand Up @@ -69,7 +73,7 @@ This section includes the following packages:

<sup>2</sup>Requires OpenSSL 1.1.1 or later.

<sup>3</sup>The supported hash algorithms are the same as the ones supported as standalone hash functions.
<sup>3</sup>Supports only hash algorithms that are supported as standalone hash functions.

## Symmetric encryption

Expand Down Expand Up @@ -181,7 +185,7 @@ This section includes the following packages:

#### Random number generation

For those operations that require random numbers, only the [rand.Reader](https://pkg.go.dev/crypto/rand#Reader) is supported.
Operations that require random numbers (rand io.Reader) only support [rand.Reader](https://pkg.go.dev/crypto/rand#Reader).

### ECDH

Expand Down Expand Up @@ -248,8 +252,8 @@ This section includes the following packages:

| Parameters | Windows | Linux |
|---------------|-------------|--------------|
|768 | ❌ | ❌ |
|1024 | ❌ | ❌ |
| 768 | ❌ | ❌ |
| 1024 | ❌ | ❌ |

## TLS

Expand Down
Loading