C#

System.Security.Cryptography.RSA has been the focus of many performance and usability improvements in recent major releases of .NET (and previously .NET Core). It’s a cross-platform, performant implementation of RSA signing and encryption that uses the operating system’s cryptography libraries rather than a software implementation such as Bouncy Castle.

In this article, you’ll learn the various ways of creating, parsing, and loading RSA keys in .NET, whether from a JSON Web Key (JWK) or a certificate generated by OpenSSL. This article serves as a reference for loading in RSA keys for my various C# articles on JWTs and cryptography. Code samples work for .NET 6 onwards.

Signing XML (XMLDSig) is not a particularly fun thing to deal with, and, from a security perspective, getting it wrong has been the source of many headaches. Whether it is peculiarities from the core XML specification or just the placement of a signature element, XML and XML signing have been the source of many vulnerabilities, including most of SAML’s.

In this article, you’re going to see how to create and validate signed XML in .NET using RSA while avoiding some of the common security issues with XML. This will follow a similar structure to the guidance in "Security in .NET" and the Microsoft documentation, but with a focus on .NET Core/.NET and some of the attacks you will need to defend against when dealing with signed XML.

XML digital signatures are a tricky beast to handle but, while you’d rather be using something else, that doesn’t mean you get to neglect it by using outdated cryptography.

In this article, I’m going to show you how to sign XML in .NET Core 2 onwards using ECDSA (an Elliptic Curve Digital Signing Algorithm) rather than the in-built RSA.

While these examples use ECDSA, you can use the same approach to support any signing algorithm not supported out of the box by .NET.

In the past, I’ve talked about how to create Elliptic Curve (EC) keys using OpenSSL and how to use them to sign JWTs and XML in .NET and .NET Core. This time, I’m going to talk about different ways of parsing and loading EC keys in .NET.

In this article, you’re going to learn what EC keys look like and then see how to use that knowledge in four different ways to load or create an ECDsa object in .NET.By the end of this article, you should be able to load in an EC key, no matter the format.

When using symmetric encryption, you should be favoring authenticated encryption, such as AES-GCM (Galois/Counter Mode), rather than unauthenticated encryption, such as AES-CBC (Cipher Block Chaining).

Authenticated encryption provides you with confidentiality and an additional integrity check, allowing you to defend against various attacks based on the chosen-ciphertext attack.

In this article, you’re going to see how to use the AES-GCM implementation found in System.Security.Cryptography, available as of .NET Core 3. If you’re not there yet, I’m also going to show you how to do the same with Bouncy Castle.

As part of my work with ScottBrady.IdentityModel, I’ve had the chance to play with XChaCha20-Poly1305. Despite sounding a bit silly and being a pain to type, XChaCha20-Poly1305 is a useful symmetric encryption algorithm that offers an alternative to the AES we know and love.

In this article, I am going to give a high-level overview of ChaCha20, Poly1305, and XChaCha20-Poly1305. This will include some code samples using a libsodium implementation in .NET, and a silly “rolling your own” implementation to help demonstrate the differences between ChaCha20-Poly1305 and XChaCha20-Poly1305.

PEM is a file format that typically contains a certificate or private/public keys. PEM files have had patchy support in Windows and .NET but are the norm for other platforms. However, starting with .NET 5, .NET now has out of the box support for parsing certificates and keys from PEM files.

This article will show you how to manually load a PEM file in .NET Core 3.1 (the old way) and how to do the same using the new .NET 5 APIs.You’ll also see how to use PEM certificates for Kestrel TLS.

Edwards-curve Digital Signing Algorithm (EdDSA) is the new hotness in digital signing algorithms. From what I’ve seen, it’s the current recommendation from the cryptography community and generally preferred over your typical Elliptic Curve Digital Signature Algorithm (ECDSA).

I’ve had a few chances to play with EdDSA as part of my work with FIDO2 and PASETO, so I’m going to solidify that by writing up my high-level understanding of EdDSA, how to use EdDSA in .NET with Bouncy Castle, and how to sign a JWT with EdDSA using ScottBrady.IdentityModel.

In my previous article I discussed the criticisms surrounding JSON Web Tokens (JWTs) and some of their alternatives. Some of these alternatives had merits, however, many of the implementations that I found neglected to include the payload validation that we are used to in JWT libraries.

I’ve implemented some of these JWT alternatives as a side project, with a focus on including JWT payload validation. Thankfully, the Microsoft.IdentityModel libraries were extensible enough for me to build on top of the existing JWT validators. This means that protecting your APIs with PASETO can look as simple as...

Sometimes you need to use an algorithm that your goto libraries do not support. Whether it’s because your platform’s cryptography libraries don’t implement it yet or because a particular client library doesn’t support it, sometimes you need to go off piece.

In this article, we’re going to look at how to do that when using the Microsoft.IdentityModel JWT libraries, using ES256K as our custom signing algorithm. Example code will both generate and verify a JWT signature.

As of version 5.5, Microsoft’s IdentityModel library now supports the signing of JSON Web Tokens using the RSASSA-PSS (Probabilistic Signature Scheme) digital signature algorithm. This is great news if you’re looking to start building .NET Core systems that implement OpenID’s Financial-grade API and Open Banking, where PS256 should be used for signing.

You can find the full list of support for various .NET targets on GitHub, but the exciting thing is that PS256, PS384, and PS512 are now supported on .NET Core.

A signed JSON Web Token (JWT) is one of the most useful and common constructs you’ll see floating around modern security systems. These tokens give us a simple, secure structure in which to transfer data and verify that it has not been tampered with. However, what about when we need to send sensitive data within a JWT?

To solve this issue, we have JSON Web Encryption (JWE), enabling us to encrypt a token so that only the intended recipient can read it.

In this article, we’re going to look at how we can protect sensitive data within our JWTs in .NET Core, using JWEs and the various token libraries available to us.

The Elliptic Curve Digital Signing Algorithm (ECDSA) is generally a better signing algorithm than your traditional RSA. ECDSA is generally harder to crack, resulting in much shorter keys and signatures for a similar level of security. For example, a 256-bit key Elliptic Curve (EC) key provides the same security as a 3072-bit RSA key.

While better signing algorithms are available, ECDSA has seen a rise in popularity thanks to an update in security to many mainstream OpenID Connect and SAML identity providers and a requirement of its usage in Open Banking and eiDAS.

In this article, you’ll learn how to use ECDSA for signing JSON Web Tokens (JWTs) in .NET (.NET Core onwards) using the ECDsa and ECDsaSecurityKey classes from Microsoft.IdentityModel. This article targets .NET Core 3.1 onwards.

Problem

Recently I had to use a Webhook that returned an enumerated string that was very different from the enum it was supposed to convert to (in this case the JSON used snake case, C# used camel case).

Oddly enough, I knew the solution for this when receiving XML but I was a bit stumped when it came to dealing with JSON.

I could have received the JSON string and then manually mapped out the entire enum within my business logic, but I wanted to handle this during deserialization with decent performance whilst still mapping the enum and its associated string in one easily maintainable location.

Solution

The solution was to use some of the methods and attributes in Newtonsoft.JSON, you know, that package that everything else is dependent on but you never seem to use. This makes use of...