52 Things: Number 52: Pick an advanced application concept such as e-Voting, Auctions or Multi-Party Computation. What are the rough security requirements of such a system?

This is the last of our 52 things which we think every first year PhD student in Cryptography should know. And as you may have gathered over the last 52 posts, we expect students to know all sorts of aspects ranging from theory to practice. But the key thing is that you need to consider in cryptography not only security against players who play by the rules, but also security against players who do not play by the rules. Lets examine this in the context of Voting, Auctions and Multi-Party Computation.
这是我们认为每个密码学博士一年级学生都应该知道的52件事中的最后一件。正如你在过去52篇文章中所收集的那样，我们希望学生们了解从理论到实践的各个方面。但关键是，在密码学中，你不仅需要考虑对遵守规则的玩家的安全性，还需要考虑对不遵守规则的参与者的安全性。让我们在投票、拍卖和多方计算的背景下研究一下这一点。

Let us first discuss what we mean by these three applications. In voting we have voters who select candidates according to some voting scheme (first-past-the-post, alternative-vote, approval voting or whatever). The vote should remain secret, only valid voters can vote, only one vote per candidate is allowed, votes must be valid (for a real candidate for example), the final result must be correct, voters must not be able to be coerced, the list of security requirements are quite long.
让我们首先讨论一下这三个应用程序的含义。在投票中，我们有选民根据一些投票方案选择候选人（得票最多、替代投票、赞成投票或其他）。投票应保密，只有有效的选民才能投票，每个候选人只能投一票，选票必须有效（例如，对于真正的候选人），最终结果必须正确，选民不能被胁迫，安全要求清单很长。

For auctions we may want bids to be private, we may not trust the auctioneer, there may be multiple items, with multiple possible final prices, the selection of the winning bid/price will be due to some algorithm, the final output may need to be auditable.
对于拍卖，我们可能希望出价是私人的，我们可能不信任拍卖师，可能有多个项目，有多个可能的最终价格，中标/价格的选择将取决于某种算法，最终输出可能需要可审计。

For Multi-Party Computation (by which we mean a computation of a function on the private inputs of a set of parties) the security requirements are simpler in that we want only the output of the function to be revealed, and nothing about the inputs (bar what can be computed from the output). However, whilst this is a simpler goal, the functionality is wider than for auctions and voting in that we require ANY function should be able to be computed.
对于多方计算（我们指的是在一组方的私有输入上计算函数），安全性要求更简单，因为我们只希望显示函数的输出，而不希望显示输入（除了可以从输出中计算的内容）。然而，虽然这是一个更简单的目标，但其功能比拍卖和投票更广泛，因为我们需要能够计算任何函数。

What makes these operations interesting is that we EXPECT the bad guy to be part of the protocol. Compare this with simple encryption, where a message from Alice to Bob is sent. In encryption we expect Alice and Bob to be trustworthy and the bad guy is the person on the outside looking in. For voting, auctions and MPC we do not trust anybody, the bad guy could be a voter trying to cast multiple votes, a vote tallier trying to count the votes incorrectly, a bidder trying to made a winning bid which is not the highest, or an auctioneer trying to work out what the value of a non-winning bid is etc.
让这些操作变得有趣的是，我们期望坏人成为协议的一部分。将其与简单加密进行比较，在简单加密中，Alice向Bob发送消息。在加密技术中，我们希望Alice和Bob是值得信赖的，坏人是外面的人。对于投票、拍卖和MPC，我们不信任任何人，坏人可能是试图投多张票的选民、试图错误计票的计票员、试图做出不是最高的中标的投标人，或者试图计算出未中标的价值的拍卖师等。

The parties in the protocol do not even need to behave by the rules, i.e. follow the protocol. They could send messages which are produced incorrectly but which "look like" valid ones, but which later produce incorrect results for the protocol. We need to protect against this so called "malicious" behaviour.
协议中的各方甚至不需要遵守规则，即遵守协议。他们可能会发送错误生成的消息，但这些消息“看起来像”有效消息，但后来会为协议生成错误的结果。我们需要防范这种所谓的“恶意”行为。

There might be a group of bad guys working together to defeat the system, we need to determine how big a coalition of bad guys we can tolerate in our protocol. In MPC there is a big difference between the case when we have an honest majority and a dishonest majority. For honest majority protocols we can ensure that the honest parties always end up with a valid function output. For dishonest majority protocols we cannot stop a dishonest party from terminating the protocol for everyone.
可能有一群坏人在一起努力击败这个系统，我们需要确定我们在协议中可以容忍多大的坏人联盟。在MPC中，当我们拥有诚实的多数和不诚实的多数时，情况有很大的不同。对于诚实多数协议，我们可以确保诚实方最终总是得到有效的函数输出。对于不诚实的多数协议，我们无法阻止不诚实的一方为每个人终止协议。

We need to protect against the problem of who goes first or last. A property in the literature called "fairness". For example suppose we have an election with three voters; A, B and C. Suppose the votes are encrypted, player C can ensure that the candidate voted for by A wins (and hence find out who A voted for) by replicating A's vote. This should be protected against.
我们需要防止谁先上场或最后上场的问题。文献中称之为“公平”的一种性质。例如，假设我们有三个选民参加选举；A、 B和C。假设选票是加密的，玩家C可以通过复制A的选票来确保A投票给的候选人获胜（从而找出A投票给谁）。这应该得到保护。

The adversary may have a set of parties who it controls at the start of the protocol, a so-called static adversary. Or perhaps as the protocol proceeds the adversary decides which parties it wants to corrupt, a so-called adaptive adversary.
对手可能有一组在协议开始时控制的各方，即所谓的静态对手。或者，也许随着协议的进行，对手决定要腐蚀哪一方，即所谓的适应性对手。

As one can see there are a multitude of security concerns one may have in such advanced protocols, and indeed a multitude of security results. Indeed each application domain gives rise to different security properties that one may require. Given the wide range of possible application protocols this means a never ending series of problems for cryptography to solve; and thus a never ending supply of problems for cryptography PhD students to solve.
正如人们所看到的，在这样的高级协议中可能存在大量的安全问题，实际上还有大量的安全结果。事实上，每个应用程序域都会产生可能需要的不同安全属性。鉴于可能的应用程序协议范围广泛，这意味着密码学要解决的一系列问题永无止境；从而为密码学博士生解决源源不断的问题。

3cH0_Nu1L

52 Things: Number 52: Pick an advanced application concept such as e-Voting, Auctions or Multi-Party Computation. What are the rough security requirements of such a system?

公告