是否存在滾動塊加密算法？

我正在製作一個note taking web app，它可以在您輸入時連續保存筆記。我發送差異以防止通過電報發送太多數據，當筆記是純文本時，這可以正常工作。是否存在滾動塊加密算法？

但是，我添加了對加密筆記的支持，因此筆記只能以加密形式離開瀏覽器（因此筆記可以包含敏感信息，而不會有任何人不知道密碼的機會（這也永遠不會離開瀏覽器）閱讀他們，甚至沒有一個完全訪問數據庫）。但是，對筆記所做的所有更改目前都完全改變了加密文本，因此我必須在編輯過程中每隔一兩秒將整個筆記發送回服務器。

根據我最近閱讀的內容，我可以（但不應該）使用ECB block cipher加密模式，它將明文分成16個字節塊並獨立加密。這意味着如果編輯發生在最後（或者如果編輯添加或刪除了16個字節的倍數），diff就可以工作。但是在筆記中間發生的任何編輯都會影響筆記其餘部分的加密文本。

因此，當我昨晚躺在牀上時，我開始想知道是否存在一種「滾動塊」加密算法，根據周圍的字符對筆記的每個部分進行加密，以便更改/添加/刪除任何一個字符只會改變周圍的16個字節。希望這是有道理的。基本上，我需要一種加密算法，以便對明文進行細微更改對加密文本進行相當小的更改。

這樣的算法是否存在？（這是另一個可以與AES一起使用的分組密碼操作模式，而不是一個完整的新算法嗎？它的安全性如何與更正常的分組密碼模式相比較？）

我原本有這個作爲JavaScript的問題，因爲這是我最終想要的，但這可能要求多一點。

來源

2011-05-27 David Johnstone

您需要使用操作像CFB，OFB或CTR一個流加密模式，而不是塊加密模式ECB像CBC或。見block ciphers modes of operation。您可以使用AES和Blowfish等通用加密算法。像CTR這樣的流密碼模式通常用於SSH等程序，因爲您一次只輸入一個字符。

來源

2011-05-27 10:05:45 WhiteFang34

如果我正確地閱讀該頁面，像CFB這樣的模式仍會在明文中途導致編輯，從而導致從該點開始的加密文本不同，這不是我想要的。 – 2011-05-27 10:24:20

啊，我明白你在說什麼了。即使有獨立處理塊的方法，插入會影響所有後續塊的文本又如何呢？那麼有趣的問題。您可能需要考慮僅發送差異並重構瀏覽器中的最終狀態。這對於允許回滾歷史具有很好的附加好處，特別是如果您爲差異事件加蓋了時間戳。 – WhiteFang34 2011-05-27 10:40:45

'CTR'模式對此無能爲力，因爲您應該*永遠不會*重複使用CTR模式流的相同部分來加密不同的數據。 – caf 2011-05-27 12:38:11

你仍然可以使用CBC - 只要消息中間的一系列塊被更新，就必須記住該序列中最後一個塊的密文的舊值。例如，給定的原文：

      | IV 0   | 
| Plaintext 0 | <=====> | Ciphertext 0 | 
| Plaintext 1 | <=====> | Ciphertext 1 | 
| Plaintext 2 | <=====> | Ciphertext 2 | 
| Plaintext 3 | <=====> | Ciphertext 3 | 
| Plaintext 4 | <=====> | Ciphertext 4 | 
| Plaintext 5 | <=====> | Ciphertext 5 |

如果客戶想要更新塊2和3，它使用Ciphertext 1作爲IV爲CBC，並把新的密文塊和Ciphertext 2bCiphertext 3b。然後，服務器保留Ciphertext 3作爲IV 1，所以它現在看起來像：

      | IV 0   | 
| Plaintext 0 | <=====> | Ciphertext 0 | 
| Plaintext 1 | <=====> | Ciphertext 1 | 
| Plaintext 2 | <=====> | Ciphertext 2b | 
| Plaintext 3 | <=====> | Ciphertext 3b | 
         | IV 1   | (= Ciphertext 3) 
| Plaintext 4 | <=====> | Ciphertext 4 | 
| Plaintext 5 | <=====> | Ciphertext 5 |

顯然，這降低了與作爲編輯積累數據存儲在服務器端的效率。

或者，您可以使用用於加密文件系統的模式，如XTS模式。這涉及到將文本分解爲比密文塊更大的可更新扇區。

來源

2011-05-27 12:32:57 caf

是否存在滾動塊加密算法？

回答

相關問題