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.
Recently, as part of messing around with an identity provider, I was given the following private/public key pair and told to sign a JSON Web Token (JWT) with them using ES256:
Private: c711e5080f2b58260fe19741a7913e8301c1128ec8e80b8009406e5047e6e1ef Public: 04e33993f0210a4973a94c26667007d1b56fe886e8b3c2afdd66aa9e4937478ad20acfbdc666e3cec3510ce85d40365fc2045e5adb7e675198cf57c6638efa1bdb
Okay, sounds simple enough. 5 days and a lot of swearing later, I finally got it working. Now I’m going to write it down so that I don’t have to go through it again.
In .NET Core, to sign a JWT using an Elliptic Curve Digital Signature Algorithm (ECDSA) we need to get ourselves an instance of
ECDsaSecurityKey. The constructor for this takes in an instance of
ECDsa, which in turn we have to pass in an instance of
ECParameters if we want to load in our own key and not have it generate one for us. So, let’s make a start!
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.
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...