【发布时间】：2020-08-05 00:43:32
【问题描述】：
所以我有一个关于用法的一般性问题，以及在什么情况下可以使用 ECB、CBC、CFB、CTR，你们认为它们有用吗？
只是一般的，例如银行等。
任何例子都会很酷
【问题讨论】：
【发布时间】：2020-08-05 00:43:32
【问题描述】：
ECB 不安全，不应按原样使用。经典演示是ECB Linux Penguin。之所以包含它，是因为其他模式是建立在 ECB 之上的，所以无论如何代码都存在。
其他模式使用不同的方法来避免欧洲央行的问题。 CBC 可能是最常见的通用模式。 CTR 需要更加小心地设置以确保 Nonce/Key 组合是唯一的，但是一旦设置它就可以并行化，而 CBC 则不能。
这些模式都不包括消息验证，必须使用 MAC 单独完成 - 消息验证码。其他现代模式，例如 GCM（伽罗瓦计数器模式）包括身份验证，无需单独的 MAC。
【讨论】：
-
那么你说它们可以在哪里使用？还是会被使用？比如什么样的系统会使用这些来加密？
欧洲央行无时无刻不在使用。原始密码原语是 AES 排列。它本身并不安全，因为相同的输入总是产生相同的输出。 CBC、CTR、GCM等算法内部都使用ECB。
CBC 使用填充使消息具有精确数量的密码块长度。这意味着观察者在不解密消息的情况下不知道消息的精确长度。大多数其他方案泄漏消息长度。填充的使用引入了填充预言攻击的漏洞。可以通过在断言给定密文是真实的消息验证码 (MAC) 上使用来阻止填充预言攻击。在不更改密文的情况下，您无法进行填充预言攻击，而 MAC 可以防止这种情况发生。
CTR 加密一个块计数器并将它与消息的等效块进行异或。这意味着您可以访问纯文本的任何部分，而无需解密整个消息。然而，它极易受到 IV（初始化向量）的重用。
GCM 可以快速修复忘记包含正确 MAC 的消息协议。它建立在 CTR 之上，并分享了它的怪癖。 MAC 只有 128 位，而通常需要 256 位。 MAC 还会在整个消息被处理后进行验证，这意味着开发人员通常会在消息被验证之前对其进行处理，这进一步降低了 GCM 的有效性。
OFB 是一种使用 CBC 硬件来执行流加密的方法，并且像 CTR 一样，特别容易受到重复 IV 的影响，并且如果与部分块反馈一起使用则很弱。
CFB 没有众所周知的漏洞。虽然它确实揭示了消息的长度，虽然重复的 IV 并不是那么灾难性，但仍然需要避免它们。
在哪里使用哪种密码模式取决于将怪癖与需求相匹配，但如果我必须推荐一个特定的密码模式，我会说：
- 使用 CFB
- 在您的协议中包含密文的 MAC，例如带有 SHA512/256 的 HMAC。
【讨论】：