我见过不同加密硬件引擎的AES(CTR)模式的多个开源驱动程序，我真的不确定计数器大小、随机数等。请任何人提供以下的一些信息
问题1：
AES驱动程序如何在CTR操作模式下识别计数器大小？
看起来CTR模式下的AES支持多种长度的"反尺寸"，如下所示：
1:First是一个计数器，由一个nonce和计数器组成。随机数是随机的，其余字节是计数器字节(递增)。例如，一个16字节的分组密码可能使用高8字节作为随机数，低8字节作为计数器。
2:第二个是计数器块，其中所有字节都是计数器字节，并且可以随着进位的生成而递增。例如，在16字节分组密码中，所有16字节都是计数器字节
Q2：
Linux内核加密子系统是否为每个输入块增加计数器值，或者是否需要由内核驱动程序为相应的加密H/W负责？
问题3：
counters和nonce是将从IV中提取的东西，即IV=nonce+counter。注意，如果"l"是IV的长度，那么第一个"l/2"是nonce的长度，下一个"1/2"是计数器的长度。请让我知道我对IV、计数器和nonce的理解是否正确？
任何关于上述的信息都是非常可观的。
BR，&Sanumala
AES驱动程序如何在CTR操作模式下识别计数器大小？
很可能不会。只要它认为IV是一个128位的大计数器，那么就没有问题。如果计数器是64位并且初始化为全零，那么您只会在2^64=18446744073709551616(16字节)数据块之后出现问题；这种情况不太可能发生。
Linux内核加密子系统是否为每个输入块增加计数器值，或者需要由内核驱动程序为相应的加密H/W负责？
它需要由内核驱动程序来处理。我只在API中看到一个IV作为输入。这通常是加密API的情况。如果必须为要加密的每16个字节更新计数器，则无法获得任何性能。
计数器和随机数是将从IV中提取的东西，即IV=随机数+计数器。请注意，如果"l"是IV的长度，则第一个"l/2"是随机数的长度，下一个"1/2"是计数器的长度。请让我知道我对IV、计数器和nonce的理解是否正确？
是的，您理解正确。只有当协议使用单独的nonce和计数器，并且这两个都是随机生成的时，才会出现问题。在这种情况下，从计数器到nonce字段的进位可能会出现问题。
请注意，最好将数据大小限制在约68GB，并使用前12个字节作为随机随机数，以避免被生日问题所困扰。