面向增量同步的分块加密算法研究(2)

　　这一部分加解密的主要过程：
　　加密：
　　1）首先根据用户输入的口令生成AES加密密钥；
　　2）对需要加密的文件进行分割，得到参数：N, BREAKPOINTS;
　　3）将上一步得到的N写入到加密的文件中；
　　4）对每一块进行加密，得到那一块的密文，依次按照：明文长度、密文长度、密文来写入到加密文件中；注：由于写入的数据是2进制的，所以显示出来按照ASCII码，不是相对应的数字，而是ACSII码对应的符号，加密过程中每一块都会打印出密文大小用以检查；
　　5）清除以上过程中使用到的缓冲区。
　　解密：
　　1）依旧首先根据用户输入的口令生成AES解密密钥；
　　2）首先读出原始文件分割块数N；
　　3）依次读出每一块的明文长度、密文长度、密文，将密文存放在BUFF中；
　　4）对密文进行解密，然后根据明文长度，读入到新建立的解密文档中，解密过程中会打印相应的解密后的块长度来检查；
　　5）清除使用到的缓冲区。
　　之所以使用EVP是因为EVP包含了OpenSSL加密库里所有算法的函数，这使得我们如果想使用相同的代码及不同的加密算法对数据进行加密和解密，只需要在初始化参数的时候做很小的改变。由于在初始化密钥函数，也就是将用户输入口令转变为标准AES密钥过程中的标准密钥结构体evp_cipher_ctx_st非常复杂，我们就不列举其中包含的所有成员及其意义了。这里需要指出的是加解密函数都是由三部分函数组成的：初始化、更新和最终步骤。以加密为例：
　　EVP_EncryptInit_ex(e, NULL, NULL, NULL, NULL);
　　EVP_EncryptUpdate(e, ciphertext, &c_len, plaintext, *len);
　　EVP_EncryptFinal_ex(e, ciphertext+c_len, &f_len);
　　下面我们来解释一下这三个函数到底是做什么的：
　　1) EVP_EncryptInit_ex()会建立一个密文空间，这个密文空间的类型从ENGINE类型的指针*impl中独取出来。在调用这个函数之前，我们必须要ctx已经进行了初始化。我们这里采用的是NULL所以将会采用缺省的实现方式。实际用于key和IV的比特数会根据密文来确定。
　　2) EVP_EncryptUpdate()将缓冲区in里面长度为inl比特的内容加密后写入out缓冲区，这个方法会被多次调用来加密连续几块的数据。由于被写入的数据大小取决于加密数据的块排列，所以被写入数据的大小可能从0到inl + cipher_block_size–1，因此outl拥有足够多的空间，最终真正写入的密文的长度会存放在outl当中。
　　3)缺省状况下我们会进入EVP_EncryptFinal_ex()方法，它负责加密“最终”数据——也就是最后留在某个块内的数据。它使用的是标准快填充[9]。这部分加密后的数据会写入到out当中，此时out当中应该还可以写入一个整块的大小的内容。这个方法被调用之后，加密操作就结束了，EVP_EncryptUpdate()方法也不允许再次被调用了。
　　4封装DLL
　　DLL封装的内容也就是函数的主体在xEnc.cpp中，xEnc.cpp部分有两个外部程序可以引用的部分：用于加密的函数和用于解密的函数，每个函数都是有三个输入的接口。加密部分的流程如图1所示。
　　1）检查用户键入的原文件是否存在（错误返回值：1）；
　　2）根据用户口令生成标准AES密钥（错误返回值：-1）；
　　3）打开原文件进行读取（错误返回值：-1），同时显示打开文件的基本属性（大小、分割块数等）；
　　4）写入当前分割块数；
　　5）写入第一分块的明文长度、密文长度并对此分块进行加密，然后写入长度为JO.ptr[0]+1的密文到秘文文件中；
　　6）类似上一步骤，写入第N分块的明文长度、密文长度并对此分块进行加密，然后写入长度为JO.ptr[n]-JO.ptr[n-1]的密文（因为这里是指逻辑上的第N块，而程序中是从i=0开始算起，故长度写法不一致）到秘文文件中，直到整个内容都已经写完为止。
　　7）清空加密过程中使用的内存和EVP_CIPHER_CTX。
　　
　　图1加密流程图
　　解密部分的流程是：
　　1）检查用户键入的秘文文件是否存在（错误返回值：1）；
　　2）根据用户口令生成标准AES密钥（错误返回值：-1）；
　　3）读取文件分块块数n；
　　4）读取第一分块的明文、密文长度，存入临时变量中，再根据这两个数值，读取相应长度的密文，然后解密这部分内容，写入到输出文件当中；
　　5）类似上一步骤，读取第N分块的明文、密文长度，存入临时变量中，再根据这两个数值，读取相应长度的密文，然后解密这部分内容，写入到输出文件当中，直到所有内容写完为之；但这里需要指出的是：考虑到每次调用解密的函数，都会改变读入的密文长度，而这个长度需要用于之后文件的定位，所以设置了一个累加器：CLENSUM =∑ PLEN[i].cipherlen；这样就可以得知第N次需要读取的位置是：sizeof(chunknum)+sizeof(length)i+CLENSUM
　　6）清空解密过程中使用的内存和EVP_CIPHER_CTX。
　　5仿真、比较与性能分析
　　首先说明一下两个文件相互之间的两个补丁不一定是一样的，也就是说，补丁是“分方向”的。原文补：以原文件作为原，生成相对于新文件的补丁；新文补：以新文件作为原，生成相对于原文件的补丁；原密补：以原密文作为原，生成相对于新密文的补丁；新密补：以新密文作为原，生成相对于原密文的补丁。
　　目标：在原文改变不是非常大（比如全文的1/2）的情况下，原密文补丁和新密文补丁不是非常的大，这样文件的分割才有意义。仿真结果如表1所示。
　　表1仿真结果
　　
　　TXT(单位：KB)
　　使用xDelta来比对文件：
　　
　　使用rdiff (python)来比对文件：
　　
　　
　　对文件的修改包括三个方面，替换，删除和增加。由上面几组数据可以看出，不论对文件内容的替换，删除还是增加，只要原文件的改动不大，原密文补丁和新密文补丁的大小变化在可以接受的范围，这样我们就可以实现增量加密，提高网盘用户数据同步的效率。 (责任编辑：论文发表网)转贴于八度论文发表网: http://www.8dulw.com(论文网__代写代发论文_论文发表_毕业论文_免费论文范文网_论文格式_广东论文网_广州论文网)