LWN: Benenios - 用于不公开投票的系统！

关注了就能看到更多这么棒的文章哦～

Belenios: a system for secret voting

By Jake Edge
March 8, 2022
DeepL assisted translation
https://lwn.net/Articles/887077/

最近关于 Debian 一般决议（GRs）改用秘密投票（secret voting）的讨论，自己也变成了一个 GR，提出了一个主题就是收集人们希望看到的 Debian 投票系统未来该拥有的特性。其中提到了一个系统，名为 Belenios，它提供了一个开源的 "可验证的在线投票系统（verifiable online voting system）"。无论 Debian 是否选择改用秘密投票，Belenios 对那些可能正在寻找满足他们自己投票需求的项目和组织来说，似乎可能是一个挺好的方案。

Background

正如 Debian GR 的讨论和来回修正中所强调的，秘密投票对不同的人来说其实理解都不一样。但一般来说，人们首先希望选举是可信的，这意味着投票者（以及会受到最终结论影响的人）需要了解并相信这个投票和统计结果的背后机制。有一些加密协议可以用来从技术上解决部分或所有这些问题，但有一些社会方面以及其他方面的考虑，从而导致它们在实际选举中可能是无法使用的，至少对于各级政府举行的选举来说还是不够的。我们对 2020 年 linux.conf.au 上的一次谈话的报道（https://lwn.net/Articles/810465/ ）可以帮助大家了解其中的一些原因，也介绍了投票系统的加密协议实现得并不好。

Debian 目前有两种投票方式：一种是每年一次的 Debian 项目负责人（DPL, Debian project leader）选举，今年的 DPL 选举于 3 月 5 日开始；另一种是跟 Debian 开发者（DD）提出需求所发起的 GR。只要有六个开发者就可以通过 GR 针对任何一个问题来投票了，因此只要有一个赞助商再加上五个跟随者就可以满足要求了。所有的投票都是通过 PGP 签名的电子邮件进行的，投票结束后，选票和投票人名单会公布出来供所有人查看。不同的是，DPL 的选举结果不告知投票者各自的选票内容，而 GR 的投票者和他的选票内容一一对应的，所以每个人都可以看到每位投票者对选票上的选项进行排序的情况。

Debian 使用 Condorcet 投票系统，允许选民对候选人或提案进行排序，并有一些特定的机制来处理低概率会出现的一些循环结果。这已经是一个相当复杂的方案，需要选民进行一些复杂的思考，来了解它的工作原理。还有一些其他形式的排名投票工具已经被用于政府（和其他）选举中，从而试图避免一些技术含量不高的选举的复杂性。

对于这两种类型的 Debian 选举，任何人都可以使用公布的选票来验证所公布的结果是否与所投的票数相符，任何 DD （Debian Developer）也可以直接看到他们记录的票数与他们在 GR 选举中的投票方式是相符的。对于 DPL 选举，当正确签名的选票通过电子邮件提交时，devotee 投票收集系统会返回个人的秘密编号（secret code）给投票者，它可以配合统计表中报告的哈希值一起来验证他们的投票是否包含在选票中了。在这两种情况下，没有投票的开发者可以通过检查 DPL 选举的单独选民名单或决议的统计表来确保没有记录他们的投票。所有这些都增加了 Debian 投票的透明程度。

同时，一些选民对于把他们的选票与他们自己的名字一起公布在 GR 上感到不舒服，特别是一些有争议的决议，例如 2021 年关于 Richard Stallman 回到 FSF 董事会的立场声明的 GR 就是一个例子。于是就引出了这次的提议（resolution），希望能改变提议投票结果的报告方式，就像现在的 DPL 选举的方式一样，不要再把选民和他们的选票之间的联系公布出来。

这个秘密投票提案最初版本中的多个要点里，还有要求把通过电子邮件投票的要求从 Debian 章程中删除（目前还有另外两种投票方案，后续会作为 GR 的一部分进行投票来决定）。这就可以让项目秘书（project secretary）尝试其他的投票机制来增强目前基于电子邮件的系统；然而，一些开发者担心这也可能会导致今后取消通过电子邮件投票的功能。长期秘书（longtime secretary） Kurt Roeckx 针对后续可能会取消电子邮件投票要求，因此计划先研究一下 Belenios。

Belenios

Belenios 系统似乎提供了支持 GRs 秘密投票的人的大部分需求。它是由 Stéphane Glondu 开发的，他是一位 Debian 开发者，此系统通过同态加密（homomorphic encryption）为投票提供隐私性以及可验证性。使用该机制的话，就没有人可以真正看到任何一位选民的选票内容，投票结果可以在不解密选票的情况下就统计出来。其主页上对系统的可验证性（verifiability）描述如下：

每个选民都可以检查自己的选票是否被计算在内，而且只有符合条件的选民可以投票。[可验证性]依赖于投票箱（ballot box）是公开的（选民可以检查他们的选票是否已经收到）以及统计结果是可以公开验证的（任何人都可以重新计算选票）来实现。此外，选票是由选民的凭证来签名的（也就是只有符合条件的选民才能[投票]）。

"how it works" 的网页给出了关于这个过程的更多细节，Belenios 的论文里更加详细。选民有一套用在网页界面的登录凭证（用户名/密码），以及一个单独交流的凭证，即用户的私人 ElGamal 密钥。服务器会存储相应的公钥，选民做出选择后在客户端里使用私钥对选票进行加密，并将其发送到服务器。

