我正在考虑以下问题：我有一些数据流，我想尽可能地保护它们的安全性-假设AES与IV一起使用是否有意义，然后Blowfish与IV一起使用，最后是AES与IV ？

加密/解密过程将被隐藏(甚至可以防止调试)，因此，不容易猜测使用了哪种加密方法和哪些IV(但是，我知道这个加密链的功能不可依赖的事实这个事实，因为在一段时间之后，所有针对调试的保护措施都是可破坏的)。

我对此具有计算机能力(数据量不是那么大)，所以问题仅在于是否值得实施。例如，TripleDES的工作原理非常相似，使用了三个IV和加密/解密/加密方案，因此它可能不是完全废话。另一个问题是，当我对第一部分和第三部分使用相同的IV或者对所有三个部分使用相同的IV时，会降低多少安全性？

我欢迎有关此主题的任何提示

解决方案

我们正在尝试保护谁免受数据攻击？兄弟，竞争对手，政府或者外星人？

每个级别都有不同的级别，在合理的预算(时间/现金)内，我们可以认为数据"尽可能安全"。

我不确定这种特定的组合，但是将这种东西混合在一起通常是一个坏主意，除非对该特定组合进行了广泛的研究。数学转换实际上可能相互抵消，最终结果可能更容易破解。 AES或者河豚的单次通过应该绰绰有余。

更新：从下面我的评论

以TripleDES为例：考虑一下世界上最好的密码学家花了多少时间和精力来创建这种组合(请注意DoubleDES有一个漏洞)，尽管有192位密钥，他们能做的最好的是112位安全。

更新2：我必须同意Diomidis的观点，AES极不可能成为系统中的薄弱环节。实际上，与AES相比，系统的其他所有方面都可能受到损害。

更新3：根据对流的处理方式，我们可能只想使用TLS(SSL的后继者)。我建议使用实用密码学以获得更多详细信息，它可以很好地解决我们需要解决的许多问题。它讨论了流密码，它可能比AES更合适，也可能不比AES更合适(因为AES是分组密码，并且我们特别提到要加密的数据流)。

另外，不要浪费时间混淆应用Kirchoff原理的算法，并且要记住，在很多需要"安全"数据的地方都使用了AES(本身)。

我认为通过将一种加密算法应用于与第一种加密算法完全不同的另一种加密算法，我们不会失去任何放松的余地。但是，即使我们在第一个算法之间运行了另一个算法，我也要警惕在第一个算法之上运行第二个相同算法的算法。两次运行之间的交互可能会打开一个漏洞。

话虽这么说，我认为我们在加密方面实在是太痛苦了。大多数数据泄露不是通过破坏行业标准的加密算法(例如AES)而发生的，而是通过系统中的其他弱点发生的。我建议花更多的时间在密钥管理，未加密数据的处理，算法实现中的弱点(可能泄漏数据或者密钥)以及更广泛的系统问题上，例如，我们对数据备份的处理方式。

达米安：你是对的，我应该写得更清楚。我说的是竞争对手，它是用于商业用途。因此，有可用的有意义的预算，但是我不希望在不知道自己为什么这样做的情况下实施预算

汉克：是的，这也是我所害怕的。提到此想法的最有说服力的来源是TripleDES。另一方面，当我使用一种算法对某些数据进行加密，然后再应用另一种算法时，如果整个加密的"功效"小于使用独立算法的话，那将是很奇怪的。但这并不意味着不可能相等……这就是我要提示的原因，这不是我的知识领域……

狄奥米迪斯：这基本上是我的观点，但是我的同事正在试图说服我它确实"增强了"安全性。我的建议是在没有任何思考或者深入了解我在做什么的情况下，使用更强大的加密密钥而不是一个接一个的算法。

我不会依赖于模糊我们正在使用的算法。这种"默默无闻的安全性"不会持续很长时间。反编译代码是揭示我们所使用的加密货币的一种方法，但是通常人们不会长时间保留这样的秘密。这就是为什么我们首先使用私钥/公钥加密的原因。

@Miro Kropacek同事正在尝试通过Voodoo增加安全性。相反，请尝试构建一些简单的东西，例如使用AES即可分析缺陷。

我猜是他(她？)建议也通过防止调试来增强安全性...

如果我们使用不同的IV和密钥多次加密，实际上并不能使事情变得不那么安全，但是安全性的提高可能比我们预期的要少得多：在2DES的示例中，中间相遇攻击意味着打破难度仅是难度的两倍。

