C#2 的加密 API 建议吗？
我们需要为项目提供付费支持的加密/解密 API - AES > 256？
我不希望开发人员编写自己的加密/解密代码，即使使用内置的东西也是如此。 出错的机会很多。
非常有价值的网站链接。
更新 由于许多人所说的事实 - 如果您不熟悉加密，并且犯了一个小错误并且它失败了，那么很难理解......
我已经看到了答案，并将从内置中获得我们自己的加密/解密 -但所有团队都需要进行同行评审。
有关信息，BlowFish.Net 很好，并且比内置加密例程执行得更快，当您开始考虑将数据加密/解密到数据库中时，内置加密例程可能会出现一些巨大的性能问题...
We need a paid for supported Encryption / Decryption API for a project - AES >256?
I dont want the developers coding their own encryption / decryption even using the built in stuff. To many chances to go wrong.
Links to sites much valued.
UPDATE
Due to the fact as many have said - Its hard to understand if you are not familar with encryption, and get a small thing wrong and its busted...
I have seen answers and will be getting our own encryption/decryption from the builtin - but all the team will need to peer review.
For information BlowFish.Net is good, and performs faster than the builtin crypto routines, which when you start to look at encrypting/decrpyting data into a database can have some massive perf issues ...
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
“甚至使用内置的东西”
它内置的原因是为了让人们测试过可靠的算法可用于实现标准，而不是可能不会的黑盒第三方 API。 什么是“出错的机会”？
也许您需要切换到 Java，如果您对内置提供程序感到偏执，那么您始终可以选择使用第三方 JSSE 提供程序。
"even using the built in stuff"
The reason that it's built in is so that people have tested, reliable algorithms available to use that implement standards, not black box third party APIs that might not. What are the "chances to go wrong"?
Maybe you need to switch to Java, you can always opt to use third party JSSE providers there if you're paranoid about the built-in provider.
Bouncy Castle 是一个备受推崇且开发良好的 .NET 加密库，通常推荐用于此类问题。 但是使用 System.Security.Cryptography 命名空间? - 它非常安全、非常快并且不需要任何外部库。 下面是如何实现它的示例 。
哦，“使用内置的东西”意味着它不太可能出错。 您的开发人员不会编写自己的类，只需使用易于使用且经过严格测试的可用接口。此外，“内置内容”将得到 Microsoft 的良好支持，因此如果您想升级到 C# 4.0（或将来的 C# 5.0？），您可能根本不需要更改代码。
Bouncy Castle is a well respected and well developed .NET encryption library that is usually recommend for these sorts of questions. But what's wrong with using the System.Security.Cryptography Namespace? - it is extremely secure, very fast and doesn't require any external libraries. Here's an example of how to implement it.
Oh, and "using the built in stuff" will mean it is less likely to go wrong. Your developers won't be coding their own classes, just using the interfaces available which are easy to use and have been very rigorously tested.. Also, the "built in stuff" will be well supported by Microsoft, so if you want to upgrade to C# 4.0 (or C# 5.0 in the future?) you probably won't need to change your code at all.
如果您要使用第三方库，您很可能仍然会遇到相同的问题，这基本上可以归结为不了解加密的陷阱。
如果没有充分的理解，您很可能会在密钥管理方面犯错误，或者使用错误的初始化向量或密钥。 无论您使用内置库（这很好）还是第三方库，您都需要了解并解决这些问题。
如果您对此感到足够担心，最好的建议可能是引入某人，或者更好的是 - 培训人们了解加密。
If you were to use a 3rd party library you would most likely still run into the same issues, which basically boil down to not understanding the pitfalls of encryption.
Without a decent understanding you'll most probably make mistakes with key management, or using bad initialisation vectors or keys. These are issues you'll need to understand to tackle regardless of whether you use the inbuilt libraries (which are fine), or a 3rd party library.
If its something you feel worried about enough, the best recommendation is probably to bring in someone, or better yet - train up people to understand encryption.
使用内置的“东西”。 但请确保以正确的模式使用它。
Use the builtin 'stuff'. But make sure you use it in the correct mode.