流密码和分组密码之间的区别

#1 楼

分组密码是$ k $位密钥和$ n $位（明文）块到$ n $位（密文）块的确定性和可计算功能。 （更一般地，这些块不必一定是位大小的，$ n $个字符块也可以放在这里）。这意味着，当您使用相同的密钥加密相同的纯文本块时，您将获得相同的结果。 （我们通常也希望函数是可逆的，即给定密钥和密文块，我们就可以计算出纯文本。）不要直接使用分组密码，而应将其置于一种操作模式。最简单的这种模式是电子密码本模式（ECB），该模式仅将消息切成块，将密码应用于每个块并输出结果块。 （不过，这通常不是安全模式。）

某些早期的加密方案，例如Caesar使用的方案，可以归类为“ ECB模式下具有1个字符块的块密码”。或通常，所有具有代码簿的东西。

我们通常使用其他操作模式，包括初始化向量和某种反馈，以便每条消息的每个块都以不同的方式加密。

流密码是一种将$ k $位密钥和任意长度的明文直接映射到（相同任意长度）密文的功能，以这种方式将明文的前缀映射为密文的前缀，即我们可以在知道明文的尾部部分之前计算出密文的开始部分。

如果重复一部分明文，则相应的密文通常不相同-消息的不同部分将以不同的方式进行加密。

通常，此类流密码通过从实际密钥（可能还有初始化向量）生成密钥流，然后简单地将其与消息进行异或运算来工作，这些流称为同步流密码。其他流密码可能会根据以前的部分来更改消息的未来部分的加密。

某些操作的分组密码模式实际上会创建同步流密码，例如CTR和OFB模式。 br />切勿将同步流密码（包括流模式下的分组密码）的密钥（以及IV，如果适用）重用于不同的消息，因为这可能导致妥协。 （即使是同一条消息，它也会显示出您重复了一条消息。）

请注意，在实际使用中，您还需要MAC，例如完整性保护，供您参考。 （例如，在选择密文攻击的情况下，某些方案会被破坏，而这种MAC将阻止这种情况（如果仅在检查MAC之后将消息传递给解密器的话）。

#2 楼

从数学上讲，块密码只是$ n $位块的集合\\ {0,1 \} ^ n $上的键控伪随机置换族。 （在实践中，我们通常还需要一种有效的方法来计算逆排列。）单独使用分组密码对实际的加密不是很有用，至少除非您只是需要加密每个都适合单个消息的小消息。

但是，事实证明，分组密码是用于构建其他密码工具的极其通用的构建基块：一旦有了良好的分组密码，就可以轻松构建从流密码到哈希函数，消息的任何内容身份验证代码，密钥派生函数，伪随机数生成器，熵池等仅基于一个分组密码。例如，它们中的许多可以基于任何不需要排列的伪随机函数（但是，很方便地，有一个引理说伪随机排列仍然可以工作）。同样，许多构造是间接的。例如，您可以从消息身份验证代码构造密钥派生函数，可以从哈希函数构造密钥，该哈希函数可以（但不是必须）从分组密码构造。但是，即使您拥有分组密码，也可以利用它来构建其余所有密码。

此外，这些构造通常带有（有条件的）安全证明，这些证据会降低所构造函数的安全性，底层分组密码的数量。因此，您无需执行费力而又不可靠的任务，即分别对每个功能进行加密分析，而是可以自由地将所有精力集中在分组密码上，因为您将对安全性有任何信心分组密码的直接转化为基于它的所有函数的置信度。

显然，如果您正在一个小型嵌入式平台上工作，那么这一切都是非常方便的，在该平台上为多个单独的加密基元包含高效且安全的代码可能既困难又昂贵。但是，即使您不在这样一个受限的平台上，由于需要注意诸如侧通道攻击之类的事情，编写和分析低级密码也可能很费力。将自己限制在有限数量的低级构建块中，并从中构建所需的一切会变得更加容易。

即使在具有大量内存的快速平台（例如台式机CPU）上实现低直接在硬件中进行级别的加密操作可能比在软件中进行加密操作快得多，但是要对其中的多个操作进行加密是不实际的。由于块密码的通用性，因此它们是硬件实现的极佳候选者（如现代x86 CPU的AES指令集）。


