這與較早的問題有關，是否可以使用算法生成 OTP？

我有兩台機器：A 和 B。A 已連接到 Internet，並且文件會定期上傳。B 為氣隙。

當文件上傳到 A 時，我想以最安全的方式加密和儲存它們。然後它們將通過 USB 傳輸到機器 B，在那裡它們可以被解密和讀取。解決此問題的最安全方法是什麼？

我的理解是這是一個非常標準的加密問題。但是，據我所知，每條消息的隨機數都與消息本身一起傳輸。我更喜歡某種方法，其中隨機數可以由 A 和 B 都知道的算法生成，並在它們之間秘密共享一個種子。這可能嗎？

但是，據我所知，每條消息的隨機數都與消息本身一起傳輸。

是的，這通常是現在使用對稱加密加密某些東西時會發生的情況。

請注意，如果您使用的是非對稱加密，則不一定是這種情況，因為那時使用的隨機性（可以被認為是“隨機數”）通常會沿著消息加密。

可能是最簡單的方法：非對稱加密

如果您只是將數據從一台機器 A 傳輸到另一台機器 B，並且不一定需要在第一台機器 A 上再次解密數據，我強烈建議您檢查公鑰加密：

• 你可以在你的機器 B 上擁有一個強私鑰並讓機器 A 知道公鑰
• 然後，機器 A 可以使用機器 B 的公鑰加密您需要傳輸到機器 B 的所有內容，而不會洩露密鑰或任何可能允許某人解密您在機器 A 上的數據的東西。
• 然後機器 B 可以使用它的密鑰來解密數據。

如果機器 A 沒有氣隙，則尤其如此，而機器 B 是：您可以認為機器 A 已經受到威脅，因此您可能在機器 A 上擁有的所有密鑰、IV 或密碼都可能洩漏，而使用公共-密鑰加密，您的數據無法通過僅查看通過機器 A 的秘密來解密（即使所述數據在未加密時可能已經洩露）。

（如果您希望機器 A 能夠通過加密機器 A 和 B 的公鑰的數據再次解密數據，這甚至可以工作。）

關於氣隙

請注意，最終的氣隙並不一定會改變事情，因為它歸結為兩種不同的情況：

• 機器 A 被入侵，所有通過機器 A 的密鑰、IV、隨機數和（最顯著的）消息都可以被視為已被入侵
• 機器 A 沒有受到影響，然後我們就沒事了

但也許這台有氣隙的機器也被物理攻擊者入侵了，誰知道呢？所以有更多的場景……最終我們擁有的場景與我們擁有兩台機器並且想要在它們之間傳輸數據時相同的場景。

如果明文在受感染的機器上，加密中沒有任何東西可以幫助您保護您的數據免受受感染的機器的侵害……

然而，您不需要加密並不是因為這種二分法（無論是否受到損害）。事實上，在以下情況下，加密數據對於保護數據仍然有用：

• 它處於靜止狀態，因此即使有人訪問您的機器並複制您的數據，他們也無法讀取數據。
• 它正在傳輸中，因此即使有人攔截了您的數據，它也會被加密並且攻擊者無法破譯。

更是如此，因為有可能從 USB 記憶棒或您用於數據的任何傳輸方式中恢復已刪除的數據……

如果附加不是永久性的，而是僅在您離開時發生（“邪惡女僕攻擊”），那麼加密數據也是有意義的。

現在，如果你真的想做你正在討論的事情

我更喜歡某種方法，其中隨機數可以由 A 和 B 都知道的算法生成，並在它們之間秘密共享一個種子。這可能嗎？

現在，如果你真的想要對稱加密，Openssl 仍然可以並且很容易地支持它，實際上！（但不是通過其他常用工具，如 GnuPG。）如果我們查看Openssl 的enc功能文件，我們可以看到以下內容：

-K 鍵

要使用的實際密鑰：這必須表示為僅由十六進制數字組成的字元串。如果僅指定了鍵，則必須使用 -iv 選項另外指定 IV。當同時指定密鑰和密碼時，將使用通過 -K 選項提供的密鑰，並採用從密碼生成的 IV。同時指定密鑰和密碼沒有多大意義。

