我正在尝试为服务器和客户端提供一种方法，以便能够为每个请求生成唯一的IV，这些请求对于每个客户端都是不同的，但是确定性的。我的意思是确定性的是服务器可以计算未来任何请求的IV，只知道起始序列。
我需要此功能的原因是我使用AES加密来实现一次性密码（OTP）方案。当客户端登录到服务器时，它会获得一个种子。通过加密该种子生成第一个OTP。对于每个后续请求，客户端使用服务器和客户端之间的共享AES密钥加密最后一个OTP。因此，即使攻击者在没有共享密钥的情况下嗅探最后一个OTP，他们也无法获得下一个OTP。 OTP在CBC模式下使用AES加密。如果服务器和客户端不同步，则会出现问题。我计划处理这个的方式是在服务器端生成一些未来的OTP，看看它们是否与客户端相匹配。但是，如果没有办法确定地计算每次加密迭代的IV，这是不可能的。
在进入我提出的解决方案之前，让我表达对AES，IV，CBC和ECB的理解。这样，如果我对我的基本原则有任何误解，可以指出并纠正它们。
我知道ECB会为使用相同密钥加密的相同明文块产生相同的输出。因此，它不应该用于多个数据块，因为可以通过统计分析数据来辨别有关明文的信息。基于此，似乎如果你可以保证你的数据总是小于16字节（128位），它将消除统计攻击的问题。此外，如果您还可以保证从未使用相同的密钥加密相同的明文，您将永远无法获得相同的输出。因此，在我看来，假设您的系统始终符合这些非常严格的标准，使用ECB是安全的。
我知道CBC旨在消除这两个问题。通过链接块，它消除了ECB的多块统计攻击。从不对同一个AES密钥使用相同的IV，可以消除使用相同密钥对相同输出加密相同明文的问题。
如果每个客户端获得生成的AES密钥，那么当多个用户具有相同密钥的可能性很小时，机会非常小。因此，可以安全地假设没有两个客户端将使用相同的AES密钥。
我建议的解决方案是为每个客户端提供唯一的AES密钥。生成密钥时，计数器将初始化为随机数。每次必须加密某些东西时，计数器将增加1。此数字将填充到块中，然后在ECB模式下使用AES加密。这个输出将是我使用CBC加密数据的IV。
如果服务器与客户端的计数器不同步，因为它具有相同的密钥而ECB不需要IV，它可以继续生成IV，直到找到允许解密数据的IV。
我的想法是这个IV对统计攻击是安全的，因为它等于AES的块大小。此外，每次用户都会有所不同，因为每个用户都有一个唯一的密钥，计数器总是递增。显然，必须安全地传输AES密钥（现在客户端正在使用服务器的公共RSA密钥加密生成的密钥）。
我对提出的解决方案中描述的技术的基本理解是否正确？我提议的解决方案有什么明显的错误吗？是否存在使用相同密钥以建议的方式生成IV以及使用CBC加密的安全漏洞？
我意识到最后一个问题可能很难/不可能回答，因为密码学真的很难，但任何见解都会受到赞赏。
提前致谢。
答案 0 :(得分：2)
正如评论中所述，我会避免不惜一切代价发明协议，而是试图实施标准化协议。一些OTP协议要求客户端在登录服务器时使用第二个带外设备接收OTP，银行的常见情况是，当您向服务器应用程序发出登录请求时，服务器将向您发送OTP你的手机。客户端和服务器的OTP生成器通常是时间同步或反向同步的，如果我理解正确，您打算使用后一种解决方案。我在你的描述中没有找到你打算如何在一个单独的设备上管理客户的柜台？
无论如何，我建议使用已经“在现场测试”的标准化程序，而不是滚动我自己的方案。 HOTP可能是您正在寻找的 - 尽管它使用的是键控HMAC解决方案而不是对称加密，但这样可以使事情变得更容易，因为您不必再担心IV了。
在任何情况下，您都应该尽早计划如何与客户建立对称密钥。如果您无法通过安全通道处理此问题（例如亲自分发密钥），则这将成为整个系统安全性的问题。
答案 1 :(得分：0)
好吧只是想一想......如果你想要一些自我同步的东西，你可以用密码反馈模式设置AES ...这样你的密文将被用作IV ......如果双方都不同步，一个密文块足以重新获得同步（但是由于前一个不可用，将导致重新同步的那个不会被解密）
答案 2 :(得分：0)
你甚至可以取消ECB部分，原则上关于IV的一个真实的东西是它应该是唯一的，并且计数器很可能是。由于在攻击过程中让计数器独一无二是很棘手的（参见例如WEP加密），使用安全随机（真正的安全随机，而不是“索尼PS3”安全随机或XKCD安全随机）要好得多。
你对加密的理解似乎没问题，但是如果其他所有方法都失败的话，我仍会继续使用其他建议并且只针对你自己的方案（和实现）。