当前位置: 玩币族首页 > 新闻观点 > 如何保证同态密文的完整性

如何保证同态密文的完整性

2019-07-10 不详来源：网络

当使用同态加密时，这意味着如果您对密文执行某种数学操作，那么在解密后，您将得到对明文进行同种运算的结果。
虽然这听起来很简单，但目前同态加密设计存在三个主要问题:

1. 性能:同态加密速度慢得令人难以忍受。
2. 可区分性:使用同态方案加密的密文有一个基本的代数结构，不像普通的加密方案生成的密文看起来像随机噪声。
3. 完整性:同态加密也受“选择密文攻击”的影响。

虽然对同态加密方案的性能和可区分性问题的研究还在进行中，但是对防止“选择密文攻击”的研究却很少。

“选择密文攻击”对抗基于同态加密的数据库

假设您有一个应用程序，它使用同态加密在将敏感信息发送给第三方服务提供者之前对其进行加密。我们将把这个特性看作一个黑盒，而不是一个特定的实现。

该应用程序拥有唯一能够解密消息的私钥，但由于它使用的是同态方案，服务提供商使用的数据库软件可以修改密文，方法是在发送回之前对其密文进行计算。可能有许多系统可以对密文执行数学操作，但这是通过一个简单的API从应用程序中抽象出来的。

如何阻止对服务端的攻击呢？

重播旧的有效密文信息，从而对应用程序隐藏更新

●在发送回消息之前执行自己的计算，从而向应用程序提供无效数据
●如果存在，利用更高级别的协议进行有针对性的修改例如，使用XOR创建错误的密文并触发重新发出请求的回退代码，可以用来创建错误的侧通道攻击，从而使攻击者能够在没有私钥的情况下窃取明文内容，而不是进行复制。

一般来说，这类攻击是直接从此类系统的威胁模型中写出来的，这一点令人担忧，因为同态加密方案通常出现在关于防止SQL注入造成的数据泄漏的讨论中。同态加密的典型现实用例将“选择密文攻击”直接放在攻击者的能力中。我们可以做得更好。

当然，这就引出了一个问题:在一个用于修改密文的系统中，是否有可能实现密文完整性我希望这个问题的答案是“是的”。

使用仅增加的分布式密码保护同态加密

在此之前，假设每个消息的密文都从应用程序发送到服务提供者，进行了修改，然后再发送回去并解密。

我们将对这个协议做一个补充，以使它能够抵抗主动攻击，只使用2017年开发人员已经可以使用的工具。

1.当应用程序向服务器发送密文时，它还会发布密文的数字签名，可以公开验证。
2.每次服务提供者(或其后端计算机)修改此密文时，将以下信息推入分布式账本(分布式账本可以是区块链，也可以不是区块链，但必须是加密安全的):

(1)正在执行的操作。
(2)操作的时间戳。
(3)生成的密文的哈希值。
(4)所有上述内容的数字签名。

3. 当服务提供者返回修改后的密文时，它还包括自上次登记以来对密文执行的修改的分布式账本的哈希列表。
4.然后，应用程序可以通过查询分布式账本以执行修改来验证每个操作。如果符合下面任意一种情况，修改可以被拒绝：

●如果操作没有生成预期的密文
●时间戳没有意义（例如在之前的更改之前）
●哈希与密文的这个阶段不匹配
●数字签名无效
●数字签名有效，但与可信公钥无关

5.应用程序可以重新提交最近密文的签名，从而将未经证实的更改列表重置为步骤1。

●此设计假定应用程序在本地存储最新的密文，以便服务提供商不能从同一起点执行多个修改。
●如果步骤4部分失败，则应用程序可能包含已更正的密文，该密文具有所有已验证更改的结果，但没有无效更改。

通过在协议中引入自动变更审计，这极大地限制了攻击面。然而，它仍然允许密文的延展性，而不需要为实际的“选择密文攻击”打开大门。

这种方法的局限性

该设计不能保证可用性。强大的攻击者可能执行“拒绝服务攻击”和“重播攻击”。

该设计并没有神奇地使底层密文与随机噪声难以区分，但它确实可以通过将该步骤视为一个黑盒子来处理任何同态方案。如果开发和部署了更好的同态加密方案，您可以将其与此设计一起使用。

使用数字签名并不保证授权执行密文修改的节点中没有恶意节点。然而，这可以让他们担负起责任。

强烈反对将数据提交给公有链(即加密货币)。为每个应用程序通过签名Merkle root到公共分布式账本上的Merkle树更合适。

—-

编译者/作者：不详

玩币族申明：玩币族作为开放的资讯翻译/分享平台，所提供的所有资讯仅代表作者个人观点，与玩币族平台立场无关，且不构成任何投资理财建议。文章版权归原作者所有。

知识区块链应用程序同态

上一篇：最新比特币矿机挑选教程 RHY教你如何挑矿机
下一篇：如何防止滥用智能合约中的伪随机性

如何保证同态密文的完整性

相关阅读：

新文章

知识推荐