Onion Routing实验

今天开始在六台服务器上Linux采集Onoin Routing的运行throughput数据。在不同的机器上使用gettimeofday来获取时间数据，却发现总是文件接受方的时间数据居然比发送方的时间数据还要早！想了一会明白了，再查看一下不同机器上的系统时间，果然，后者的系统时间比前者的慢。所以解决方案就是把最终的文件接收进程也放到和文件发送进程的同一台机器上啦！

实验效果图：

有关RSA的padding：（http://golang.org/src/pkg/crypto/rsa/pkcs1v15.go）

// EncryptPKCS1v15 encrypts the given message with RSA and the padding scheme from PKCS#1 v1.5.
    18	// The message must be no longer than the length of the public modulus minus 11 bytes.
    19	// WARNING: use of this function to encrypt plaintexts other than session keys
    20	// is dangerous. Use RSA OAEP in new protocols.

而Cryptopp官方也建议使用OAEP padding scheme（http://www.cryptopp.com/wiki/RSA_Encryption_Schemes）

Cryptopp 中，当密钥为1024bit时，OAEP的明文限制长为86bytes，PKCS1v15是128-11=117bytes.

在实验中，发现原来的程序中的加密解密函数中内在的将密文通过加密后HexEncode和解密前HexDecoder使得中间的密文以较好的十六进制呈现，而由于我们这里需要多密文层层加密，所以这样无疑使得明文/密文对应的字节比例扩大，导致程序越来越慢！！

我们仔细的查看了一下代码，首先去除了HexEncode和Hexdecode这一中间过程，但是如果其他地方不加更改会导致如下图所示的bug，这主要是由于C-style的string在复制中遇到\0会自动的认为结束！而我们的密文中很可能就有\0的出现，经过一番尝试，发现cstring转换为string然后不再转换为cstring而直接用string才完成任务！！我们

修改后正确结果：

》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》

Nov 6:

太郁闷了！昨天晚上发现直接使用密文进行多层加密时在第二个节点处解密时就会发生呢个ciphertext invalid错误。晚上回去想了想，猜想估计是由于在向密文文件开头添加address时使用cin流的方式会使得在密文中遇到特殊的编码时>>与<<会不一致，所以一大早就开始赶过来，计划使用C语言中的gets puts以及fread fwrite替代cin流，以为OK了。但下午测试时还是报同样的错误！用diff查看文件到底那里出错了，同时在本机上直接加密密文后立即解密，发现即使是在本机上对密文加密后立即解密得到的仍然是不一样的！这就是说使用密文作为message本身是有问题的！

最后上张实际实验的截图，PS不得不说的是实验说明chaum-MIX/Onion Routing的throughput真的有点低啊～