AES256-GCM 可以在https://gist.github.com/cannium/c167a19030f2a3c6adbb5a5174bea3ff中實現但是，Seal接口的方法cipher.AEAD有簽名：Seal(dst, nonce, plaintext, additionalData []byte) []byte所以對于非常大的文件，必須將所有文件內容讀入內存，這是不可接受的。一種可能的方法是在and上實現Reader/Writer接口，但這不應該由 AEAD 的那些分組密碼“模式”來解決嗎？所以我想知道這是golang cipher lib的設計錯誤，還是我錯過了GCM的一些重要內容？SealOpen
2 回答
慕容3067478
TA貢獻1773條經驗 獲得超3個贊
AEAD 不應用于一次性加密大量數據。API 旨在阻止這種情況。
在單個操作中加密大量數據意味著 a) 所有數據都必須保存在內存中，或者 b) API 必須通過返回未經身份驗證的明文以流方式操作。
返回未經身份驗證的數據很危險，因為 gpg 命令還提供了流接口，所以在互聯網上不難找到人們提出的建議。gpg -d your_archive.tgz.gpg | tar xz
當然，使用 AES-GCM 之類的結構，如果應用程序在處理之前未對其進行身份驗證，則可以很容易地隨意操作明文。即使應用程序在確定真實性之前小心翼翼地不向 UI“釋放”明文，流式設計也會暴露更多的程序攻擊面。
通過規范化大密文并因此流式傳輸 API，出現的下一個協議更有可能在沒有意識到問題的情況下使用它們，因此問題仍然存在。
最好將明文輸入分成相當大的部分（比如 16KiB）并單獨加密。這些塊只需要足夠大，以使額外驗證器的開銷可以忽略不計。通過這樣的設計，可以增量處理大消息，而不必處理未經身份驗證的明文，并且 AEAD API 可以更安全。（更不用說可以處理更大的消息，因為 AES-GCM 對單個明文有 64GiB 的限制。）
需要一些想法來確保塊的順序正確，即通過計算隨機數，第一個塊應該是第一個，即從零開始隨機數，最后一個塊應該是最后一個，即通過附加一個空, 帶有特殊附加數據的終結符塊。但這并不難。
例如，請參閱miniLock中使用的分塊。
即使采用這樣的設計，攻擊者仍然可以導致消息被可檢測地截斷。如果您想瞄準更高，可以使用全有或全無變換，盡管這需要兩次通過輸入并且并不總是可行的。
POPMUISE
TA貢獻1765條經驗 獲得超5個贊
這不是設計錯誤。只是在這方面 API 是不完整的。
GCM 是一種流操作模式，因此能夠在不停止流的情況下按需處理加密和解密?？磥砟鸁o法重用與之前的 MAC 狀態相同的 AEAD 實例，因此您無法直接使用此 API 進行 GCM 加密。
crypto.NewCTR您可以在您自己的 GHASH之上實現您自己的 GCM 。
- 2 回答
- 0 關注
- 668 瀏覽
添加回答
舉報
0/150
提交
取消