Is it safe to use Rijndael.Create() instead of new RijndaelManaged()

I've read some on this topic, but I'm still not 100% comfortable with the answers I see.

When you create a cryptographic algorithm using Rijndael.Create(), you get an object of type RijndaelManaged - there doesn't seem to be a difference between this and calling new RijndaelManaged() (or New RijndaelManaged() for you VB folks). :)

From what I've read, the Rijndael.Create() method exists so that you don't need to worry about the specific implementation, in case it chan开发者_开发问答ges in a future version. But my question is: suppose that does happen, and .NET 5.0 returns a different implementation. Is there a guarantee that items encrypted using RijndaelManaged can be decrypted without issue using SomeFutureRijndaelManaged?

I can't imagine that they would be incompatible, but I just want to confirm that.

Thanks

Rijndael.Create adds a layer of abstraction and additional redirects so that supposedly it can provide a system specific version of the algorithm. In practice it's extremely slow, requiring trips through the Crypto API to resolve OID string mappings to eventually arrive at the RijndaelManaged class. We've found that instead of providing stability across platforms it instead causes issues across Windows 2000/XP/Vista/Windows. Plus it's several hundred times slower to create the instance of the object through the Create methods than to just instantiate the RijndaelManaged class directly. We found this to be a major bottle neck when encrypting/decrypting data in memory.

As far as "future proofing" - there's no such thing with security algorithms. When .NET 5.0 comes out. You'll have to update to accomodate any changes they make regardless of the method you create the algorithm. You can use <supportedRuntime /> in your application's .config file to lock in a .NET version so that you only allow your app to switch once you've tested and updated.