使用 Rijndael.Create() 而不是 new RijndaelManaged() 是否安全
我读过一些关于这个主题的文章，但我仍然对我看到的答案不是 100% 满意。
当您使用 Rijndael.Create() 创建加密算法时，您会得到一个 RijndaelManaged 类型的对象 - 这与调用 之间似乎没有区别>new RijndaelManaged()（对于 VB 人员来说，或者 New RijndaelManaged()）。 :)
根据我所读到的内容，Rijndael.Create() 方法的存在是为了让您无需担心具体的实现，以防它在未来版本中发生变化。但我的问题是：假设这种情况确实发生，并且 .NET 5.0 返回不同的实现。是否可以保证使用 RijndaelManaged 加密的项目可以使用 SomeFutureRijndaelManaged 解密而不会出现问题？
我无法想象它们会不兼容，但我只是想确认这一点。
谢谢
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 changes 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
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
Rijndael.Create 添加了一个抽象层和额外的重定向，以便它可以提供算法的系统特定版本。实际上，它非常慢，需要遍历 Crypto API 来解析 OID 字符串映射，最终到达
RijndaelManaged类。我们发现，它不但不能提供跨平台的稳定性，反而会导致 Windows 2000/XP/Vista/Windows 出现问题。另外，通过 Create 方法创建对象的实例比直接实例化 RijndaelManaged 类要慢数百倍。我们发现这是在内存中加密/解密数据时的主要瓶颈。至于“面向未来”——安全算法不存在这样的事情。当.NET 5.0出来时。无论您使用哪种方法创建算法，您都必须进行更新以适应它们所做的任何更改。您可以在应用程序的 .config 文件中使用
Rijndael.Createadds 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 theRijndaelManagedclass. 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.