openssl 与 windows capi
对于加密问题，使用 openssl 或 windows capi 哪个更好，两者的优点和缺点是什么。 如果可以在 openssl 上编写我的加密程序并使用 windows capi 解密它，没有问题，或者存在一些问题。
Which is better to use openssl or windows capi for ecnryption issues what is the pro and con list for both.
and if it possible to write my encryptor program on openssl and decrypt it with windows capi with no problem or there are some problem with this.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
出于加密目的，我发现首先考虑密钥管理更容易。密钥存储在哪里、如何创建、谁使用它们以及如何安全地销毁它们。根据我的经验，密钥管理对应用程序结构的限制最大。
CryptoAPI 提供了一个 API，用于通过在操作系统中注册的驱动程序（“CSP”）访问存储在任意位置的密钥。 OpenSSL 可能会在 OpenSC 的帮助下提供类似的功能，但驱动程序应支持 PKCS#11 API。无论哪种方式，驱动程序都是由构建存储设备的人提供的某种 DLL（假设密钥在硬件设备中存储和使用）。
如果您希望能够使用存储在硬件设备中的密钥（该设备可能是智能卡、HSM...任何可以进行加密但拒绝提供密钥本身的设备），那么您将必须经过CryptoAPI 或 PKCS#11。 CryptoAPI 本质上仅适用于 Windows，因此如果您希望代码能够在非 Windows 系统（MacOS、Linux、Solaris...）上运行，那么 PKCS#11 是您的最佳选择。如果您采用 PKCS#11 方式，您可能需要尝试 NSS OpenSSL 的。 NSS 是Netscape 衍生浏览器（例如Firefox）中使用的库。它是开源的。
另一方面，如果您仅针对 Windows 系统，那么 CryptoAPI 可以简化分发过程，因为它已经存在，无需额外的 DLL。
如果您准备放弃硬件，并希望使用纯软件加密技术，并将密钥保存在 RAM 中，那么您可能不想使用 CryptoAPI，它在其实现的算法数量和它接受的变体数量方面相当不足（例如，CryptoAPI 坚持要求 RSA 公共指数小于 32 位——这是正常情况，但该限制仍然是任意的并且可能令人厌烦）。有很多密码学库；除了 OpenSSL 和 NSS 之外，您可能还想研究一下 Crypto++，它相当成熟并且据说对 C++ 友好。
For cryptographic purposes, I find it easier to think about key management first. Where keys are stored, how they are created, who uses them, and how they are to be securely destroyed. In my experience, key management is what constrains most the application structure.
CryptoAPI offers an API to access keys which are stored in arbitrary places, through a driver (a "CSP") registered in the operating system. OpenSSL may offer something similar with the help of OpenSC, but the driver shall then support the PKCS#11 API. Either way, the driver is some kind of DLL provided by whoever built the storage device (assuming that the key is stored and used in a hardware device).
If you want to be able to use keys stored in hardware devices (where the device may be a smartcard, a HSM,... anything which can do some crypto but will refuse to give the key itself) then you will have to go through either CryptoAPI or PKCS#11. CryptoAPI is, by nature, Windows-only, so PKCS#11 is the way to go if you want your code to potentially run on non-Windows systems (MacOS, Linux, Solaris...). If you go the PKCS#11 way, you may want to try NSS instead of OpenSSL. NSS is the library used in the Netscape-derived browser (e.g. Firefox). It is open-source.
On the other hand, if you target only Windows systems, then CryptoAPI eases distribution, since it is already there, no need for an extra DLL.
If you are ready to forfeit hardware, and want to use software-only cryptography, with keys held in RAM, then you will probably not want to use CryptoAPI, which is quite underpowered in the number of algorithms it implements and the variations it accepts (e.g. CryptoAPI insists on RSA public exponents to be smaller than 32 bits -- this is the normal case, but the limitation is still arbitrary and potentially irksome). There are many cryptographic libraries out there; apart from OpenSSL and NSS, you might want to investigate Crypto++, which is quite mature and supposedly C++-friendly.