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