使用openssl应用层接口(EVP_***)实现对称(aes,idea等)加密

前两天写过一篇工作日志，记录了通过openssl去实现aes加密。分别通过命令行和写代码的方式。后来自己又找了一些其他的资料，包括看openssl的官方文档，发现之前的代码方式还是有点复杂。和openssl官方给出的demo，比如对称加密demo/evp文件夹下的aes-ccm的样例为例：

 虽然对于ccm的加密流程不懂，但是这个demo可以用来辅助我们理解库的使用。库的使用主要就是调用以下几个接口：

1. EVP_CIPHER_CTX_new：申请加密

2. EVP_EncryptInit_ex：初始化加密，设置加密的算法。比如demo里面使用的加密是aes-192-ccm，设置的加密算法是EVP_aes_192_ccm()。这个地方确实有些奇怪。因为用openssl enc -list来枚举openssl支持的对称加密算法中，并没有aes-192-ccm这个算法。而代码中却有存在。通过man openssl-enc查帮助资料时，搜索ccm，可以看到：

The enc program does not support authenticated encryption modes like CCM and GCM, and will not support such modes in the future。

所以这种ccm和gcm的模型，老早以前可能是支持的，但是现在不再支持了。但是通过这个接口，可以知道，如果想要使用aes-128-ecb模型，只要将EVP_aes_192_ccm()替换成EVP_aes_128_ecb()即可。

3. EVP_EncryptUpdate：加密，以aes-ecb方式为例，这里是分段进行的，都是16个字节的整数倍。

4. EVP_EncryptFinal_ex：我理解可能是padding部分的加密。至少调试aes-128-ecb模型时是遮掩过的。

用类似的这种方式，我去实现aes-128-ecb，aes-128-cbc等加密和解密，代码实现就简单太多了。而且有一个特别好的地方。就是在我前一篇openssl中，自己手动去padding的那种方式，加密再解密后，文件的最后虽然不再有乱码，但是会多出NUL字符。比如加密的时候padding了3个0，那么最后解密完后就会多出3个NUL。但是用EVP这种方式，就不再有这个问题了。所以还是用这种方式好