CTR模式下并行分组密码Morus的多线程适配：如何保证解密正确性？

你的核心问题出在对CTR模式并行实现的误解上——CTR模式的密钥流生成天生是完全独立、支持随机访问的，和线程数、处理顺序无关，不需要让分片依赖前一个分片的状态，也不需要加密和解密线程数一致，更不需要每个块重新初始化Morus。

正确的实现思路 #

CTR模式的本质是：每个明文/密文块对应一个唯一的计数器值，密钥流块由初始状态（key+IV）和该块的计数器值直接生成，与其他块的处理过程完全无关。针对Morus的正确并行实现应该是这样：

• 加密阶段：
  1. 将整个消息划分为若干个固定大小的块（最后一个块可以是变长），给每个块分配唯一的计数器值（比如从0开始依次递增）。
  2. 每个线程启动时，用key+IV初始化一次Morus状态。
  3. 对于线程负责的每个块，根据该块的计数器值生成对应的密钥流块（若Morus支持快速状态跳转，可直接跳到对应计数器的状态；若不支持，线程可处理连续的计数器范围，从初始状态开始连续生成密钥流）。
  4. 密钥流块与明文块异或得到密文块，无需保留或传递线程内的中间状态。
• 解密阶段：
  1. 按加密时的块大小拆分密文，每个密文块对应原计数器值。
  2. 任意数量的线程启动后，用相同的key+IV初始化Morus状态。
  3. 每个线程处理自己负责的密文块，生成对应计数器值的密钥流块并与密文异或得到明文块，完全不需要关心加密时的线程数量。

为什么你之前的方案有问题？ #

你之前让同一个线程内的M12依赖M11的加密状态，这是错误的CTR模式用法——这相当于把Morus当成了链式运行的流密码，而非CTR模式下的独立密钥流生成。这种做法破坏了CTR模式的并行性，还导致了线程数依赖的问题。

针对Morus初始化成本的优化 #

Morus的初始化需要16轮状态更新，但完全不需要每个块都重新初始化：

• 每个线程仅在启动时初始化一次Morus状态，初始化成本会被分摊到该线程处理的所有块上，几乎可以忽略。
• 即使Morus不支持直接随机访问密钥流，让线程负责连续的计数器范围，从初始状态开始连续生成密钥流，也能避免重复初始化的开销。

总结 #

只要遵循CTR模式的本质，让每个块的密钥流仅依赖初始状态和自身计数器值，就能完全支持加密和解密使用任意数量的线程，既不需要额外约定线程数，也不会产生过高的初始化成本。

内容的提问来源于stack exchange，提问作者biagiop1986