关于加密通信奇怪问题?

Question

本帖最后由 VisualEleven 于 2011-05-03 08:32:25 编辑

Answer 1

经过网络，自序会重新排列的，解密失败就是一种情况 密钥错了！你检查的是不是你的密文啊？ 检查密钥才是关键！DES还是很常用的加密。

Answer 2

多谢chenjiawei007回复，密钥前后使用的是相同的密钥。
我检查了密文缓冲、明文缓冲等涉及的相关所有内存数据。通过发送前内存字节数据和接收到的内存字节数据相比，二者完全一致。

Answer 3

加密后，发送前，数据用base64或其他方法编码一下是不是好点

Answer 4

本帖最后由 VisualEleven 于 2011-05-03 09:57:27 编辑

  

Answer 5

base64对传输没有影响。LZ已经检测过密文是正确了对吗？LZ可以把传输后的密钥，放到本地的密文中测试，是否能解成功，如果密文和密钥都正确，解密怎么会失败呢？
仔细点，只要一个字节错了，你的解密就失败了。我觉得还是有些地方被你疏忽了。

Answer 6

我接触到的是，java编译的数组到C中使用，会产生大小端转换问题，而TCP传输是不会的。有可能出了一种很弱智的错误，就是发送端字符串的结束符接收端无法解密，比如“\r\n”或“\0”等，我曾经就遇到过类似的问题，字符串发送端与接收端表面看起来完全一致~

Answer 7

我自己的网络引擎.  加了一层AES CFB_Mode 两端收发都没问题. 你要仔细检查.99.9%都是自己的问题.

Answer 8

1，检测密文正确（字节对比）
2，对于密钥，没有进行传输，两端都是定义的宏#define DES_ENC_KEY _T("123abc")
，现在如果把这个DES_ENC_KEY放到加密函数体内就没问题，放到参数就解密失败

Answer 9

发端明文：
0x0012D0C8  48 65 6c 6c 6f 20 53 65 72 76 65 72 00 00 00 00 00 00 00 00 00 00  Hello Server..........
0x0012D0DE  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ......................
发端密文：
0x0012E1E8  b6 38 47 eb 0b 0f 67 1e d2 33 c0 cb f7 ea 37 ca 00 00 00 00 00 00  .8G...g..3....7.......
0x0012E1FE  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ......................
收端密文：
0x01FEEC68  b6 38 47 eb 0b 0f 67 1e d2 33 c0 cb f7 ea 37 ca 00 00 00 00 00 00  .8G...g..3....7.......
0x01FEEC7E  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ......................
收端解密结果：
0x015E21D0  03 9b 32 bc 88 a6 82 49 3c bc 39 f4 ab f6 5b 1e 00 00 00 00 00 00  ..2....I<.9...[.......
0x015E21E6  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ......................通过上面调试数据可以看出，加密密文在发送和接收过程中完全相同。1，如果不经过网络传输即发送加密后接着解密，解密正常。（此时解密代码为直接收端拷贝过来的）
2，如果DES加密KEY不放在参数传递，而直接在函数体内定义，解密正常。如果作为参数传递，解密失败。
3，通过内存比较，两端加密数据和DES KEY都完全相同但就是出现以上问题，令人头大

Answer 10

每个包都进行了CRC校验，确认数据一致，具体可见上一楼的调试结果

Answer 11

DES不支持流式加解密,关键数据块加解密,非关键数据加解密浪费资源.

Answer 12

1，不理解“流式加解密”，我将数据拷贝到字节数组（缓存），再从字节数组加密到另一缓存后发送，这种方式DES不支持？但只要不发送，加密后在本地解密即成功。
2，如果是机器字节顺序问题，那有什么办法可以解决？