java - Java中的确定性RSA加密

Question

这是我在此站点上的第一个问题，我对RSA仅具有基本的数学理解，请耐心等待! :)

我正在为大学的最后一个项目编写Java Web应用程序。它是基于Web的安全投票系统“Pret-a-voter”的实现，适用于听说过的人。

从本质上讲，我的问题是我希望能够聘请一位能够担任审计员的人:

源字节数组(要加密的纯文本)

RSA公钥文件

是“目标”字节数组，这是我在给定明文和公钥

的情况下自己计算密码数据的结果

然后，我希望审核员能够使用前两个项目执行加密，并确信第三个项目是结果。因此，我需要加密为 确定性，即每次重复使用相同的明文和公钥进行的加密时，都生成相同的密码数据。

(注意-我正在这个项目中处理非常小的数据块-根本不涉及对称加密...我知道这是对RSA的“有趣”使用!)

无论如何，我发现在Java中，使用

cipher = Cipher.getInstance("RSA");

使用默认的随机填充方案，开销为11个字节(因此，使用2048位 key 对时，可以加密2048/8-11 = 245个字节)。重复对同一明文进行加密会生成不同的密文，这显然不是我想要的ECB模式。

我的问题是- 我应该使用以下内容吗？

cipher = Cipher.getInstance("RSA/ECB/NoPadding");

我在很多地方都读过RSA不填充而不安全。这仅仅是因为攻击者可以构建纯文本/密文字典吗？这是我为了使审核员能够验证我的加密而需要的确定性加密的副作用，并且在我的方案中，审核员是受信任的，因此可以。

我的问题的第二部分与Java有关。如果我确实如上所述使用RSA/ECB/NoPadding，我相信我可以提供(例如)长度为128(对于1024位RSA key 对)的源字节数组，并对其进行加密以获得另一个长度的字节数组。 128.如果我随后尝试使用另一个1024长度的公共(public) key 再次对其进行加密，则会得到

javax.crypto.BadPaddingException: Message is larger than modulus

有人知道为什么吗？

编辑-使用NoPadding加密并不总是会生成此异常-这很气质。但是，即使加密没有生成此异常，解密也会生成此异常:

javax.crypto.BadPaddingException: Data must start with zero

非常感谢您阅读本文!任何帮助将不胜感激。

编辑-抱歉，我最初的问题不是很清楚我想要做什么，所以这里有一个[尝试]的解释:

纯文本是选举中的选民投票。

Pret-a-voter的目的是在不牺牲选民的 secret 性(等)的情况下进行端到端可验证。投票后，将为选民提供一张收据，供他们用来验证自己的投票已正确记录，并且稍后将向他们显示其投票未被篡改。投票人会将收据上的信息与网上发布的相同副本进行比较。

但是，任何投票人都不可能证明自己的投票方式(这可能会导致胁迫)，因此该信息不是明文，而是投票的加密副本。

实际上，纯文本被加密了四次，使用四个不同的非对称 key -由两个不同的出纳员持有，每个出纳员都持有两个 key 。因此，将一个投票(明文)提供给一个出纳员，该出纳员使用公共(public) key ＃1对其进行加密，然后使用其第二个公共(public) key 对THAT密文进行加密，将THAT密文提供给第二个出纳员，该出纳员使用相同的两个 key 对其加密道路。生成的密文(四个顺序加密的结果)就是发布到网络上的内容(公开)。柜员是可信赖的。

每个加密的投票都可以可视化为一个“洋葱”，其中中心是投票，并且有多层加密。为了进行投票，必须依次删除每一层，这意味着必须以相反的顺序应用相应的私钥(由出纳员持有)。这是安全性的关键-所有出纳员必须协同工作才能解密投票。

可以将Web公告板显示为具有5列的表格-第一个(在左侧)保存完全加密的投票(也显示在每个投票者的收据上)，并且是在投票发布阶段唯一可见的列。第二列包含相同的投票集，但除去了外层-出纳员2通过在计数阶段使用其私钥解密投票来填充此列和第3列。在计算阶段结束时，第5列包含可以解密的完全解密的选票。

每个投票者都会获得一张收据，将其链接到第1列中的加密投票。这没有显示他们的投票方式，但是允许他们验证自己的投票未被篡改，因为他们可以在整个选举过程中验证自己的加密货币投票仍在第1列中保持不变。当然，这只是“端到端验证”的一半，因为选民无法验证解密是否正确完成，即，第2列中有一个条目是他们的投票减去加密的外层。每个投票者仅负责第1列之前的验证。

此后，审核员有责任检查第1列中的条目是否解密到第2列，依此类推。他们这样做的方法是依靠确定性加密，并且用于加密的公共(public) key 是公共(public)的。

因为公共(public) key 是公共(public) key ，所以您不希望人们仅在第5列到第1列之间划界线，因为某人的投票经过反复加密后才参与投票-这样，将您与加密投票联系起来的收据实际上会将您与未经加密的可读投票->强制!因此，只有第1列，第3列和第5列是公开的(这就是每个柜员执行两次加密的原因)，并且对于第3列中的每个条目，{2,4}中只有一个对应的条目会向审核员显示。这样可以防止任何人(甚至审计员)将加密的投票链接到未加密的投票。

因此，

审核员需要在第3列中获得一个条目，在第2列中获得相应的条目以及公共(public) key ，并执行相同的加密以验证他们确实在第2列中获得了该条目。

放在一起，可以提供端到端的可验证性。

抱歉，这太长了-我希望它能说明我对确定性加密的需求。我错过了许多基本细节(我已经对该方案进行了重大修改)，但希望核心原理都在那里。非常感谢您的阅读-非常感谢。

Answer 1

卸下衬垫会使系统不安全。如您所说，如果公用 key 确实是公用的，那么攻击者可以简单地转到第5列，获取纯文本，并以适当的顺序用4个公用 key 对其进行加密。然后，他们可以将接收到的密文与接收到的密文进行匹配，从而损害“无强制性”属性。

随机填充可以阻止这种情况，因为攻击者不知道要添加什么填充。

您将需要使用常规填充，但要将一部分私钥透露给审核员的一部分(在选举系统中通常称为“审查员”)。这意味着一名审查员可以确认第1列与第2列匹配，而另一名审查员可以确认第2列与第3列匹配，依此类推。监票员不能将选民与选票相提并论，只能合作。

出现“消息大于模数”错误的原因是，由于每个模数不同，因此一次加密的密文可能超出了下一次加密的允许范围。