但是，总的来说，如果需要更高的安全性，则坚持使用一种众所周知的算法并增加密钥长度会更安全。将组成密码系统的工作留给专家(我自己也不是其中之一)。

黑客将始终攻击链中最弱的元素。因此，使强元素变得更强几乎没有帮助。使用128位密钥长度已经不可能破解AES加密。河豚也是如此。选择更大的密钥长度会使其变得更加困难，但实际上到目前为止，从未破解过128位(并且可能不会在未来10或者20年内破解)。因此，这种加密可能不是最弱的元素，那么为什么要使其更强呢？它已经很强大了。

想想最弱的元素还有哪些？ IV？实际上，我不会花太多时间选择一个出色的IV或者将其隐藏。最弱的密钥通常是加密密钥。例如。如果我们正在加密存储在磁盘上的数据，但是应用程序需要读取此数据，则应用程序需要知道IV，并且需要知道加密密钥，因此它们都必须位于二进制文件中。这实际上是最弱的元素。即使我们采用20种加密方法并将它们链接在数据上，所有20种加密方法的IV和加密密钥也必须位于二进制文件中，并且如果黑客可以提取它们，则使用20种加密方法而不是1种加密的事实提供了零添加安全。

由于我仍然不知道整个过程是什么(谁加密数据，谁解密数据，数据在哪里存储，如何传输，谁需要知道加密密钥等等)，所以这很难要说最弱的元素是什么，但是我怀疑AES或者Blowfish加密本身就是我们最弱的元素。

即使一开始可能不清楚，两次加密比一次加密更安全。

直观上看，使用相同算法进行两次加密并没有提供额外的保护，因为攻击者可能会找到一个密钥，该密钥将从最终密文到原始文本一直解密。 ... 但这种情况并非如此。

例如。我从纯文本A开始，并用密钥K1对其进行加密以获得B。然后，我用密钥K2对其进行加密以获得C。

凭直觉，假设可能存在一个密钥K3似乎是合理的，我可以用它来加密A并直接获得C。如果是这种情况，那么使用蛮力的攻击者最终会偶然发现K3并能够解密C，结果是额外的加密步骤没有增加任何安全性。

但是，(对于任何现代加密方案)存在这样的密钥的可能性极小。 (当我在这里说"极不可能"时，是指普通人用"不可能"一词表达的意思)。

为什么？
将键视为提供从纯文本到密文的映射的函数。
如果我们的密钥全都是KL位，那么就有2 ^ KL这样的映射。
但是，如果我每个都使用2个KL位密钥，这将给我(2 ^ KL)^ 2映射。
并非所有这些都等同于单阶段加密。

如果使用2种不同的算法，则两次加密的另一个优点是，如果在其中一种算法中发现了漏洞，则另一种算法仍会提供一定的安全性。

正如其他人指出的那样，强行使用密钥通常是不得已的方法。攻击者通常会在其他时候尝试破坏该过程(例如，使用社交工程发现密码短语)。

提高安全性的另一种方法是简单地将较长的密钥与一种加密算法一起使用。

...随时纠正我的数学问题！

是的，这可能是有益的，但在大多数情况下可能会显得过大。另外，正如Hank所提到的，某些组合实际上会削弱加密。

TrueCrypt提供了多种组合加密算法，例如AES-Twofish-Serpent。当然，使用它们会降低性能。

更改算法并不能提高质量(除非我们期望算法会被破坏)，而仅仅是密钥/块的长度以及混淆方面的一些优势。多次执行此操作很有趣，因为即使第一个密钥泄漏，生成的数据也无法与随机数据区分开。在给定平台上有更好处理的块大小(例如寄存器大小)。

攻击质量加密算法只能靠蛮力起作用，因此取决于我们可以花费的计算能力。这意味着最终我们只能增加可能性
平均需要有人解密的时间。

如果数据具有真实价值，最好不要攻击数据，而要攻击密钥持有者...

我同意上面所说的。加密的多个阶段不会给我们带来多少好处。如果我们使用的是"安全"算法，则几乎不可能破解。在某些标准流模式下使用AES。有关可接受的密码和模式，请参见http://csrc.nist.gov/groups/ST/toolkit/index.html。如果正确使用该站点上建议的任何内容，都应足够安全。如果我们想提高安全性，请使用AES 256，尽管128仍然足够。最大的风险不是针对算法本身的攻击，而是针对密钥管理的攻击或者侧信道攻击(根据应用程序和使用情况，可能会或者可能不会造成风险)。如果应用程序容易受到密钥管理攻击或者旁路攻击的威胁，那么实际上我们应用多少级别的加密都没有关系。这就是我要集中精力的地方。