We Keep Coding

ASP.NET Core JWT - what't the difference between HmacSha512 and HmacSha512Signature algorithms?

There're these two similar options in SecurityAlgorithms class.
Which one should be used for signing JWT token? Is there any difference?

The difference is in the header of the token and specifically in the alg attribute. When you use HmacSha512 the header looks like this:
{
"alg": "HS512",
"typ": "JWT"
}
But when you use HmacSha512Signature the header looks like this:
{
"alg": "http://www.w3.org/2001/04/xmldsig-more#hmac-sha512",
"typ": "JWT"
}
You can confirm that using https://jwt.io/.
When I had the same question, I found out that many libraries, mostly outside .NET, do not support http://www.w3.org/2001/04/xmldsig-more#hmac-sha512 as a valid value for the alg attribute because it is not included in the JSON Web Algorithms RFC, Section 3.1.
Related discussion 1: https://github.com/auth0/node-jsonwebtoken/issues/662
Related discussion 2: https://giters.com/jwtk/jjwt/issues/676
So personally I decided to use HmacSha512. If your whole system will be developed inside the .NET ecosystem you can use either and they work the same but if the token could be consumed by an application that isn't .NET it's probably better to use HmacSha512.

There's no functional difference for JWTs; under the hood, HmacSha512Signature gets converted to HmacSha512.
My limited understanding is that they're different constants that represent the same underlying algorithm. The Signature versions are identifiers for representing the algorithm in XML, while the ones without the suffix map to the algorithm identifiers used by JWT.
Old documentation contains a remark on using the algorithms ending in 'Signature' for the signature argument, but the latest documentation no longer contains that remark. I suspect the Signature version was kept around for legacy and backwards compatibility reasons.

How to persuade GetProto to spit out proto3 format

Using the excellent ProtobufNet by Marc Gravell, we are able to maintain our types in C# and then export them to .proto files for conversion into all the languages needed by our clients.
However we would like to use the proto3 protocol format which is much simpler and less error prone than proto2 which seems to be standard.
After looking around the net we found this encouraging post from the author that seems to indicate that there is proto3 support: https://github.com/mgravell/protobuf-net/issues/187
However we have not found any documentation for ProtobufNet, and so it is a bit difficult to know how to pull this off. So the question is, how can we have GetProto generate proto3 compatible output for our decorated C# types?

In the current versions there is an optional parameter (technically an overload) that defines the schema version. I think it might even default to proto3.
So... just update? Or worst case: update and specify the optional parameter to GetProto.

What cipher does MachineKey.Protect() use?

I've just come across the MachineKey.Protect() method. I've not seen this before (a contractor introduced it into the code base). It seems interesting but the documentation on what it's doing is a little sparse.
I'm not really one for blindly following Microsoft's lead without a little investigation so I tried to find docs on how this works, what ciper does it use, how big is the key, how's the key generated, etc. But the doc's contain surprisingly little information and I couldn't find any other information on how this is implemented:
This method supersedes the Encode method, which requires the caller to
specify whether the plaintext data should be encrypted, signed, or
both. The Protect method performs the appropriate operation and
securely protects the data. Ciphertext data produced by this method
can only be deciphered by the Unprotect method.
The purposes parameter is an optional list of reasons that can lock
the ciphertext to a specific purpose. This parameter lets you isolate
cryptographic operations performed by different subsystems within an
application. A malicious client should not be able to get the result
of one subsystem's Protect method and feed it as input to another
subsystem's Unprotect method, which could compromise application
security. The purposes parameter helps ensure that protected data can
only be used by the component that originally generated it.
Applications should make sure that each subsystem uses a unique
purposes list.
so can anyone shed some light on what cipher this uses to "protect" the data sent into it? Any best practice on usage would be useful too. When is this appropriate to use, when not, etc.?

