群发邮件的问题

[logxing]

呵呵，你说的对。
对第一点通过调整pow算法，群发增加pow难度是不是也可以？
第二点我觉得问题也不大，加密后的邮件没有收件人、发件人等任何信息，攻击者基于什么依据非要去破解它呢？

1，原始的方法可以一定程度的抑制垃圾邮件，发送大规模邮件相当于要做pow证明。alt的方法的话，发送者计算量少了很多。

2，alt的方法正文密文只有一份（对称加密），asekey密文有N份（不对称加密）。
同时对这N个不对称密文攻击，理论上比攻击1份特定的不对称密文容易。N个里面破解一个就可以看到邮件正文了。
原始方法的话，即使是同一封邮件，从密文也看不出来。因此无法同时攻击N个。

3，alt的方法会泄漏N这个数字，虽然这个数可能不是很重要。

先想到这些。

我想攻击大多都是非特定目标的，如果截获了一封N值比较大的邮件，
那么由于攻击可能性相对较高，攻击者可能会优先攻击，以期许意外收获。

此外，理论上“群发邮件会比单封发的邮件安全性低”，这在一个系统的设计上是很奇怪的。

[alt]

其实就是这个加密过程:
    auto priv_dh_key = fc::ecc::private_key::generate();  //随机一个非对称密码
    em.dh_key        = priv_dh_key.get_public_key(); //刚才随机出来的公钥保存在邮件中
    auto aes_key      = priv_dh_key.get_shared_secret( to );//刚才随机出的私钥+收件人公钥生成 aes_key，收件人用em.dh_key加上自己的私钥能还原出aes_key
    em.data = aes_encrypt( aes_key, fc::raw::pack(*this) ); // aes_key 用来加密邮件内容，收件人用 aes_key 再解密邮件。我把这里对邮件内容的加密改为对key1的加密。而用key1来加密邮件内容

key2是收件人public key，还是说会根据收件人随机再生成一个aes_key，对key1再做一次aes加密。 为什么要再生成一次AES，感觉没有必要？

如果是后者不太明白为什么还要做一次，看了贴的代码，感觉第二次这个AES_KEY是不是通过收件人信息生成的，后面是不是还应该有一个用public key 做非对称加密的过程?

现在的邮件内容本来就是用aes_encrypt加密的，它对每个收件人随机一个不同的aes_key，所以网络上有很多份不同加密的邮件内容。
我是先用一个随机key( key1)对邮件内容做aes_encrypt加密，再对每个收件人用一个不同的随机key对key1做aes_encrypt加密。这样只有一分加密的邮件了。
不同的收件人用自己的 private key解密就能拿到  key1

    auto priv_dh_key = fc::ecc::private_key::generate();
    em.dh_key        = priv_dh_key.get_public_key();
    auto aes_key      = priv_dh_key.get_shared_secret( to );
    em.data = aes_encrypt( aes_key, fc::raw::pack(*this) );

我理解是不是这样，原来对每个人都发送单独一份邮件内容，N个人网络上就有N份Copy？

楼主的做法加入AES这一环节，相当于把邮件内容加密的过程增加了一个环节，对密钥而非对邮件内容做非对称加密，毕竟密钥会更短，我觉得还是有用的，尤其是以后考虑到邮件列表的支持，收件人可能会很多，但是增加了AES这一环节会不会削弱安全性？

[HackFisher]

key2是收件人public key，还是说会根据收件人随机再生成一个aes_key，对key1再做一次aes加密。 如果是后者为什么要再生成一次AES，感觉没有必要？

看了贴的代码，感觉第二次这个AES_KEY是不是通过收件人信息生成的，后面是不是还应该有一个用public key 做非对称加密的过程?

现在的邮件内容本来就是用aes_encrypt加密的，它对每个收件人随机一个不同的aes_key，所以网络上有很多份不同加密的邮件内容。
我是先用一个随机key( key1)对邮件内容做aes_encrypt加密，再对每个收件人用一个不同的随机key对key1做aes_encrypt加密。这样只有一分加密的邮件了。
不同的收件人用自己的 private key解密就能拿到  key1

    auto priv_dh_key = fc::ecc::private_key::generate();
    em.dh_key        = priv_dh_key.get_public_key();
    auto aes_key      = priv_dh_key.get_shared_secret( to );
    em.data = aes_encrypt( aes_key, fc::raw::pack(*this) );

我理解是不是这样，原来对每个人都发送单独一份邮件内容，N个人网络上就有N份Copy？

楼主的做法加入AES这一环节，相当于把邮件内容加密的过程增加了一个环节，对密钥而非对邮件内容做非对称加密，毕竟密钥会更短，我觉得还是有用的，尤其是以后考虑到邮件列表的支持，收件人可能会很多，但是增加了AES这一环节会不会削弱安全性？

