以下哪种模式: cbc、cfb、ctr、ecb、ncfb、nofb、ofb、stream是安全的，哪种模式是绝对不可接受的

Question

我所说的安全性是指编码的字符串与随机噪声是无法区分的，并且对同一文本的每次加密都是不同的，因此不可能猜测所使用的加密算法或对编码文本进行任何字典攻击。

第二:输出字符串长度与输入字符串长度不一致，无法对该账号进行猜测。

第三:可以验证所提供的密码是不正确的，因此解码函数可以返回false，而不是假设解码的随机字符串。

- edit:这是给定的算法和模式对编码的速度：

0.554 : cast-128 : ctr : 8
0.556 : gost : ncfb : 8
0.5562 : cast-128 : ecb : 8
0.5566 : cast-128 : ncfb : 8
0.5579 : gost : cbc : 8
0.5596 : gost : cfb : 8
0.5596 : gost : ofb : 8
0.5601 : gost : ctr : 8
0.5613 : cast-256 : cfb : 16
0.5621 : twofish : cbc : 16
0.5622 : rijndael-128 : ctr : 16
0.5632 : twofish : cfb : 16
0.5646 : rijndael-128 : cfb : 16
0.5656 : rijndael-128 : ofb : 16
0.5657 : rijndael-128 : ncfb : 16
0.5658 : loki97 : cbc : 16
0.5663 : gost : ecb : 8
0.5667 : cast-128 : cfb : 8
0.5674 : cast-128 : ofb : 8
0.5675 : rijndael-128 : ecb : 16
0.5684 : loki97 : ctr : 16
0.5684 : rijndael-128 : nofb : 16
0.5686 : loki97 : ecb : 16
0.5688 : loki97 : cfb : 16
0.5692 : gost : nofb : 8
0.57 : saferplus : ecb : 16
0.5701 : cast-256 : nofb : 16
0.5704 : loki97 : ncfb : 16
0.571 : twofish : ncfb : 16
0.5719 : cast-256 : ecb : 16
0.5728 : cast-256 : cbc : 16
0.573 : twofish : ofb : 16
0.5731 : cast-256 : ofb : 16
0.5737 : loki97 : nofb : 16
0.5741 : saferplus : ctr : 16
0.5748 : twofish : ecb : 16
0.575 : rijndael-192 : cfb : 24
0.5759 : cast-256 : ctr : 16
0.5769 : cast-128 : nofb : 8
0.5776 : saferplus : ofb : 16
0.5778 : saferplus : ncfb : 16
0.5778 : twofish : nofb : 16
0.5783 : rijndael-128 : cbc : 16
0.5795 : rijndael-192 : ecb : 24
0.5801 : rijndael-192 : cbc : 24
0.5808 : rijndael-192 : nofb : 24
0.5809 : saferplus : cbc : 16
0.581 : saferplus : nofb : 16
0.5829 : rijndael-192 : ctr : 24
0.5837 : serpent : ctr : 16
0.5845 : cast-256 : ncfb : 16
0.5856 : xtea : ecb : 8
0.5857 : serpent : cbc : 16
0.5859 : xtea : ctr : 8
0.5863 : saferplus : cfb : 16
0.5877 : twofish : ctr : 16
0.5881 : xtea : nofb : 8
0.5887 : xtea : ofb : 8
0.5891 : cast-128 : cbc : 8
0.5892 : xtea : ncfb : 8
0.5895 : rijndael-192 : ncfb : 24
0.5913 : serpent : cfb : 16
0.5918 : serpent : ofb : 16
0.5934 : rijndael-256 : ecb : 32
0.5935 : rijndael-256 : cbc : 32
0.5936 : serpent : nofb : 16
0.5943 : loki97 : ofb : 16
0.595 : rijndael-192 : ofb : 24
0.5958 : rijndael-256 : ctr : 32
0.596 : blowfish-compat : cbc : 8
0.5962 : serpent : ecb : 16
0.5972 : rijndael-256 : cfb : 32
0.5976 : rijndael-256 : ncfb : 32
0.5977 : xtea : cbc : 8
0.5982 : rc2 : ctr : 8
0.5989 : blowfish-compat : cfb : 8
0.599 : rc2 : cfb : 8
0.6 : des : cfb : 8
0.6002 : rc2 : nofb : 8
0.6009 : blowfish-compat : ctr : 8
0.6013 : rc2 : cbc : 8
0.6021 : rc2 : ncfb : 8
0.604 : rijndael-256 : nofb : 32
0.6043 : blowfish-compat : ncfb : 8
0.6043 : des : nofb : 8
0.6055 : des : ecb : 8
0.607 : blowfish : cbc : 8
0.6078 : rc2 : ecb : 8
0.6081 : blowfish-compat : nofb : 8
0.6081 : des : cbc : 8
0.6093 : blowfish : ecb : 8
0.6098 : des : ofb : 8
0.6105 : blowfish : cfb : 8
0.6113 : blowfish-compat : ofb : 8
0.6137 : rc2 : ofb : 8
0.6139 : xtea : cfb : 8
0.6141 : serpent : ncfb : 16
0.6144 : des : ctr : 8
0.6174 : blowfish : ofb : 8
0.6184 : blowfish : ncfb : 8
0.6218 : des : ncfb : 8
0.6228 : blowfish-compat : ecb : 8
0.6228 : rijndael-256 : ofb : 32
0.6253 : blowfish : nofb : 8
0.628 : blowfish : ctr : 8
0.6343 : tripledes : ctr : 8
0.6356 : tripledes : cfb : 8
0.6365 : tripledes : cbc : 8
0.6367 : tripledes : ncfb : 8
0.6368 : tripledes : ecb : 8
0.647 : tripledes : ofb : 8
0.6582 : tripledes : nofb : 8

从上到下，哪个是最安全的？

Answer 1

第二:这没有任何意义。你知道加密4个字节的结果和加密4兆字节的结果是不一样的，对吧？通常，为了掩盖实际长度(在加密密码等时)，需要使用填充--要加密的数据附加一定数量的字节，然后对整个数据进行加密。但是话又说回来，加密4字节长的密码和48字节长的口令是有区别的(除非您使用填充到64字节，但是您已经明白了)。

第三:哈希用于此目的。即，将原始数据(或某些附加数据)的散列包含在加密数据中。解密后，重新计算散列并与存储的散列进行比较。请注意，计时攻击在比较时是可能的，因此必须正确实现比较。

总而言之，你是在试图重新发明轮子。如果您只需要使用安全密钥(甚至密码)对数据进行加密，请使用OpenPGP。它解决了你问过的所有问题，也解决了你在重新发明强加密时会问到的所有问题。OpenPGP允许您使用普通口令进行加密。

Answer 2

请看这里：http://en.wikipedia.org/wiki/Block_cipher_modes_of_operatio获取一些背景知识。

这真的要看情况了。其中一些有众所周知的缺点，您必须真正查看组合密码/连接以及如何使用它的细节。

对于“临时使用”，您可以争辩说，块密码模式不是加密系统中最敏感的部分。

有些只有在你想把一个块密码变成一个流密码时才有用，例如：

• CTR
• CFB
• OFB

因此，除非您需要这样做，否则它们对您没有任何用处。

ECB是最简单的一种，它的主要缺点是明文块相等会产生相同的密文。如今，几乎没有理由使用它。

纠正你的观点：

1. 实际上并不依赖于数据块加密模式。您可能希望使用salt或加密密码N次，以避免预先计算的表攻击。
2. 这不会发生。输入填充在encryption
3. Not之前确定您的意思...

编辑:我同意尤金的观点，如果你不需要，就不要再发明轮子了！