The machineKey Element specifies which algorithms and keys to use for encryption.
Following on from the comment, the documentation for the MachineKey class includes the following snippet that leads to the machineKey Element
The MachineKey class provides methods that expose the hashing and encryption logic that ASP.NET provides. For information about which encryption and hashing algorithms ASP.NET uses, and the key values that it uses with them, see machineKey Element (ASP.NET Settings Schema).

Why does RNGCryptoServiceProvider's constructor ignore its parameter?

I saw this while coding and thought it seemed odd:
Sure enough, MSDN says that RNGCryptoServiceProvider(byte[] rgb) and RNGCryptoServiceProvider(string str) both ignore their parameters.
As far as I can tell, there is no practical difference between either of those two and RNGCryptoServiceProvider(). What is going on? I suspect I'm missing something weird to do with cryptography.

It's probably a leftover from a previous older version, maybe going back as far as 1.x as even the 2.0 API contains the same description. It could however well be that the 2.0 and 2.1 API's have changed in the mean time.
If you look at the Mono source then you find
_handle = RngInitialize (rgb);
and
_handle = RngInitialize (Encoding.UTF8.GetBytes (str));
so I presume that the data was used as an additional or initial seed for a platform provided random number generator. That would also make the most sense. The Mono source usually follows the MS implementation as much as possible.
If the platform provided RNG is secure there may be little need to seed it from an application. Using an RNG as method to generate the same stream over and over again (i.e. when the parameter is used as initial seed) is fraught with danger, especially if the underlying implementation is unknown and may differ between platform and system updates. So that would be a good reason to deprecate the constructors.
Obviously if they are just deleted then the old sources won't compile anymore. So it is more logical to leave the implementation empty as the resulting instance should be generating random data anyway.
In the end this is just a (very) educated guess though, the reason is not specified in the current API documentation. The constructors are not marked obsolete either it seems. Everything I've come to expect from Microsofts crypto API documentation in other words.

Encryption libraries?

I have been tasked with implementing a PKI library in C# for a company project, and have been unable to find a good implementation of it. There appear to be multiple libraries, and many broken links pointing to MSDN libraries that have been removed. I've seen people using Crypt32.dll, people building their own libraries, people using P/Invoke to access system certificate stores, people extending the built-in libraries, examples that simply don't apply to C# (e.g. Java examples), and commercial libraries.
My question is, which implementation/library is most recommended for simple encryption/decryption of data?
As some background for what I plan to do with it, I simply need to encrypt messages using a private key (.pfx), and decrypt with public keys (.cer). Message signing and authentication isn't required at this level of the project, although it may be in future.
I have seen reference to encryption lengths which make me uneasy. We need to be able to encrypt any length message (within reason, of course!). Is this something I need to worry about, and if so, is there a way to deal with it?
I would prefer not to store public/private keys in the windows certificate manager if at all possible, but if it makes implementation significantly simpler, so be it.
I realize PKI and encryption is a large and complex subject, but I'm hoping for a relatively simple library anyway... (one can hope, right?)
Thanks!

Well, you did not mention that the built-in class doesn't cover your need, so how about System.Security.Cryptography.RSACryptoServiceProvider?
It has a large set qualified ways to asymmetrically encrypt/decrypt streams.
There are several tutorial/guides to take you along the way:
Public Key RSA Encryption in C# .NET - Code Project
RSA Encryption in .NET -- Demystified! - By Peter A. Bromberg
There are countless more to be found through Google.
Update: About the length-restrictments, it's should not be any problems if you just implement the same buffer-algorithm on both sides, encryption and decryption.
Update2: Yes, my example was RSACryptoProvider, but you can use any class that derives from System.Security.Cryptography.AsymmetricAlgorithm, if you want a public/private key-solution. Or build your own... or maybe not :)

Yes, what's wrong with built-in classes?
And if you don't want to use Windows certificate store you can use something like this
RSACryptoServiceProvider rscp = new RSACryptoServiceProvider();
rscp.FromXmlString("<RSAKeyValue><Modulus>key data gere</Modulus><Exponent></Exponent></RSAKeyValue>");
Not sure that this is a good idea for private keys, though.
There's a good tutorial on the subject here