今天给团队调试一个错误,概率性的加密的数据没法做解密,现象是解密出来的结果和源数据长度不一致,很奇怪的现象,因为加密使用的数据是随机的,所以使得问题出现时表象是概率的问题;
因为初次做加解密算法相关的项目,碰到这样的问题,首先是单步把解密流程过了一遍,发现解密没有问题,能正常的解密,但解密出来的长度就是不对,分析才发现加密后的数据的长度也不正常,所以考虑是加密源数据的问题,通过分析,才发现一个二进制的源数据经过转换为字符串对象string后使用openssl的接口完成的加密处理,导致string对象比原来的字节数组长度要短,短的原因是字节数组中包括了'\0'结束符,原以为是openssl的接口实现存在这样的问题,建议使用方将加密的字节数组将0字符都过滤一遍,但想来还是不正确,原来char*的数组转换为string存在一个陷阱:见“https://blog.csdn.net/b876144622/article/details/79972498”;所以还是转换的不合适,修改前后的代码如下:
//原来的代码
#if 0
char *temp = (char *)malloc(length + 1);
if (temp == NULL){
ALOGE("encrypt failed, temp == NULL");
ShutdownOpenABE();
return -1;
}
memcpy(temp, rawData, length);
temp[length] = '\0';
string inputStr = temp;
FREE(temp);
#else
//修改的代码
string inputStr ;//= temp;
//convert temp to string
for (int i=0; i<length; i++){
if (i < length-1 && rawData[i] == '\0'){
cerr << "rawdata:" << rawData <<", length:" << length<<endl;
//ALOGE("rawdata:%s, length:%d, i:%d", rawData, length, i);
//return PARMETER_ERR_CONTENT;
}
inputStr += rawData[i];
}
#endif//end
参考:https://blog.csdn.net/analogous_love/article/details/71744427
还有一种方法是使用assign方法进行赋值,需要指定赋值字节数组的长度,否则以0做结束符计算长度,更简洁些;
inputStr .assign(rawData, length);