从技术上讲，您的解决方案与CGS97 （注意日期）非常相似，它是Helios及其后代的基础。作为一般方法，这是非常合理的，但完全缺乏防止投票和贿赂/威胁（文献中的收据自由和强制抵抗）：

缺少 RF 示例：假设我承诺如果你投票给我的候选人，给你 100 美元，并向我展示你使用的随机性（即收据）来加密你的选票作为证据。这是教科书 Helios（在原始论文中提到）的一个已知问题，在后来的作品中得到了不同程度的修复。

你建议使用区块链来实施公告板是合理的，但我认为活跃在该领域的人都知道。

您的解决方案还有一些问题：

• 复制其他人的选票是微不足道的。这被认为对隐私不利。延展性攻击也是如此。
• 要求一个人的选票总和为 1 是不够的。假设我给候选人 X -100 票，给候选人 Y +101 票。
• 结合以上，将所有张贴在板上的选票加起来。假设有n个。求和。这将产生一个总计为-n的选票。为您的候选人添加n+1票。您现在有一张选票否定所有先前的选票并将他们的所有选票转移给您的候选人。
• 上述大部分问题都是通过零知识协议解决的，证明选票的各个部分是 0/1，除了总和为 1 外，还有一些不可延展性要求。
• 让当局为每个选民解密一个小额金额可能是低效的。另外，您如何验证他们的行为是否正确？如果你的答案是 ZK，为什么不把它交给选民呢？
• 当您谈论盐和加密时，我认为您的意思是 IND-CPA。不过，您可能需要 NM-CPA（也可以查看 IND-CCA，但这不是绝对必要的）。

回到大局，我们还想考虑从受感染的 PC 上投票，有一个人们可以并且将遵循的验证过程，选举会吸引国家支持的对手的事实，以及在失败将是极其昂贵的（就公众信任和美元而言）。

TL;DR：该领域有大量文献（展位内和互联网），但这也是一个非常困难的问题。

你提出的这个算法肯定是一个很好的算法。但也许它缺乏隐私的概念。这也许就是为什么整体避免电子投票的原因。

这里的隐私是指用户可能发送的一组响应/纯文本。{0,1}。这指的是“已知的纯文本攻击”。一个对手，将一个人置于中间攻击可能会拦截密码。现在，知道明文、公钥和密文，他可以使用许多复杂的工具，或者通过简单的暴力攻击破解盐以及用于加密的密钥！（当然，破解所花费的时间肯定取决于密钥和盐的长度）。