WebAssembly: Aes.Create() throws System.PlatformNotSupportedException

[AliGuemues]

Hello,

I switched from ASP .NET Core 3.1 to ASP .NET 5 RC-1. I use the current Visual Studio 2019 Preview (Version 16.8.0 Preview 3.0).

I have following issue: I created a Blazor PWA application with AES-Encryption. So everthing works fine in .NET Core 3.1 after the method Aes.Create() is called. By switching to ASP .NET 5 RC-1 I get a System.PlatformNotSupportedException after Aes.Create() is called:

System.Security.Cryptography.Algorithms is not supported on this platform

System.PlatformNotSupportedException: System.Security.Cryptography.Algorithms is not supported on this platform.\n   
at System.Security.Cryptography.Aes.Create()

I already read the breaking changes from .NET Core 3.1 to .NET 5 but dont found anything related to this issue.

Thanks in advance!

[campersau]

See #40076 (comment) and the comment below.

[ghost]

Tagging subscribers to this area: @bartonjs, @vcsjones, @krwq, @jeffhandley
See info in area-owners.md if you want to be subscribed.

[marek-safar]

Related to #40074

[jeffhandley]

@AliGuemues Would you be able to share more about the scenario you're using Aes for within the browser? While looking at the APIs folks have reported needing in the browser, we're also trying to better understand the functionality that needs to be accomplished.

[AliGuemues]

@jeffhandley So basically we want to port a UWP application to Blazor. We have encrypted data on a Blob-Storage which would be decrypted inside the UWP application. Any new or changed data from our UWP application would be encrypted again and send to the Blob-Storage.

We want to port this behaviour to a potencial Blazor (PWA) application.

[bartonjs]

What's the key management strategy for the application? (That is, how are you getting the same key to decrypt as you had to encrypt, assuming the operations happen on different launches of the process?)

The two most obvious (to me) answers are: saving it to a file / deriving it from a password. If it's "saving it to a file", what's your strategy for migration from UWP to Blazor and/or the user migrating to another computer?

We're actually trying to understand a real overarching use case. The simple scenario descriptions are at the level of "I want to save some stuff to third party storage where they can't be coerced to read it"... but then it ignores things like how migrating to a different computer would work, or if there's any sort of recovery path... and then my response is "so two days after launch when someone can't remember (or typo the same way) their password they get mad and abandon the application...", which (to me) negates the scenario. So... please educate me/us 😄.

[gulbanana]

I have a different scenario for in-browser Aes, although there is some overlap. My team builds client-server enterprise applications used both on intranets and in the cloud. Some of our clients want communication between client and server to be encrypted, even if the underlying transport is HTTPS - for example, this is done for one application where the network's IT staff, who possess keys for the enterprise MITM certificates, should not be able to decrypt this specific application's data.

In order to achieve this extra layer of encryption, the server creates a session key and communicates it to the client, with an initial key exchange based on the user's password (via PBKDF2). The session key and a random number are then set as the Key and IV on an Aes instance on both ends, securing the communication channel. Because we have an application server, users forgetting passwords isn't a big deal - an application administrator can reset it for them.

Now we would like to use Blazor as a client technology, and have built prototypes. Our code uses both Aes and Rfc2898DeriveBytes from System.Security.Cryptography. It works on .NET Core 3.1, but not on .NET 5.0.

[AliGuemues]

All our users get initially a AccessKey which they use with a password they choose to generate a certificate. This certificate is also saved in the Azure storage but gets installed on the users machine. With every new installation the user can get their certificate with the password. The certificate holds the key(s) for en/decryption.

Now every new dataset that was generated or edited from our UWP application gets encrypted and stored directly to the Azure Blob storage. The local application is always in sync with the cloud because every change-set were directly uploaded. So migration should not a big deal in terms of data size (approx. 10-50 MB of user data) or that any local files has to be migrated.

[harrison314]

Another scenario for the use of AES and PBKDF2 in WebAssembly is the creation encrypted pastebin. Like 0bin, cryptobin,...

Or, scenarios where the serverside should not have access to user data.

Or scenarios with secure applications where the entire infrastructure is not trusted (typically seecret management).

[GrabYourPitchforks]

We just posted our plan for cryptographic support in Blazor/wasm apps in .NET 7 and beyond. See here for full details. That document also includes sample code demonstrating how to interop with the JS layer to get support for other algorithms (like HMACSHA256) which aren't supported out-of-the-box in Blazor/wasm in .NET 6.

Please use #40074 for feedback on that document. This issue (#42384) should remain geared toward AES specifically.

Thanks!

[igandrews]

I'm not sure if you're still looking to collect info on scenarios devs need AES but we need it to support reading/writing password protected excel files.

[vcsjones]

@eerhardt I think we can close since #70915 and #71501 are merged, correct?

[eerhardt]

Yep, closing. #70915 and #71501 enabled AES support on WebAssembly. This will be available in .NET 7 Preview 7.