那么，流密码又如何呢？ br />从数学上讲，从最广义上讲，流密码也是密钥可逆的伪随机函数族，但是在任意长度的位串$ \ {0,1 \} ^ * $上，而不是在长度有限的块。

（这里有一些微妙之处；例如，大多数流密码构造要求输入包含唯一的随机数值，并且如果将相同的随机数用于两个不同的随机数，则从真正的随机函数的可分辨性的角度出发，也不保证安全性。另外，由于从$ \ {0,1 \} ^ * $到其自身的可逆函数之间没有统一的分布以选择随机函数，因此我们需要仔细定义流密码看起来“不可区分”的含义。从随机”，并且此定义确实具有实际的安全隐患-例如，大多数流密码会泄漏消息的长度。实际上，我们通常还要求流密码实际上是“流”，即任意长输入比特流可以仅使用恒定的存储和消息长度的线性时间来加密和解密。）

当然，流密码比分组密码更有用：您可以直接使用它们加密任何长度的消息。但是，事实证明，它们作为其他加密工具的构建块也没有多大用处：如果您具有分组密码，则可以轻松地将其转换为流密码，而将任意流密码转换为分组密码非常困难。如果不是不可能的话。

那么，人们为什么不花心思设计专用的流密码，那么，如果分组密码也能做到这一点呢？通常，原因是速度：有时，您需要一种快速密码来加密大量数据，并且那里有一些真正快速的专用流密码设计。这些设计中的一些设计也非常紧凑，无论是在软件或硬件中，或在两者中都可以实现，因此，如果您真的只需要流密码，则可以使用其中一种密码而不是密码来节省代码/电路大小。基于通用分组密码的密码。

但是，您获得的速度和紧凑性却失去了多功能性。例如，似乎没有任何简单的方法可以从流密码中构造哈希函数，因此，如果您需要其中一种（并且经常这样做，因为哈希函数除了自身有用之外，还可以其他加密工具的通用构建基块），则必须分别实现它们。而且，猜猜是什么，大多数哈希函数都是基于分组密码的，因此，如果您有一个，您最好也将相同的分组密码重新用于加密（除非您确实需要专用流密码的原始速度）。 >

#3 楼

分组密码本身确实使用密钥将n位映射到n位。即它是一个键控伪随机排列。它不能接受更长或更短的文本。

要真正加密消息，您始终需要链接模式。 ECB是一种这样的链接模式（而且是一种非常糟糕的链接模式），它不是纯分组密码。甚至ECB也包含“附加处理操作”。这些链接模式可以具有完全不同的属性。

计数器模式（CTR）是最流行的链接模式之一，它根据分组密码构造同步流密码。 CFB的另一种模式构造了一种自同步流密码，其属性介于CBC和同步流密码之间。

因此，您认为流密码和块密码之间没有密码的假设并不是真的。密码学家只喜欢用众所周知的块密码本元来构建它们，而不是创建一个全新的系统。它使用26符号编码而不是2符号编码，但这并不意味着它不是流密码。查看Solitaire / Pontifex，了解具有26个符号的流密码的现代构造。

#4 楼

加密有两种基本类型


对称。它使用相同的密钥进行加密和解密。
不对称。它使用两个不同的密钥（公共密钥和私有密钥）进行加密和解密。

密码和流密码构成对称加密的一部分。 Stream Cipher根据用户给定的密钥生成扩展的密钥流，然后使用纯文本（用于加密）/密文（用于解密）对其进行XoR。

Block Cipher将数据块作为输入，对它与密钥混合一起产生密文。分组密码具有多种操作模式，其中计数器（CTR）模式的工作方式类似于流密码。序列号输入到分组密码，其输出与纯文本进行异或以形成密文。在这种操作模式下，仅需要块密码的加密代码。不需要解密代码，对于解密，我们只需输入相同的序号来对密码进行分组，然后将其输出与Ciphertext进行异或以得到纯文本。有时会与计数器一起使用一个nounce，因此输入的分组密码将分为两部分，即固定nounce和增量计数器。



其他操作方式是：-


ECB（提供机密性）
CBC和CTR（提供机密性）机密性和绝对安全性，可抵御所选的明文攻击）
EAX，CCM和GCM（提供经过身份验证的加密）

更多详细信息，请点击这里