-
Import and Export RSA Key Formats in .NET Core 3
.NET Core 3.0 introduced over a dozen new APIs for importing and exporting RSA keys in different formats. Many of them are a variant of another with a slightly different API, but they are extremely useful for working with private and public keys from other systems that work with encoding keys.
RSA keys can be encoded in a variety of different ways, depending on if the key is public or private or protected with a password. Different programs will import or export RSA keys in a different format, etc.
Often times RSA keys can be described as “PEM” encoded, but that is already ambiguous as to how the key is actually encoded. PEM takes the form of:
-----BEGIN LABEL----- content -----END LABEL-----
The content between the labels is base64 encoded. The one that is probably the most often seen is BEGIN RSA PRIVATE KEY, which is frequently used in web servers like nginx, apache, etc:
-----BEGIN RSA PRIVATE KEY----- MII... -----END RSA PRIVATE KEY-----
The base64-encoded text is an RSAPrivateKey from the PKCS#1 spec, which is just an ASN.1 SEQUENCE of integers that make up the RSA key. The corresponding .NET Core 3 API for this is
ImportRSAPrivateKey
, or one of its overloads. If your key is “PEM” encoded, you need to find the base64 text between the label BEGIN and END headers, base64 decode it, and pass toImportRSAPrivateKey
. There is currently an API proposal to make reading PEM files easier. If your private key is DER encoded, then that just means you can read the content directly as bytes in toImportRSAPrivateKey
.Here is an example:
var privateKey = "MII..."; //Get just the base64 content. var privateKeyBytes = Convert.FromBase64String(privateKey); using var rsa = RSA.Create(); rsa.ImportRSAPrivateKey(privateKeyBytes, out _);
When using openssl, the
openssl rsa
commands typically output RSAPrivateKey PKCS#1 private keys, for exampleopenssl genrsa
.A different format for a private key is PKCS#8. Unlike the RSAPrivateKey from PKCS#1, a PKCS#8 encoded key can represent other kinds of keys than RSA. As such, the PEM label for a PKCS#8 key is “BEGIN PRIVATE KEY” (note the lack of “RSA” there). The key itself contains an AlgorithmIdentifer of what kind of key it is.
PKCS#8 keys can also be encrypted protected, too. In that case, the PEM label will be “BEGIN ENCRYPTED PRIVATE KEY”.
.NET Core 3 has APIs for both of these. Unencrypted PKCS#8 keys can be imported with
ImportPkcs8PrivateKey
, and encrypted PKCS#8 keys can be imported withImportEncryptedPkcs8PrivateKey
. Their usage is similar toImportRSAPrivateKey
.Public keys have similar behavior. A PEM encoded key that has the label “BEGIN RSA PUBLIC KEY” should use
ImportRSAPublicKey
. Also like private keys, the public key has a format that self-describes the algorithm of the key called a Subject Public Key Info (SPKI) which is used heavily in X509 and many other standards. The PEM header for this is “BEGIN PUBLIC KEY”, andImportSubjectPublicKeyInfo
is the correct way to import these.All of these APIs have export versions of themselves as well, so if you are trying to export a key from .NET Core 3 to a particular format, you’ll need to use the correct export API.
To summarize each PEM label and API pairing:
- “BEGIN RSA PRIVATE KEY” =>
RSA.ImportRSAPrivateKey
- “BEGIN PRIVATE KEY” =>
RSA.ImportPkcs8PrivateKey
- “BEGIN ENCRYPTED PRIVATE KEY” =>
RSA.ImportEncryptedPkcs8PrivateKey
- “BEGIN RSA PUBLIC KEY” =>
RSA.ImportRSAPublicKey
- “BEGIN PUBLIC KEY” =>
RSA.ImportSubjectPublicKeyInfo
One gotcha with openssl is to pay attention to the output of the key format. A common enough task from openssl is “Given this PEM-encoded RSA private key, give me a PEM encoded public-key” and is often enough done like this:
openssl rsa -in key.pem -pubout
Even if key.pem is a PKCS#1 RSAPrivateKey (“BEGIN RSA PRIVATE KEY”), the
-pubout
option will output a SPKI (“BEGIN PUBLIC KEY”), not an RSAPublicKey (“BEGIN RSA PUBLIC KEY”). For that, you would need to use-RSAPublicKey_out
instead of-pubout
. The opensslpkey
commands will also typically give you PKCS#8 or SPKI formatted keys. - “BEGIN RSA PRIVATE KEY” =>
-
Sometimes valid RSA signatures in .NET
One of the nice things about .NET Core being open source is following along with some of the issues that people report. I tend to keep an eye on System.Security tagged issues, since those tend to be at the intersection of things that interest me and things I can maybe help with.
A user filed an issue where .NET Framework considered a CMS valid, and .NET Core did not. This didn’t entirely surprise me. In the .NET Framework, the
SignedCms
class is heavily backed by Windows’ handling of CMS/PKCS#7. In .NET Core, the implementation is managed (sans the cryptography). The managed implementation adheres somewhat strictly to the CMS specification. As other issues have noticed, Windows’, thus .NET Framework’s, implementation was a little more relaxed in some ways.This turned out not to be one of those cases. The CMS part was actually working just fine. What was failing was RSA itself. The core of the issue was that different implementations of RSA disagreed on the RSA signature’s validity.
That seems pretty strange!
When I talk about different implementations on Windows, I am usually referring to CAPI vs CNG, or
RSACryptoServiceProvider
andRSACng
, respectively. For now, I’m keeping this post to the .NET Framework. We’ll bring .NET Core in to the discussion later.There are two implementations because, well, Windows has two of them. CNG, or “Cryptography API: Next Generation” is the newer of the two and is intended to be future of cryptographic primitives on Windows. It shipped in Windows Vista, and offers functionality that CAPI cannot do. An example of that is PSS RSA signatures.
.NET Framework exposes these implementations as
RSACryptoServiceProvider
andRSACng
. They should be interchangable, and CNG implementations should be used going forward. However, there is one corner case where the old, CAPI implementation considers a signature valid while the CNG one does not.The issue can be demonstrated like so:
byte[] n = new byte[] { ... }; byte[] e = new byte[] { ... }; byte[] signature = new byte[] { ... }; var digest = new byte[] { 0x68, 0xB4, 0xF9, 0x26, 0x34, 0x31, 0x25, 0xDD, 0x26, 0x50, 0x13, 0x68, 0xC1, 0x99, 0x26, 0x71, 0x19, 0xA2, 0xDE, 0x81, }; using (var rsa = new RSACng()) { rsa.ImportParameters(new RSAParameters { Modulus = n, Exponent = e }); var valid = rsa.VerifyHash(digest, signature, HashAlgorithmName.SHA1, RSASignaturePadding.Pkcs1); Console.WriteLine(valid); } using (var rsa = new RSACryptoServiceProvider()) { rsa.ImportParameters(new RSAParameters { Modulus = n, Exponent = e }); var valid = rsa.VerifyHash(digest, signature, HashAlgorithmName.SHA1, RSASignaturePadding.Pkcs1); Console.WriteLine(valid); }
When used with one of the curious signatures that exhibits this behavior, such as the one in the GitHub link, the first result will be false, and the second will be true.
Nothing jumped out at me as being problematic. The signature padding is PKCS, the public exponent is the very typical 67,537, and the RSA key is sensible in size.
To make it stranger, this signature came off the timestamp of Firefox’s own signed installer. So why are the results different?
Jeremy Barton from Microsoft on .NET Core made the observation that the padding in the RSA signature itself is incorrect, but in a way that CAPI tollerates and CNG does not, at least by default. Let’s look at the raw signature. To do that, we need the public key and signature on disk, and we can poke at them with OpenSSL.
Using the command:
openssl rsautl -verify -in sig.bin -inkey key.der \ -pubin -hexdump -raw -keyform der
We get the following output:
0000 - 00 01 ff ff ff ff ff ff-ff ff ff ff ff ff ff ff 0010 - ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff 0020 - ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff 0030 - ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff 0040 - ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff 0050 - ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff 0060 - ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff 0070 - ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff 0080 - ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff 0090 - ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff 00a0 - ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff 00b0 - ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff 00c0 - ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff 00d0 - ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff 00e0 - ff ff ff ff ff ff ff ff-ff ff ff 00 68 b4 f9 26 00f0 - 34 31 25 dd 26 50 13 68-c1 99 26 71 19 a2 de 81
This is a PKCS#1 v1.5 padded signature, as indicated by by starting with 00 01. The digest at the end can be seen,
68 b4 f9 26 ... 19 a2 de 81
which matches the digest above, so we know that the signature is for the right digest.What is not correct in this signature is how the digest is encoded. The signature contains the bare digest. It should be encoded as an ASN.1 sequence along with the AlgorithmIdentifer of the digest:
DigestInfo ::= SEQUENCE { digestAlgorithm AlgorithmIdentifier, digest OCTET STRING }
This goes back all the way to a document (warning: link is to an ftp:// site) written in 1993 by RSA labratories explaining how PKCS#1 v1.5 works,and was standardized in to an RFC in 1998.
The RSA signature we have only contains the raw digest. It is not part of a
DigestInfo
. If the digest were properly encoded, it would look something like this:0000 - 00 01 ff ff ff ff ff ff-ff ff ff ff ff ff ff ff 0010 - ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff 0020 - ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff 0030 - ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff 0040 - ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff 0050 - ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff 0060 - ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff 0070 - ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff 0080 - ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff 0090 - ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff 00a0 - ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff 00b0 - ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff 00c0 - ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff 00d0 - ff ff ff ff ff ff ff ff-ff ff ff ff 00 30 21 30 00e0 - 09 06 05 2b 0e 03 02 1a-05 00 04 14 68 b4 f9 26 00f0 - 34 31 25 dd 26 50 13 68-c1 99 26 71 19 a2 de 81
The signature now includes
DigestInfo
along with the OID 1.3.14.3.2.26 to indicate that the digest is SHA1.At this point we know what the difference is, and the original specification in part 10.1.2 makes it fairly clear that the “data” should be a digest and should be encoded as DigestInfo, not a bare digest.
The source of this signature is from Verisign's timestamp authority at http://timestamp.verisign.com/scripts/timstamp.dll. After checking with someone at DigiCert (now running this TSA), it was launched in May 1995.
I suspect that the TSA is old enough that the implementation was made before the specification was complete or simply got the specification wrong and no one noticed. Bringing this back to CNG and CAPI, CNG can validate this signatures, but you must explicitly tell CNG that the signature does not have an object identifier.
BCRYPT_PKCS1_PADDING_INFO
’s documentation has the detail there, but gist of it isIf there is no OID in the signature, then verification fails unless this member is NULL.
This would be used with
{B,N}CryptVerifySignature
. To bring this back around to the .NET Framework, how do we useRSACng
and givenull
in for the padding algorithm? The short answer is: you cannot. If you try, you will get an explicitArgumentException
saying that the hash algorithm name cannot be null.For .NET Framework, this solution “keep using
RSACryptoServiceProvider
”. If you need to validate these signatures, chances are you do not need to use CNG’s newer capabilities like PSS since these malformed signatures appear to be coming from old systems. Higher level things likeSignedCms
andSignedXml
useRSACryptoServiceProvider
by default, so they will continue to work.To bring in .NET Core, the situation is a little more difficult. If you are using
SignedCms
like so:var signedCms = new SignedCms(); signedCms.Decode(File.ReadAllBytes("cms-with-sig.bin")); signedCms.CheckSignature(true);
This will start throwing when you migrate to .NET Core. .NET Core will use CNG when run on Windows to validate RSA signatures for
SignedCms
andSignedXml
. This is currently not configurable, either. When used withSignedCms
, it ultimately calls theX509Certificate2.GetRSAPublicKey()
extension method, and that will always return an implementation based on CNG.If you are using
SignedCms
on .NET Core and need to validate a CMS that is signed with these problematic signatures, you are currently out of luck using in-the-box components. As far as other platforms go, both macOS and Linux environments for .NET Core will agree with CNG - that the signature is invalid.The good news is, these signatures are not easy to come by. So far, only the old Verisign timestamp authority is known to have produced signatures like this.
-
C# ReadOnlySpan
and static data Since C# 7 there have been a lot of point releases that contain all kinds of goodies. Many of them are performance focused, such as safe stack allocations using
Span<T>
, or interoperability with improvements tofixed
.One that I love, but is not documented well, is some special treatment that
ReadOnlySpan<byte>
gets when its contents are known at compile time.Here’s an example of a lookup table I used to aide with hex encoding that uses a
byte[]
:private static byte[] LookupTable => new byte[] { (byte)'0', (byte)'1', (byte)'2', (byte)'3', (byte)'4', (byte)'5', (byte)'6', (byte)'7', (byte)'8', (byte)'9', (byte)'A', (byte)'B', (byte)'C', (byte)'D', (byte)'E', (byte)'F', };
This binary data has to get stored somewhere in our produced library. If we use
dumpbin
we can see it in the .text section of the binary.dumpbin /RAWDATA /SECTION:.text mylib.dll
Right at the bottom, we see:
00402A40: 30 31 32 33 34 35 36 37 38 39 41 42 43 44 45 46 0123456789ABCDEF
I won’t go into the a lot of the details on how this data is compiled into the
.text
section, but at this point we need to get that data into the array somehow.If we look at the jit assembly of
LookupTable
, we see:sub rsp, 0x28 vzeroupper mov rcx, 0x7ffc4638746a mov edx, 0x10 call 0x7ffc49b52630 mov rdx, 0x1b51450099c lea rcx, [rax+0x10] vmovdqu xmm0, [rdx] vmovdqu [rcx], xmm0 add rsp, 0x28 ret
Where
0x7ffc49b52630
isInitializeArray
.With an array, our property leans on
InitializeArray
, the source of which is in the CoreCLR. For little-endian platforms, it boils down to amemcpy
from a runtime field handle.Indeed, with a debugger we finally see:
00007ffd`b18b701a e831a40e00 call coreclr!memcpy (00007ffd`b19a1450)
Dumping
@rdx L10
yields:000001f0`4c552a90 30 31 32 33 34 35 36 37-38 39 41 42 43 44 45 46 0123456789ABCDEF
So that was a very long-winded way of saying that when using arrays, initializing a field or variable with bytes results in
memcpy
from the image into the array, which results in more data on the heap.Now, starting in 7.3, we can avoid that
memcpy
when usingReadOnlySpan<byte>
.private static ReadOnlySpan<byte> LookupTable => new byte[] { (byte)'0', (byte)'1', (byte)'2', (byte)'3', (byte)'4', (byte)'5', (byte)'6', (byte)'7', (byte)'8', (byte)'9', (byte)'A', (byte)'B', (byte)'C', (byte)'D', (byte)'E', (byte)'F', };
Looking at the jit assembly:
mov eax, 0x10 xor edx, edx mov r8, 0x1b5144c0968 mov [rcx], rdx mov [rcx+0x8], r8 mov [rcx+0x10], eax mov rax, rcx ret
We see that there is
mov r8, 0x1b5144c0968
. The contents of0x1b5144c0968
are:000001b5`144c0968 30 31 32 33 34 35 36 37-38 39 41 42 43 44 45 46 0123456789ABCDEF
So we see that the method is now returning the data directly and omitting the
memcpy
entirely, so ourReadOnlySpan<byte>
is pointing directly to the.text
section.This works for property getters as shown above, but also as the return of a method:
ReadOnlySpan<byte> GetBytes() { return new byte[] { ... }; }
Which works similar to the getter of the property. In addition, this also works for locals in a method body as well:
void Write200Ok(Stream s) { ReadOnlySpan<byte> data = new byte[] { (byte)'H', (byte)'T', (byte)'T', (byte)'P', (byte)'/', (byte)'1', (byte)'.', (byte)'1', (byte)' ', (byte)'2', (byte)'0', (byte)'0', (byte)' ', (byte)'O', (byte)'K' }; s.Write(data); }
Which also produces a reasonable JIT disassembly:
sub rsp, 0x38 xor eax, eax mov qword ptr [rsp+0x28], rax mov qword ptr [rsp+0x30], rax mov rcx, 0x1e595b42ade mov eax, 0x0F lea r8, [rsp+0x28] mov qword ptr [r8], rcx mov dword ptr [r8+8], eax mov rcx, rdx lea rdx, [rsp+0x28] cmp dword ptr [rcx], ecx call 0x7ff89ede10c8 (Stream.Write(System.ReadOnlySpan`1<Byte>), mdToken: 0000000006000001) add rsp, 0x38 ret
Here we see
mov rcx, 0x1e595b42ade
which moves the address of the static data directly in to the register with no additional work to create a byte array.These optimizations currently only works with
ReadOnlySpan<byte>
right now. Other types will continue to useInitializeArray
due to needing to handle different platforms and how they handle endianness. -
C# 8 using declarations
Visual Studio 2019 preview 2 was released a few days ago and I took the time to install it. Visual Studio itself is actually rather uninteresting to me, however the inclusion of the next C# 8 preview got my attention. I glanced at the feature highlights and posted “looks nice” on Twitter.
Predictably, I got a few responses like “I’m not sure I like that”, and there is always a guarantee that if F# has a similar feature, an F# developer will appear and tell you F# has had this feature for 600 years.
The one I like a lot is using declarations. This allows a local to automatically be disposed at the end of the block. Essentially, it hides the
try
/finally
or theusing() {...}
. The .NET team’s blog kind of gave a bad example of this, so I’ll use one from Open OPC SignTool. Here is the original snippet:private static X509Certificate2 GetCertificateFromCertificateStore(string sha1) { using (var store = new X509Store(StoreName.My, StoreLocation.LocalMachine)) { store.Open(OpenFlags.OpenExistingOnly | OpenFlags.ReadOnly); var certificates = store.Certificates.Find(X509FindType.FindByThumbprint, sha1, false); return certificates.Count > 0 ? certificates[0] : null; } }
A
using var
can make this:private static X509Certificate2 GetCertificateFromCertificateStore(string sha1) { using var store = new X509Store(StoreName.My, StoreLocation.LocalMachine); store.Open(OpenFlags.OpenExistingOnly | OpenFlags.ReadOnly); var certificates = store.Certificates.Find(X509FindType.FindByThumbprint, sha1, false); return certificates.Count > 0 ? certificates[0] : null; }
This has the same effect of
store
havingDispose
called on it at the end of the method. The benefit here being that there is less indentation and braces. This keeps me focused on the code that matters. I don’t care whenstore
is disposed in the method, I can just observe that it has ausing
modifier on the local and be assured thatDispose
will be called.This isn’t the same as garbage collection or finalizers. Both of those are non- deterministic, and can lead to unexpected program behavior. That’s less so in the case of
X509Store
, so let’s look at another example:using Stream stream = entry.Open(); var xmlDocument = XDocument.Load(stream, LoadOptions.PreserveWhitespace); return new OpcRelationships(location, xmlDocument, readOnlyMode);
Not disposing a stream that is backed by a file can cause access errors later in software that might try to open that file again - it is already open, so not only is it a bad idea it leave streams to the GC, it is just simply incorrect.
However again
using
on the local ensures it is deterministically closed.When it gets disposed I can see being slightly unclear to the developer. The quick explanation is when the local is no longer reachable, not when it is last used. The C# 8 above gets compiled roughly to:
var stream = entry.Open(); try { var xmlDocument = XDocument.Load(stream, LoadOptions.PreserveWhitespace); return new OpcRelationships(location, xmlDocument, readOnlyMode); } finally { if (stream != null) { ((IDisposable)stream).Dispose(); } }
The disposal is done after the return, when the local is no longer reachable, not after
XDocument
is created.I find this very helpful to keep code readable. This doesn’t work when you need fine control over when
Dispose
is called. A place where this does not work well is when theDispose
pattern is used for scopes, such as logging. The AzureSignTool project has code similar to this inSignCommand
:var logger = loggerFactory.CreateLogger<SignCommand>(); Parallel.ForEach(AllFiles, options, () => (succeeded: 0, failed: 0), (filePath, pls, state) => { using (var loopScope = logger.BeginScope("File: {Id}", filePath)) { logger.LogInformation("Signing file."); //Sign the file. omit a bunch of other code. logger.LogInformation("Done signing the file."); } logger.LogDebug("Incrementing success count."); return (state.succeeded + 1, state.failed); }
Here, we cannot change this to a
using var
because then theLogDebug
would be inside of that logging scope, which it wasn’t before. This is a place where we continue to wantDispose
to be called at a different time from the whenloopScope
would no longer be in scope.My impression from C# developers is that they do not tend to call
Dispose
on resources as soon as it can be disposed, just at a reasonable point in the same method. Most developers do not write this code:public bool MightBeExe(string filePath) { var firstBytes = new byte[2]; int bytesRead; using (var file = File.Open(filePath, FileMode.Open)) { bytesRead = file.Read(firstBytes, 0, 2); } return bytesRead == 2 && firstBytes[0] == (byte)'M' && firstBytes[1] == (byte)'Z'; }
They will instead write something like:
public bool MightBeExe(string filePath) { using (var file = File.Open(filePath, FileMode.Open)) { var firstBytes = new byte[2]; var bytesRead = file.Read(firstBytes, 0, 2); return bytesRead == 2 && firstBytes[0] == (byte)'M' && firstBytes[1] == (byte)'Z'; } }
Which is a perfect candidate for
using var
:public bool MightBeExe(string filePath) { using var file = File.Open(filePath, FileMode.Open); var firstBytes = new byte[2]; var bytesRead = file.Read(firstBytes, 0, 2); return bytesRead == 2 && firstBytes[0] == (byte)'M' && firstBytes[1] == (byte)'Z'; }
There are of course some reasonable limitations to this feature. For example, it cannot be combined with out-variables.
if (Crypto32.CryptEncodeObjectEx( // other stuff out var handle, ref size) ) { using (handle) { // Do stuff } }
This does not work:
if (Crypto32.CryptEncodeObjectEx( // other stuff out using var handle, ref size) ) { // Do stuff }
Jared Parsons said on Twitter that C# folks thought of this, and decided that it had “Too much confusion about ownership.” Thinking about it myself, I agree, so it’s nice that the feature is limited in that regard.
Another limitation is that the variable cannot be reassigned. For example:
using var stream = entry.Open(); stream = entry2.Open();
This will produce error CS1656, “Cannot assign to ‘stream’ because it is a ‘using variable’”.
All in all, I very much like this small feature in C# 8. It has reasonable guard rails on it from doing something too weird like re-assigning to it, while giving the benefit of less blocks, braces, indentation.
-
Secure Random Integers in .NET Core 3
.NET Core 3.0 is tentatively set to include a new API for securely generating a random integer bound to a specific range.
I won’t be shy in admitting that it was something I pushed for and made the initial attempt at implementing, though it’s unfair to say that I implemented it by myself given all of the outstanding feedback I got on the initial pull request (thanks Levi and Jeremy!)
It’s been known for a while that
System.Random
shouldn’t be used when cryptographic randomness is required. Despite that, there wasn’t anything built in to .NET that made creating bounded random integers easy. You could either useSystem.Random
and hope for the best, or use a CSPRNG likeRandomNumberGenerator
that gave back raw bytes, which requires some thought on how to to properly convert it to a random integer without introducing any kind of bias.Starting in .NET Core 3.0, you’ll be able to do:
var min = 1; var max = 1_000; var randomNumber = RandomNumberGenerator.GetInt32(min, max);
If you need this before .NET Core 3, well, the source is right there. It can be adapted with a bit of effort to work on the .NET Framework as well as other environments that don’t have
Span<T>
.