B必须存储从A接收到的加密数据。B的存储是加密的，但未压缩1 。
B不能选择解密A2的数据。
但是，与数据量相比，A和B之间的数据通道太窄，使得压缩通信是一项要求。但是，加密会使内容的熵最大化，使其不可压缩。
另一种选择是压缩数据，然后对其进行加密，但是B应当能够解密数据以对其进行解压缩。
我的第一个想法是，这些要求与我所知道的实用工具相矛盾。但是我不确定，从理论上看它是怎么看的？
加密是可能的吗？尽管它“足够”安全，但又有什么能使数据的可压缩性恶化呢？ br />
1原因是这里的数据安全性和对增量备份的支持（如果有关系的话）（我认为不重要）。
2它有明显的安全原因-备份存储具有复杂网络的所有数据成为安全瓶颈。
#1 楼
没有解密密钥就无法对压缩后加密的数据进行解压缩，至少对于相互独立的压缩和加密方案而言。我们可以为此提出一个理论上的论点：压缩方案仅压缩一小部分可能的明文（碰巧是在实践中使用压缩的明文），并略微扩展其他明文（例如随机数据）。加密使得无法区分两个相等大小的密文是否对应于压缩压缩后的明文。因此可以防止任何有意义的解压缩。在问题的情况下，经典的解决方案（在问题中称为“另一个选项”）是在A处压缩，然后加密，然后将压缩+加密的数据传输到B.在检索时，相同的压缩+加密数据从B转发到A（或A'），然后解密，然后解压缩。这样就减少了备份和检索的带宽，并降低了B处的存储需求。
B不需要在任何时候解压缩或解密数据：问题“但是B应当能够解密数据到解压缩”是正确的，但不是问题。 B不需要密钥，并且（因此）无法解密。
问题是直接访问庞大数据集的一部分：对于许多常见的压缩算法，需要传输访问该点之前的所有数据（有时是所有数据）。这可以通过先拆分后再压缩再加密的策略来解决，在该策略中，明文被拆分为多个段，这些段被独立地压缩，然后被独立地加密（或大体如此）。但是拆分往往会减少压缩，尤其是对于短片段。
另一个问题是压缩率泄漏到窃听者那里，这揭示了有关数据的某些信息。这可能是一个严重的问题：对于语音而言，它已经足以理解所讲的内容！
评论
$ \ begingroup $
问题在于，B可以选择解密数据。您的回答非常有用，但是，我的问题的目的是找到一些方法来解压缩加密的数据而不解密它（如果存在）。
$ \ endgroup $
–peterh-恢复莫妮卡
19年5月30日在21:29
$ \ begingroup $
@peterh：不，不是。 B永远不需要解密（因此不需要解密密钥）；它总是只处理加密的压缩消息。
$ \ endgroup $
–雨披
19年5月30日在22:41
$ \ begingroup $
关于压缩率辅助通道，您可能需要查看利用此辅助通道的CRIME攻击和其他有关TLS的相关攻击。
$ \ endgroup $
– rlee827
19年5月31日在19:48
$ \ begingroup $
在第一段中，我关注的重点是无损压缩或至少是可变速率压缩，对此我并不满意。这如何转化为一般情况？有损压缩可以以恒定比率工作。
$ \ endgroup $
–leftaround关于
19年6月1日在22:31
#2 楼
您说要解压缩来自A的数据，以便B可以进行增量备份和恢复。如果A的数据未加密，这将是很合理的。但是A的数据是加密的，这会改变一切。让我们仔细考虑一下。假设A压缩其数据，然后对其进行加密。假设B可以以某种方式从A解压缩数据而不解密它；它不能，但是让我们假设。 B现在具有A的解压缩但加密的数据。它具有有效的随机位。
为了进行增量备份，来自A的文件的最新版本必须与旧版本具有某些共同之处。但是，即使对未加密数据进行的最小更改也将完全更改加密数据。没有增量。 A中文件的每个加密版本与以前的版本都没有共同之处，否则您可以提取信息。无论原始数据是否经过压缩，B都无法对加密数据进行增量备份。
类似地，数据恢复B必须寻找某种模式。加密数据实际上是随机的。 B无法对加密的数据进行数据恢复，没有可寻找的模式。
因此，从B的角度来看，来自A的压缩和加密数据与来自A的加密数据相同。 br />
备份的完整性可以通过常规方式处理：多个冗余备份，RAID，异地备份等。至于增量备份，我认为这是不可能的。幸运的是，这只是节省磁盘空间。考虑将旧版本卸载到更便宜，更慢的存储中。
UPDATE正如Barmar在评论中提到的那样，A可能必须以这种方式将其数据切成文件，以使逻辑小更改仅触及了相应数量的小文件。然后，B将忠实地备份这些文件的新版本。
例如，如果您有一个资源数据库，而不是将它们存储在一个大文件中，则A可以将它们拆分为每个文件一个资源。资源引用将被混淆为校验和。校验和将被计算或存储在索引中。例如，
thing 123的数据可能存储为c27b4225f9ed9b196e307b97f07f04e869d954b9。stuff/
objects/
00/9df0b6c69370f17f4abb0eccf335048497dac3
97/d5b7466a5eb62e8309d8df06e76d0a7496ed26
af/d5a4ca06ef2f3c8550a3d2ff923a73dd07b17a
c2/7b4225f9ed9b196e307b97f07f04e869d954b9
您可能会意识到这与Git存储库非常相似。
如果A对单个资源进行了更改，则它只会更改一个（希望很小）文件。 B只需存储一个文件的新版本。
这确实意味着B可以查看正在更改的资源，频率以及其他资源。即使使用混淆的文件名，这也可以提供一些有关文件名的线索。我认为，如果要增量备份，这是必要的信息泄漏。要使用B，必须对加密数据有一些限制。
评论
$ \ begingroup $
这是正确的答案，因为您似乎是唯一意识到OP暗示他们在传输到B后正在尝试执行增量备份的人，而不是在A的源头进行增量备份。
$ \ endgroup $
– Barmar
19年5月31日15:11
$ \ begingroup $
@Barmar谢谢，但是雨披在评论中首先弄清楚了它。我同意您的想法，即如何在A上构造数据以使其更容易备份和更新答案。
$ \ endgroup $
–施韦恩
19年6月1日在0:38
#3 楼
我认为从理论上讲，可以使用语义安全的加密来支持对加密数据进行解压缩（在有损和无损压缩设置中均如此），但是在实践中效率将非常低下。对于一般方法，可以压缩纯文本，使用完全同态的加密方案对其进行加密，然后使用解压缩机制的实现将加密的密文服务器端解压缩为恒定大小的电路，该电路可以进行同态评估。这仅要求解压缩机制可以表示为固定大小的电路，而并没有太大的局限性。
在先前的回答中提出的论点是，解压缩加密数据的能力将泄漏压缩率，并且因此违反了我认为是错误的语义安全性。无论原始数据上的实际压缩率如何，加密的解压缩均可能炸毁所有密文。即使不是这种情况，也可能仅从压缩明文的大小就可以看出压缩率（例如，在压缩固定大小的图像的情况下），因此在那种情况下，存在泄漏但没有泄漏与加密方案有关。
我不是FHE专家，但是我认为这在当今有损压缩设置中可能是不切实际的。例如，JPEG解压缩本质上是在相对较小的数据块上应用逆离散余弦逆变换。我想象有可能真正实现这种FHE样式或其他轻量级有损减压方案，而无需使用过多的工作因素。
尽管只存储对称加密的压缩明文，但在几乎任何可以想象的意义上，效率仍然更高。具体来说，我怀疑对于客户端而言，这不仅会比对客户端进行解压缩更有效。
#4 楼
您正在考虑的一般概念是同态加密，这是加密方案的总称，它允许对密文（加密的数据）执行某种类型的内部一致性计算以产生加密的结果。例如，您可能有两个加密的整数（相同的密钥），可以将它们相加以获得一个结果，该结果将使用相同的密钥解密为总和。加密方案必须有意设计为允许所需的计算，这是一个不小的问题。我想说肯定有可能设计一种加密和压缩方案，以使加密在压缩过程中是同态的，但是我在实践中一无所知，我希望这样做非常非常困难。
这是一个活跃的研究领域。您可以在Wikipedia上阅读有关此内容的更多信息。
#5 楼
另一种实现目标的方法：融合加密通常是在压缩和加密数据上完成增量备份的方法。请注意，在这种情况下，需要备份客户端维护文件的加密索引或文件块并将其发送到服务器。服务器非常笨拙，仅存储加密的Blob和引用计数。但是至关重要的是，服务器只需要存储每个唯一的加密和压缩的blob一次。
如果需要，您可以使用键控HMAC代替简单的哈希函数来导出每个文件/每个块的加密密钥。以确保系统的每个“租户”都不会受到存在确认攻击的攻击。<br />
截至2019年，许多重复数据删除备份系统中使用了融合加密的变量。这些方法既节省了存储空间，又节省了存储空间。更显着的网络带宽。
#6 楼
我同意这两个要求似乎是矛盾的：快速增量备份和安全的（防主机）异地备份。
但是，rsyncrypto文档特别指出了这些特定的矛盾要求：
有时有必要将文件存储在远程服务器上。出于备份目的，通常需要这样做。完成该操作后，有两个问题需要解决：
如何保持文件存储的隐私性？
，即“备份不应该解密文件。”
如何将带宽使用率保持在最低水平？
，即“与数据量相比，A和B之间的数据通道太窄。”
这两个问题都非常简单解决方案：
在发送文件之前先对其进行加密。将密钥保留在本地。
使用rsync仅传输更改。
只有一个问题-
两种解决方案相互矛盾。文件的纯模式加密隐藏了文件的特定更改，从而使rsync在检测文件中的更改时无用。这就是rsyncrypto的急救方法。
-https://rsyncrypto.lingnu.com/（源代码）
Rsyncrypto被设计为[a]备份服务的一部分... [具有]两个基本需求：
在较差的上传带宽上传输增量数据
以某种方式加密数据不允许服务器对其进行解密
Rsyncrypto解决了此问题
-https://rsyncrypto.lingnu.com/index.php?title=算法
因为rsyncrypto似乎或多或少地解决了上述问题（双方都有很小的妥协-带宽比完全未加密的纯文本略大，理论安全性比未修改的CBC略低），所以我我要说的是，理论上是可能的。
评论
为什么要求B存储加密的未压缩数据？如果B没有钥匙，为什么他会在乎它呢？如果A发送了加密的压缩数据，为什么B需要对其解压缩？@poncho正如我在（2）中所写的那样，它有一个实际的原因：B实际上是后端基础结构中的中央系统，具有许多客户端计算机的所有备份快照。这使B变得非常危险，如果只存储数据但无法访问它，我的睡眠会更好。正如我在（1）中所写，需要解压缩有两个原因：1）可以创建增量备份，以及2）在数据丢失的情况下提供更好的可恢复性选项。
@peterh：听起来您真正需要的是一种压缩方法，该方法可以提取压缩文件的一部分而不必处理整个内容。会不会满足您的要求？
@supercat否，B应该无法访问（不应解码）该内容。如果它可以比较不同的快照以找到冗余部分，那还可以。答案之一说，解密记录的语音数据可能已经足够了。实际上，我的问题试图朝着处理压缩数据而不解压缩的方向发展，这是一个非常热门的话题。显然，我不知道有什么工具可以实现这一目标，但是我对理论上的不可能感到好奇。
我不明白为什么需要解压缩以支持增量备份。增量备份是一个非常模糊的想法，但是对于一个具体示例，您可以发送经过压缩然后加密的差异（例如diff -u $ old_version $ new_version | gzip | gpg -c）。您无需解压缩即可支持该功能。关于您的第二点，即具有更好的可恢复性选项，您是否正在考虑在如此遥远的时间使用这些备份，以致整个世界都忘记了gzip的工作方式？只需存储gzip源的备份即可。