-iv IV

要使用的實際 IV：這必須表示為僅由十六進制數字組成的字元串。當使用 -K 選項僅指定鍵時，必須顯式定義 IV。當使用其他選項之一指定密碼時，將從此密碼生成 IV。

-傳遞參數

密碼來源。有關 arg 格式的更多資訊，請參閱openssl(1) 中的“Pass Phrase Options”。

因此，您通常可以使用參數指定一個密鑰-K，並使用該參數從共享的“密碼”文件中派生 IV -pass file:pathname。請注意，您可以選擇如何派生密碼，我建議您使用-pbkdf2並設置一定數量的迭代：

-迭代次數

在導出加密密鑰時對密碼使用給定的迭代次數。高值會增加暴力破解生成文件所需的時間。此選項允許使用 PBKDF2 算法來派生密鑰。

但！這種方法有幾個問題：

• 這將使重用 IV 變得“容易”，因為如果您使用相同的密碼兩次以相同的迭代次數，您應該得到相同的 IV，對嗎？嗯，不完全是，因為Openssl 讓你得到了覆蓋。密碼派生算法依賴於在加密文件的第一行傳遞的“鹽”，就像您通常傳遞 IV 一樣。我想您可能會抱怨這與傳遞 IV 基本相同，但事實並非如此，因為鹽與“秘密”密碼一起使用來導出 IV。
• 這使得使用太短的鍵變得容易！這確實是一個問題，因為如果您使用的密鑰大小不正確，Openssl 會用零填充密鑰以達到正確的長度！
• 在命令行上手動使用 Openssl 有點痛苦。
• 使用“壞”參數很容易。
• 最後，也是最煩人的：這不允許使用身份驗證加密！這在文件中是合理的，如下所示：

目前常用的 AEAD 模式在重用 key/iv/nonce 時也會遭受災難性的機密性和/或完整性失敗，並且由於 openssl enc 將 key/iv/nonce 管理的全部負擔置於使用者身上，因此暴露的風險AEAD 模式太大而無法允許。

這是真的：key、iv 和 nonce 管理被認為是困難的，我們不建議您自己做！如果您真的願意，您可以這樣做，但我們通常不會告訴您它是執行任何類型加密的“最安全的方法”。

請注意，我的最後一點是一個問題：缺乏身份驗證意味著有人可以在不被發現的情況下更改您的加密數據，但您可以通過在加密後執行 MAC 來解決它，採用“Encrypt-then-MAC”樣式。這可以使用openssl mac或openssl dgst取決於您的版本。或者，您可以改用openssl在其命令中包含 AHEAD 模式的 LibreSSL 來解決它enc……您只需要選擇一個經過身份驗證的密碼即可。

TL; DR：不要這樣做。

但是，正如您所看到的：我們越挖那個洞，我們就越需要探勘以嘗試獲得“安全”的東西……因此，這通常不是您想要“手動”做的事情。

我們通常建議使用對稱或非對稱加密（通常使用GnuPG），而不關心管理 IV 和“血淋淋的細節”，例如身份驗證的需要等。（注意 GPG--sign將使用公鑰簽名，所以你會即使使用該--symmetric模式也需要生成密鑰並與另一台機器共享公鑰。）

另外，如果您現在正在考慮“滾動自己的”加密，以解決您的問題，您不妨嘗試看看其他人在遇到與您類似的問題時已經做了什麼，有很多那裡的工具。“最簡單”的工具之一可能是“ Enchive ”，它使用了一種有趣的基於 Diffie-Hellman 的共享密鑰生成算法，但仍然非常簡約。

我還建議您關注最近由非常優秀的密碼學家設計和創建的“ Age ”的開發，並且應該允許您具有高安全性，具有良好的可用性做您想做的事情，而不必太在意 IVs ， ETC。

請注意實際上沒有人，即使“滾動他們自己”讓使用者管理他們的 nonces/IV，這樣做是有原因的……而且我不建議你也這樣做。

引用自：https://crypto.stackexchange.com/questions/75376