[alt]

呵呵，你说的对。
对第一点通过调整pow算法，群发增加pow难度是不是也可以？
第二点我觉得问题也不大，加密后的邮件没有收件人、发件人等任何信息，攻击者基于什么依据非要去破解它呢？

1，原始的方法可以一定程度的抑制垃圾邮件，发送大规模邮件相当于要做pow证明。alt的方法的话，发送者计算量少了很多。

2，alt的方法正文密文只有一份（对称加密），asekey密文有N份（不对称加密）。
同时对这N个不对称密文攻击，理论上比攻击1份特定的不对称密文容易。N个里面破解一个就可以看到邮件正文了。
原始方法的话，即使是同一封邮件，从密文也看不出来。因此无法同时攻击N个。

3，alt的方法会泄漏N这个数字，虽然这个数可能不是很重要。

先想到这些。

[alt]

好的，我去改下标题，可怜的英语
其实技术上很简单，不用讨论技术问题，只要从用户的角度把这个事情解释清楚就好了，主要是对存储和带宽资源占用的优化。

标题 Improve for mail to a group  改成“Improvement for group mail”吧，否则老外一看题目不知道什么意思，估计就不读正文了

等开发者去解答吧，主要是一般人答不了，所以不回复。要不我去顶一个

[logxing]

1，原始的方法可以一定程度的抑制垃圾邮件，发送大规模邮件相当于要做pow证明。alt的方法的话，发送者计算量少了很多。

2，alt的方法正文密文只有一份（对称加密），asekey密文有N份（不对称加密）。
同时对这N个不对称密文攻击，理论上比攻击1份特定的不对称密文容易。N个里面破解一个就可以看到邮件正文了。
原始方法的话，即使是同一封邮件，从密文也看不出来。因此无法同时攻击N个。

3，alt的方法会泄漏N这个数字，虽然这个数可能不是很重要。

先想到这些。

[ripplexiaoshan]

标题 Improve for mail to a group  改成“Improvement for group mail”吧，否则老外一看题目不知道什么意思，估计就不读正文了

等开发者去解答吧，主要是一般人答不了，所以不回复。要不我去顶一个

[Musewhale]

虽然我不懂具体的技术问题
但是我觉得楼主的思路是对的

[alt]

现在的邮件内容本来就是用aes_encrypt加密的，它对每个收件人随机一个不同的aes_key，所以网络上有很多份不同加密的邮件内容。
我是先用一个随机key( key1)对邮件内容做aes_encrypt加密，再对每个收件人用一个不同的随机key对key1做aes_encrypt加密。这样只有一分加密的邮件了。
不同的收件人用自己的 private key解密就能拿到  key1

    auto priv_dh_key = fc::ecc::private_key::generate();
    em.dh_key        = priv_dh_key.get_public_key();
    auto aes_key      = priv_dh_key.get_shared_secret( to );
    em.data = aes_encrypt( aes_key, fc::raw::pack(*this) );

我理解是不是这样，原来对每个人都发送单独一份邮件内容，N个人网络上就有N份Copy？

楼主的做法加入AES这一环节，相当于把邮件内容加密的过程增加了一个环节，对密钥而非对邮件内容做非对称加密，毕竟密钥会更短，我觉得还是有用的，尤其是以后考虑到邮件列表的支持，收件人可能会很多，但是增加了AES这一环节会不会削弱安全性？

[HackFisher]

我理解是不是这样，原来对每个人都发送单独一份邮件内容，N个人网络上就有N份Copy？

楼主的做法加入AES这一环节，相当于把邮件内容加密的过程增加了一个环节，对密钥而非对邮件内容做非对称加密，毕竟密钥会更短，我觉得还是有用的，尤其是以后考虑到邮件列表的支持，收件人可能会很多，但是增加了AES这一环节会不会削弱安全性？

[alt]

现在群发邮件的实现方式是对每个收件人单独发送一个加密邮件到p2p网络上，这样导致对带宽、硬盘的很大浪费。

所以我对此做了一些修改
1. 随机产生一个aes key，用这个aes key加密邮件内容。
2. 增加一块数据，把这个 aes key用收件人的公钥加密，保存这个加密后的aes key列表，这样只有列表中的人才能得到  aes key并解密邮件。
只需要把这个邮件发送到网络，所有收件人都能收到了。

但是这个新增加的数据块导致与旧版本的bts不兼容，无法互相发送邮件，所有人都升级到新版本才能没问题。

所以我没把这个修改提交到 github，只在论坛提了下建议，不知道为什么没人回复，是不是我英文太烂了啊。大家觉得这个修改有用吗？如果觉得有用去帖子下帮我用英文再补充一下吧。
https://bitsharestalk.org/index.php?topic=2177.0