服务器使用公钥来验证选票，使用客户端提供的零知识证明（zero-knowledge proof），来证明选票是有效的（比如说只包含那些选择了适当数量的选项的投票）。零知识证明是一种证明断言（assert）的方法，除了能证明断言是真实之外，不会把给出验证证明的实体的任何额外信息暴露出来。在这种情况下，既可以证明选票的有效性，又不会给服务器任何关于选票中实际投票选择内容的信息。相关的维基百科链接中有一些 "现实世界" 的例子，以及零知识证明概念的数学背景。

等服务器验证了选票之后，它就会在选举的公共信息页面上列出该选票的 "追踪号码（tracking number）"（加密过的选票的一个哈希值）。选民可以在该页面上查找到他们的追踪号码，并在本地使用他们的私钥就可以查看到他们在选票上的实际投票记录。其他人无法解密这个选票。这一对密钥通常是由服务器生成，私钥在发送给用户后就被服务器丢弃。但也可以是由另一个实体来生成密钥并将两部分分别传送给各自的所有者。安全分发私钥显然是一个重要要求。不应该选择使用未加密的电子邮件来发送。

选举的结果由统计过程（tally process）决定，它的描述如下：

默认情况下，选举服务器会存储用于解密的密钥。加密方案有一个特殊的属性，称为同态性（homomorphism）：从加密的选票中，任何人都可以不利用任何密钥就通过组合密码文本来计算出加密过的结果（每个候选人的票数之和）。这样一来，只有最终的这个加密过的结果需要被解密，这就保证了投票的隐私性：单个选民的具体选票永远不会被解密。

选举的最终加密结果可以由一个或多个被指定为解密机构的选举管理员来进行解密；所有这些机构需要配合来解密最终结果。这里利用了另一个零知识证明来证明这个加密过的加密结果就是投票的结果，同样不需要对单个选票进行解密。在某种程度上来说，这听起来像是 "神奇的密码学仙法（magic cryptographic fairy dust）"，但其底层所依据的原理已被建立好并得到了充分的理解，至少在密码学领域是这样认为的。

用于审计和验证（auditing and verifying）过程的工具也在 Belenios 代码仓库中，尽管该项目欢迎其他人创造新的工具来配合该系统使用。协议规范 "应该提供了所有必要的细节（当然，也欢迎提出问题）"。Belenios 在线服务器可用来进行多达 2500 名选民的选举，当然，也可以在其他的个人服务器上运行其代码来创建自己的服务器。FAQ 中有关于如何实现这个做法（当然也包括许多其他主题的答案）。网站上似乎没有提到的一件事是，是否对 Belenios 代码进行过安全审计（security audit）或正式验证（formal verification）；我们感觉在它被采用之前，至少对某些类型的投票来说可能还是要求这个系统的代码先要进行安全审计或正式验证的。

进行投票所选择的默认机制是一种批准投票（approval voting）的形式，投票者可以选择他们认为可以接受的一个或多个候选人："例如，她可以在 10 个候选人的名单中选择 3 到 5 个候选人"。对其他投票机制（包括 Condorcet 投票）的支持正在开发中。

Back to Debian

这个想要从章程（constitution）中删除 "通过电子邮件方式" 这一要求的想法，是 Sam Hartman 最初提案的一部分（GR 页面上的提案 A），一些人对此并不支持，尽管他们可能也倾向于使用秘密投票方式。于是这就产生了提案 B，它只采用了秘密投票的语言，不再提及 "电子邮件" 相关的要求，并且没有像提案 A 一样添加关于推翻或取代秘书的两项规定。还有提案 C，它是表示仍然希望决议要进行公开投票，之所以加上这个选项，部分原因是因为其他提案中没有说明秘密投票系统的实施细节。

如果提案 B 得以通过，起码我们可以在 Belenios 中加入电子邮件投票收集机制，这似乎是合理做法。它可以使用 Debian 开发者在发行版钥匙圈（keyring）上的公共 PGP 密钥来加密 ElGamal 私钥，从而创建正确签名过的选票，这些密钥可以被发送给每个开发者。或者，有可能把 Belenios 修改为直接使用开发者的 PGP 密钥签名过的电子邮件。这可能会让一些投票者使用 Belenios 的网络应用来进行投票，而另一些人则像往常一样使用电子邮件。显然，如果提案 C 获胜，就不需要任何改动了。

用于 DPL 选举的系统有一些已知弱点，用户可能被迫透露他们的秘密编码，或者一群用户可能合作来把他们的投票 unmask 掉，这两种情况都会破坏选票的保密性。这些问题在 Belenios 中并没有得到真正的缓解，因为 ElGamal 私钥扮演着与 devotee secret code 相同的角色，但 Debian 发行版已经在这些可能的攻击下生存了很长时间了，不用太担心。

关于秘密投票决议的讨论期一直持续到 3 月 11 日，因此在此之前，其他提案可能会被加入到投票中。两周的投票期大概会在此后不久开始。看起来至少有可能，甚至是非常有可能的是，提案 A 在清理一些不相关的模糊之处（secretary overreach）的方面迈的步子有点太大了；此外，取消电子邮件方式对一些人来说也可能是太过了。似乎有合法的理由不对 GR 进行公开投票，即使最有争议的往往是政治问题，而不是技术或 Debian 内部的问题，许多 DD 认为这些问题根本就不应该被投票。无论如何我们应该在三月底左右知道 Debian 项目对秘密投票的观点。如果最终选择了采用某种形式进行秘密投票，那么也许 Belenios 可以被修改来适合这种需求。

全文完
LWN 文章遵循 CC BY-SA 4.0 许可协议。

欢迎分享、转载及基于现有协议再创作～

长按下面二维码关注，关注 LWN 深度文章以及开源社区的各种新近言论～