Java中的确定性RSA加密

Chr*_*ris 9 java encryption rsa deterministic encryption-asymmetric

这是我在这个网站上的第一个问题,我对RSA只有基本的数学理解,所以请耐心等待!:)

我正在为大学的最后一年项目编写一个Java Web应用程序.这是一个基于网络的实施"Pret-a-voter",一个安全的投票系统,适用于那些听过它的人.

基本上我的问题是我希望能够给某人履行审计员的角色:

  • 一个字节阵列(明文进行加密)
  • RSA公钥文件
  • 一个" 目标 "字节数组,这是我自己计算明文和公钥的密码数据的结果

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

(注意 - 我在这个项目中的数据很小块的工作 - 有在所有涉及没有对称加密...我知道这是一个"有趣"的使用RSA的!)

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

cipher = Cipher.getInstance("RSA");
Run Code Online (Sandbox Code Playgroud)

使用默认的随机填充方案,在11个字节的成本(因此与2048位密钥对,这是可能的加密2048/8-11 = 245字节).对同一明文的重复加密会产生不同的密文,这显然不是我想要的ECB模式.

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

cipher = Cipher.getInstance("RSA/ECB/NoPadding");
Run Code Online (Sandbox Code Playgroud)

我已经在很多地方看到RSA没有填充而不安全.这仅仅是因为攻击者可以建立明文/密文字典吗?这是确定性的加密我需要为了让审计人员来验证我的加密的副作用,并在我的方案审核员信任,所以这将是确定.

我的问题的第二部分与java有关.如果我确实如上所述使用RSA/ECB/NoPadding,我相信我能够提供(例如)长度为128(对于1024位RSA密钥对)的源字节数组并加密以获得另一个长度的字节数组128.如果我再尝试加密再次,与1024不同长度的公钥,我得到

javax.crypto.BadPaddingException:消息大于模数

有谁知道为什么?

编辑 - 使用NoPadding进行加密并不总能产生这种异常 - 这是一种性情.但是,即使加密没有生成此异常,解密也会生成:

javax.crypto.BadPaddingException:数据必须以零开头

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

编辑 - 对不起,我原来的问题不是很明确我想做什么,所以这是一个[尝试]解释:

  • 明文是选举中投票人的投票.
  • 一个选民的目的是在不牺牲选民保密的情况下进行端到端的可核实(等).投票后,选民可获得一张收据,他们可以用来验证他们的投票是否已被正确记录,并且稍后会向他们表明他们的投票没有被篡改.选民将收据上的信息与网上发布的相同副本进行比较.
  • 但是,任何选民都不应该证明他/她投票的方式(因为这可能导致强制),因此信息不是明文,而是加密的投票副本.
  • 事实上,明文被加密了四次,有四个不同的非对称密钥 - 由两个不同的柜员持有,每个柜员拿着两把钥匙.因此,投票(明文)被提供给一个柜员,他使用公钥#1加密它,然后用他的第二个公钥加密THAT密文,给那个用他的两个密钥加密它的第二个柜员提供密文.办法.生成的密文(四个连续加密的结果)是发布到Web(公开)的内容.出纳员是值得信赖的.
  • 每个加密的投票都可以看作是一个"洋葱",其中心是投票,并且有几层加密.为了得到表决,每一层又必须被去除,这意味着相应的私钥(由柜员保持)必须以相反的顺序施加.这是安全的关键 - 所有出纳员必须合作才能解密投票.
  • 网络公告板可以显示为一个包含5列的表格 - 第一列(左侧)包含完全加密的投票(也显示在每个选民的收据上),并且是投票阶段唯一可见的列.第二列包含相同的投票集,但删除了外层 - 柜员2通过在统计阶段使用其私钥解密投票来填充此列和第3列.在计数阶段结束时,第5列包含完全解密的投票,然后可以计算.
  • 每个选民都会得到一张收据,将他们与第1栏中的加密投票联系起来.这并未显示他们如何投票,但允许他们核实他们的投票未被篡改,因为在整个选举过程中他们可以验证他们的加密投票第1栏仍然存在,未触动过.当然,这只是"端到端验证"的一半,因为选民无法验证解密是否已正确完成,即第2列中有一个条目是他们的投票减去外层加密.每个选民只负责验证到第1栏的点.
  • 此后,审核员有责任检查第1列中的条目是否解密到第2列,依此类推.他们这样做的方式是依靠确定性加密和用于加密的公钥是公开的.
  • 由于公钥是公开的,你不希望人们只是简单地从第5列到第1列绘制线条,加入某人的投票,因为它变得反复加密 - 这样,将你绑定到加密投票的收据实际上将你绑定到未加密的,可读的投票 - >强制!因此,只有第1,3和5列是公共的(这就是每个出纳员执行两次加密的原因),对于第3列中的每个条目,{2,4}中只有一个相应的条目被透露给审计员.这可以防止任何人(甚至是审计员)将加密的投票链接到未加密的投票.
  • 因此,审计人员需要在第3列中输入一个条目,在第2列和公钥中给出相应的条目,并执行相同的加密以验证它们确实在第2列中获得了条目.
  • 总而言之,这提供了端到端的可验证性.

抱歉,这是如此冗长 - 我希望它描述了我对确定性加密的需求.我错过了很多基本细节(我已经大量修改了这个方案),但希望核心原则都存在.非常感谢你阅读 - 我真的很感激.

caf*_*caf 5

删除填充会使系统不安全。如果公钥确实是公开的,如您所说,那么攻击者可以简单地转到第 5 列,获取明文,并按照正确的顺序使用 4 个公钥对其进行加密。然后,他们可以将生成的密文与接收者的密文进行匹配,从而损害“无强制”属性。

随机填充阻止了这一点,因为攻击者不知道要添加什么填充。

您将需要使用普通填充,但向一部分审计员(通常在选举系统中称为“审查员”)显示私钥的一个子集。这意味着一个检查员可以确认第 1 列与第 2 列匹配,另一个可以确认第 2 列与第 3 列匹配,依此类推。单独的监票员不能将选民与选票相匹配,只能是合作的。


您收到“消息大于模数”错误的原因是因为每个模数都不同,因此一次加密的密文可能超出下一次加密的允许范围。