[讨论] 关于微软Crypt API安全的思考解决方案
[讨论] 关于微软Crypt API安全的思考
最近在做一个项目，需求分析已经完成。项目中很大部分涉及到了数据加密的问题，并且数据只能采用对称加密的模式。 基于开发成本以及代码稳定性等多方面的考虑，决定采用微软的Crypt API来完成对文档的加密。 而且以前也有几个项目都是用Crypt API来完成的，同时客户也没有反应出任何问题来。
晚上抱着儿子出去遛弯，突然想到一个问题，由于Crypt API中所有的API都包含在Advapi32.dll中，那么在程序运行过程中，我直接注入一个线程，HOOK 相关的Crypt API,那么程序中所有的加密岂不是不堪一击？ 而且实现HOOK API之类的也不是什么复杂技术，下几个源码改吧改吧就能实现。由此我不由的想到了以下的几个问题，希望大家共同探讨：
1、由于时间关系，我并没来得及验证HOOK API是不是真的能够完全HOOK到这些API，不过我想应该问题不大。
2、如果能HOOK到这些相关API，而且能够很简单的就能得到这些原始的秘密或HASH或数据，那么就说明微软Crypt API虽然可能不是一个鸡肋，至少不能直接使用这些API,自己还得需要在自己程序中再进行二次加密。不过我想微软不可能没有这方面的考虑，那么有什么办法去避免这些可能存在的发生。
3、假设我所想的这一切都成立，而除了对Crypt API进行加密后的数据进行二次处理没有什么更好的办法外，还有什么更好的办法？
4、大家有没有使用过比较稳定的对称加密开源库，给推荐一下。
5、有很多没想到的，希望大家一起讨论讨论
------解决方案--------------------
现在对称加密的成熟库很多，3DES等
------解决方案--------------------
较成熟的 openssl, cryptlib, 同样也有被 hook 的可能?
可否把加密算法实现在自己的 dll 中, 做一些 anti hook 的保护.
我不懂, 乱说的.
------解决方案--------------------
不用API直接用算法实现，难不成还能HOOK算法？
------解决方案--------------------
用openssl
静态链接
------解决方案--------------------
是不是可以不用考虑这么多啊，因为加密的目的大多是用于网络传输，只有能一定程度地防范恶意截包后的数据解密，就基本达到目的了。毕竟，软件加密只是一方面（而且从理论上讲，没有破不了的），还得与用户的系统布署、安全等级、制度规定等措施相结合。
------解决方案--------------------
HOOK Crypt API 得到密码的前提是他知道你使用了Crypt API 进行的加密
只要清楚你的加密原理很多种办法可以破解你的密码的
只不过 用Crypt API 可能更容易被破一点
我想你可以在防止静态反编译 和 动态跟踪上面多花点精力
------解决方案--------------------
没有完全安全之说
------解决方案--------------------
Crypto++ (公共领域)，你能想到的算法基本上都支持，拷一段它的说明：
authenticated encryption schemes GCM, CCM, EAX
high speed stream ciphers Panama, Sosemanuk, Salsa20, XSalsa20
AES and AES candidates AES (Rijndael), RC6, MARS, Twofish, Serpent,
CAST-256
IDEA, Triple-DES (DES-EDE2 and DES-EDE3),
other block ciphers Camellia, SEED, RC5, Blowfish, TEA, XTEA,
Skipjack, SHACAL-2
block cipher modes of operation ECB, CBC, CBC ciphertext stealing (CTS),
CFB, OFB, counter mode (CTR)
message authentication codes VMAC, HMAC, CMAC, CBC-MAC, DMAC,
Two-Track-MAC
SHA-1, SHA-2 (SHA-224, SHA-256, SHA-384, and
hash functions SHA-512), Tiger, WHIRLPOOL, RIPEMD-128,
RIPEMD-256, RIPEMD-160, RIPEMD-320
RSA, DSA, ElGamal, Nyberg-Rueppel (NR),
public-key cryptography Rabin, Rabin-Williams (RW), LUC, LUCELG,
DLIES (variants of DHAES), ESIGN
padding schemes for public-key PKCS#1 v2.0, OAEP, PSS, PSSR, IEEE P1363
systems EMSA2 and EMSA5
Diffie-Hellman (DH), Unified Diffie-Hellman
key agreement schemes (DH2), Menezes-Qu-Vanstone (MQV), LUCDIF,
XTR-DH
elliptic curve cryptography ECDSA, ECNR, ECIES, ECDH, ECMQV
insecure or obsolescent MD2, MD4, MD5, Panama Hash, DES, ARC4, SEAL
algorithms retained for backwards 3.0, WAKE, WAKE-OFB, DESX (DES-XEX3), RC2,
compatibility and historical SAFER, 3-WAY, GOST, SHARK, CAST-128, Square
value
最近在做一个项目，需求分析已经完成。项目中很大部分涉及到了数据加密的问题，并且数据只能采用对称加密的模式。 基于开发成本以及代码稳定性等多方面的考虑，决定采用微软的Crypt API来完成对文档的加密。 而且以前也有几个项目都是用Crypt API来完成的，同时客户也没有反应出任何问题来。
晚上抱着儿子出去遛弯，突然想到一个问题，由于Crypt API中所有的API都包含在Advapi32.dll中，那么在程序运行过程中，我直接注入一个线程，HOOK 相关的Crypt API,那么程序中所有的加密岂不是不堪一击？ 而且实现HOOK API之类的也不是什么复杂技术，下几个源码改吧改吧就能实现。由此我不由的想到了以下的几个问题，希望大家共同探讨：
1、由于时间关系，我并没来得及验证HOOK API是不是真的能够完全HOOK到这些API，不过我想应该问题不大。
2、如果能HOOK到这些相关API，而且能够很简单的就能得到这些原始的秘密或HASH或数据，那么就说明微软Crypt API虽然可能不是一个鸡肋，至少不能直接使用这些API,自己还得需要在自己程序中再进行二次加密。不过我想微软不可能没有这方面的考虑，那么有什么办法去避免这些可能存在的发生。
3、假设我所想的这一切都成立，而除了对Crypt API进行加密后的数据进行二次处理没有什么更好的办法外，还有什么更好的办法？
4、大家有没有使用过比较稳定的对称加密开源库，给推荐一下。
5、有很多没想到的，希望大家一起讨论讨论
------解决方案--------------------
现在对称加密的成熟库很多，3DES等
------解决方案--------------------
较成熟的 openssl, cryptlib, 同样也有被 hook 的可能?
可否把加密算法实现在自己的 dll 中, 做一些 anti hook 的保护.
我不懂, 乱说的.
------解决方案--------------------
不用API直接用算法实现，难不成还能HOOK算法？
------解决方案--------------------
用openssl
静态链接
------解决方案--------------------
是不是可以不用考虑这么多啊，因为加密的目的大多是用于网络传输，只有能一定程度地防范恶意截包后的数据解密，就基本达到目的了。毕竟，软件加密只是一方面（而且从理论上讲，没有破不了的），还得与用户的系统布署、安全等级、制度规定等措施相结合。
------解决方案--------------------
HOOK Crypt API 得到密码的前提是他知道你使用了Crypt API 进行的加密
只要清楚你的加密原理很多种办法可以破解你的密码的
只不过 用Crypt API 可能更容易被破一点
我想你可以在防止静态反编译 和 动态跟踪上面多花点精力
------解决方案--------------------
没有完全安全之说
------解决方案--------------------
Crypto++ (公共领域)，你能想到的算法基本上都支持，拷一段它的说明：
authenticated encryption schemes GCM, CCM, EAX
high speed stream ciphers Panama, Sosemanuk, Salsa20, XSalsa20
AES and AES candidates AES (Rijndael), RC6, MARS, Twofish, Serpent,
CAST-256
IDEA, Triple-DES (DES-EDE2 and DES-EDE3),
other block ciphers Camellia, SEED, RC5, Blowfish, TEA, XTEA,
Skipjack, SHACAL-2
block cipher modes of operation ECB, CBC, CBC ciphertext stealing (CTS),
CFB, OFB, counter mode (CTR)
message authentication codes VMAC, HMAC, CMAC, CBC-MAC, DMAC,
Two-Track-MAC
SHA-1, SHA-2 (SHA-224, SHA-256, SHA-384, and
hash functions SHA-512), Tiger, WHIRLPOOL, RIPEMD-128,
RIPEMD-256, RIPEMD-160, RIPEMD-320
RSA, DSA, ElGamal, Nyberg-Rueppel (NR),
public-key cryptography Rabin, Rabin-Williams (RW), LUC, LUCELG,
DLIES (variants of DHAES), ESIGN
padding schemes for public-key PKCS#1 v2.0, OAEP, PSS, PSSR, IEEE P1363
systems EMSA2 and EMSA5
Diffie-Hellman (DH), Unified Diffie-Hellman
key agreement schemes (DH2), Menezes-Qu-Vanstone (MQV), LUCDIF,
XTR-DH
elliptic curve cryptography ECDSA, ECNR, ECIES, ECDH, ECMQV
insecure or obsolescent MD2, MD4, MD5, Panama Hash, DES, ARC4, SEAL
algorithms retained for backwards 3.0, WAKE, WAKE-OFB, DESX (DES-XEX3), RC2,
compatibility and historical SAFER, 3-WAY, GOST, SHARK, CAST-128, Square
value