沒有解密的壓縮和加密數據的解壓在理論上也是不可能的嗎？
我們在資訊系統中有兩個通信點，分別稱為 A(lice) 和 B(ackup)。
B 必須儲存從 A 接收到的加密數據。 B 的儲存是加密的，但不是壓縮的1。
B 應該沒有選項來解密 A 2的數據。
但是，與數據量相比，A 和 B 之間的數據通道太窄，使得通信的壓縮成為一個要求。然而，加密使內容的熵最大化，使其不可壓縮。
另一種選擇是壓縮數據，然後對其進行加密，但是 B 應該能夠解密數據以解壓縮它。
我的第一個想法是這些要求是矛盾的，就像我所知道的實用工具一樣。但我不確定，從理論上看，它看起來如何？
加密是否可能，儘管它“足夠”安全，但什麼不會惡化其中數據的可壓縮性？
1原因是這裡的數據安全和增量備份的支持，如果重要的話（我認為，它不）。
2有明顯的安全原因——擁有復雜網路所有數據的備份儲存成為安全瓶頸。
如果沒有解密密鑰，就不可能對壓縮後加密的數據進行解壓縮，至少對於相互獨立的壓縮和加密方案來說是這樣。我們可以為此提出一個理論論據：壓縮方案只壓縮一小部分可能的明文（恰好是在實踐中使用壓縮的那些），並稍微擴展其他的（例如隨機數據）。加密使得無法區分兩個大小相等的密文是否對應於壓縮壓縮的明文；從而防止任何有意義的減壓。
在問題的情況下，經典解決方案（在問題中描述為“另一個選項”）是在 A 處壓縮，然後加密，然後將壓縮+加密的數據傳輸到 B。在檢索時，相同的壓縮+加密數據從B 到 A（或 A’），解密，然後解壓縮。這減少了備份和檢索的頻寬，以及 B 的儲存需求。
B 不需要在任何時候解壓縮或解密數據：問題的“但是 B 應該能夠解密數據以解壓縮它”是正確的，但不是問題。B 不需要密鑰，因此（因此）無法解密。
問題在於直接訪問龐大數據集的一部分：對於許多常見的壓縮算法，這需要在訪問點之前傳輸所有數據（有時是所有數據）。這是通過拆分然後壓縮然後加密策略解決的，其中明文被拆分為獨立壓縮的段，然後獨立加密（或大部分加密）。但是拆分往往會減少壓縮，特別是對於短段。
另一個問題是壓縮比洩露給了竊聽者，這揭示了一些關於數據的資訊。這可能是一個嚴重的問題：對於語音，已經證明它足以理解所說的內容！
您說要解壓縮來自 A 的數據，以便 B 可以進行增量備份和恢復。如果 A 的數據沒有加密，這將是完全合理的。但是 A 的數據是加密的，這改變了一切。讓我們考慮一下。
假設 A 壓縮其數據，然後對其進行加密。假設 B 可以在不解密的情況下以某種方式解壓縮來自 A 的數據；它不能，但讓我們假設。B 現在有 A 的解壓縮但加密的數據。它實際上具有隨機位。
為了進行增量備份，來自 A 的文件的最新版本必須與其舊版本有共同之處。但即使是對未加密數據的最小更改也會完全改變加密數據。沒有增量。A 中文件的每個加密版本都與以前的版本沒有任何共同之處，否則您將能夠提取資訊。無論原始數據是否壓縮，B 都無法對加密數據進行增量備份。
同樣，要進行數據恢復 B 必須有某種模式要尋找。加密數據實際上是隨機的。B 無法對加密數據進行數據恢復，沒有模式可查找。
因此，從 B 的角度來看，來自 A 的壓縮和加密數據與來自 A 的加密數據相同。只是更小。
可以通過正常方式處理備份的完整性：多個冗餘備份、RAID、異地備份等。至於增量備份，我認為這裡不可能。幸運的是，這只是為了節省磁碟空間。考慮將舊版本解除安裝到更便宜、更慢的儲存空間。
更新正如 Barmar 在評論中提到的，A 可能必須以這樣一種方式將其數據分割成文件，以便小的邏輯更改只涉及相應數量的小文件。然後 B 會盡職盡責地備份這些文件的新版本。
例如，如果您有一個資源數據庫，而不是將它們放在一個大文件中，A 可以將它們拆分為每個文件一個資源。資源引用將被混淆為校驗和。校驗和將被計算或儲存在索引中。例如，數據
thing 123可能儲存為c27b4225f9ed9b196e307b97f07f04e869d954b9.stuff/ objects/ 00/9df0b6c69370f17f4abb0eccf335048497dac3 97/d5b7466a5eb62e8309d8df06e76d0a7496ed26 af/d5a4ca06ef2f3c8550a3d2ff923a73dd07b17a c2/7b4225f9ed9b196e307b97f07f04e869d954b9您可能會認為這與Git 儲存庫非常相似。
如果 A 對單個資源進行更改，它只會更改一個（希望很小）文件。B 只需儲存單個文件的新版本。
這確實意味著 B 可以看到哪些資源正在發生變化、變化的頻率以及其他哪些資源。即使使用混淆的文件名，這也可以提供一些關於其中內容的線索。如果您想要增量備份，我相信這是必要的資訊洩漏；B 使用的加密數據必須有一些邊界。