runtime: [RijndaelManaged] System.PlatformNotSupportedException: 'BlockSize must be 128 in this implementation.'

.NET Core does not support AES/Rijndael with a block size other than 128. @Gnbrkm41 gave a pretty good summary of the issue.

Rijndael (pre AES-specification) supported different block sizes. The final, standardized version of AES only uses a block size of 128 and different block sizes were removed from its specification.

RijndaelManaged in .NET Framework was a pure, C# implementation of Rijndael (as were all of the other *Managed). In .NET Core there are no managed implementations of cryptographic primitives. They all depend on components as part of the underlying operating system. To my knowledge, none of these underlying components support block sizes other than 128-bits for AES.

The RijndaelManaged class was brought back in .NET Core 2.0 for API compatibility. However unlike the .NET Framework, the implementation forwards to an AES implementation (which only supports 128-bit block sizes).

I have no idea what should I do, it’s blocking issue for me. I can not run/test my code because of this problem.

You should use AES / Rijndael with a block size of 128 bits - or plan to migrate to it. I suppose you could do that with the .NET Framework by decrypting it with RijndaelManaged and re-encrypting it with a block size of 128. Then you are using AES and .NET Core will be able to interact with it.

.NET Framework implemented the Rijndael algorithm before AES got standardized (2001) (it was sort of unfortunate timing, because AES standardization beat the release of .NET Framework 1.0, but not the betas… I wasn’t on the team back then, so I don’t know if there was a discussion of “do we cut support at the last minute?” or not). The AES algorithm is just the Rijndael algorithm when the block size is fixed at 128-bit.

To avoid timing side-channel vulnerabilities, and compliance problems (both for us as a platform and applications built on us), .NET Core has eliminated the managed implementations of cryptographic algorithms. The plan is to never bring them back (as @vcsjones pointed out, we brought back the class names, but they’re purely for ease of porting… AesManaged asks the OS to do AES, and RijndaelManaged asks the OS to do AES… the OS won’t do the more general Rijndael algorithm).

I’m wondering is there any similar migration (from .NET Framework to .NET Core) problems?

There are a lot of things that either aren’t in .NET Core at all (AppDomains, non-AES Rijndael) or aren’t available on other platforms (System.DirectoryServices).

https://docs.microsoft.com/en-us/dotnet/core/porting/ recommends the API Port tool (which identifies compile failures you’re likely to expect from types or members that don’t exist in .NET Core) and the API Analyzer, which identifies places that .NET Core throws PlatformNotSupportedException (when .NET Framework didn’t). The API Analyzer should flag calling RijndaelManaged.BlockSize’s setter.

what about cross-platform support if we add such a dependency to NET Framework?

.NET Framework only runs on Windows.

I have no idea what should I do, it’s blocking issue for me.

I’ll agree with @vcsjones that the best answer is to get existing data converted from Rijndael-with-blocksize-256 to AES, and change the pipeline going forward. If you can’t get the encrypting party to adjust their process to use the algorithm which has been the industry standard for years; you might be able to do it with BouncyCastle, or another 3rd party solution. Per http://www.bouncycastle.org/specifications.html, their RijndaelEngine class supports the 256-bit block size, but the easier to use Rijndael class does not.

Helping you with BouncyCastle (or other 3rd party packages) is outside our domain of expertise. I also don’t know that it would actually work for you, I’m just basing it on their docs. (Heck, I don’t even know which of the BouncyCastle packages to reference. Maybe BouncyCastle.NetCore?)

Which framework do you get the error from? The document seem to suggest any other size than 128 is not supported on .NET Core:

This algorithm supports key lengths of 128, 192, or 256 bits; defaulting to 256 bits. In .NET Framework, this algorithm supports block sizes of 128, 192, or 256 bits; defaulting to 128 bits (Aes-compatible). In .NET Core, it is the same as AES and supports only a 128-bit block size.

Though your TargetFrameworks is set to target .NET Framework 4.6.1 as well, so this is irrelevant if you’re getting this on .NET Framework. Also interesting that there’s mention in the document that you should use Aes instead of this due to this being a predecessor of it.