如果您只有一个块，则使用其他模式（例如 CBC）不会提供额外的安全性。请记住，这里唯一的秘密应该是加密/解密的密钥。IV 通常是一个已知的实体。如果您希望通过将 IV 设为秘密来获得更好的安全性，那么您是从错误的方向接近它。

这么说，我仍然不推荐欧洲央行；）。考虑两个具有相同密码的用户。由于欧洲央行的“密码本”性质，它们的加密密码也相同。

在您的情况下，我可能会使用 CTR 模式，计数器值只是用户的 ID。

如果密钥是真正随机的，ECB 应该没问题。但是，一般来说，您不应该依赖于此。正确的安全设计是对底层数据做出最少必要的假设，但只适用于所有可能的情况。所以在我看来，只有在 IV 的额外费用非常糟糕的情况下，你才应该这样做。

此外，我想指出您没有保护密钥免受操纵。如果该加密数据字段中的某些位被翻转，您将永远不会知道它发生了，直到更进一步的某个层发现您的系统提供的密钥不起作用。然后您仍然不知道您是否输入了正确的密钥，或者存储是否损坏/被操纵。AES-GCM 或 CCM 会告诉您加密数据是否被篡改。

在您的特定情况下，可能不需要从 ECB 切换到 CBC 模式。这对于一组假设非常具体，因此如果您决定使用它，请确保记录欧洲央行正常的原因以及您所做的所有假设。（我假设您永远不会多次存储相同的密钥。如果这样做，ECB 将显示哪两个密文对应于相同的密钥。）

您的方案中的一个单独问题是您缺少消息身份验证代码。一般来说，您应该在应用加密的每个上下文中使用消息身份验证。

ECB 在您的情况下效果很好（在 ECB 模式下使用 AES-128 加密 16 字节的随机数据）。

但是，据我了解，如果您决定加密较长的密钥，则可能会出现问题。