Aes
如何最小化 AES 輸出大小？
我在一個關於 CAN 匯流排的項目上工作，我想在節點之間加密數據，但我遇到了一個問題，因為 CAN 匯流排節點彼此接收和發送 8 個字節，而且我知道 AES 輸出的大小與輸入完全相同. 我很困惑。據我所知，AES 工作在 16 字節的塊中。我的問題是：
如何減小輸出 aes 大小以使 CAN 匯流排節點能夠正確接收 8 個字節（來自任何節點的實際消息）？
當你在這個受到嚴格限制的環境中工作時，它可能比你在 stackexchange 上聽一些陌生人所得到的更複雜；您可能需要遵循一些現有的 CAN 匯流排加密標準（由專家編寫），或者找專業的開發人員 - 問題遠不止“我如何使用 AES”
我將討論一些明顯的問題：
- 安全目標是什麼？是不是有人在 CAN 匯流排上監聽無法讀取消息？或者，是否只是為了確保收到的任何消息都來自授權的發件人？例如，CAN 匯流排上的其他人是否無法插入自己的命令，無論是隨機命令（DOS 攻擊）、選定命令還是重新發出以前的有效命令？是否有人無法在飛行中修改命令（如果他們可以接收密文，以某種方式阻止接收者獲取原始密文，然後重新發布修改後的密文，這可能是可能的）？
- 您聲明密文必須是 8 個字節 - 相應的明文也是 8 個字節嗎？這樣做的問題是有人可以注入一個 8 字節的密文，它會解密為一些有效的明文。
- 使用 AES 假設發送者和接收者共享一個密鑰；這是真的？密鑰是如何共享的？它是在工廠或安裝時預先配置的嗎？或者，它是否以某種方式協商（如果是，細節是什麼）？
- 我假設發送者和接收者不能保證保持“同步”；也就是說，接收者可能會錯過來自發送者的有效消息。我還假設系統需要“盡力而為”；也就是說，讓系統拒絕有效消息是不能容忍的（例如，您不想因為密碼系統剛剛進入錯誤狀態而忽略“我剛剛被按下”的製動踏板消息）。如果這個假設不成立，那麼有一些有用的技術是可能的。
現在，鑑於上述可能的答案，我對加密模式的第一直覺是使用格式保留加密，例如 FF1（它使用 AES 加密任意長度的消息，例如 64 位）。然而，FF1 的計算成本很高（它使用大約 10 次 AES 評估來加密/解密 64 位消息），並且充其量只是整個解決方案的一小部分。
如果您使用 AES 作為流密碼，您可以使用 CTR 模式並發送不超過消息大小。但是，這不會為您提供消息身份驗證，您需要確保發送者和接收者同步。處理這些額外的要求將不可避免地發現您發送的數據比原始消息更多。