不要推出自己的加密货币！

从纯密码学的角度来看，任何保长双射函数都不会降低安全性。事实上，即使定义为f(x) = x的恒等函数也不会降低安全性，假设用于标准密码和自制密码的密钥是相互独立的。唯一可能降低安全性的方法是，如果您的自制函数不使用不同的独立密钥并泄漏密文中的密钥，例如在每个单独的输入块x上完成f _k (x) = x ⊕ k，一种经典的 XOR 密码，易受已知明文攻击。

从实际的角度来看，有些问题很重要。我在上面提到了保持长度是有充分理由的。压缩函数仍然是函数，有时压缩和加密会导致非常糟糕的结果。这就是为什么您的第二个示例（在标准加密之前应用您的自定义算法）确实更糟的部分原因。它可以通过长度泄漏有关明文的信息。您的实现中也可能存在导致其他安全漏洞的错误。从纯理论的角度来看，它们超出了范围。

有人在评论中向我指出，我可能没有充分强调这是一个多么糟糕的想法。虽然理论上可能没问题，但现实世界的运作方式不同。实际上，无论您如何使用它，使用您自己的自制加密货币都是一个非常糟糕的主意。如果您是专业的密码学家，您唯一应该真正这样做的时候。伯恩斯坦可以做到这一点。Rivest 可以做到这一点。Rijmen 可以做到这一点。你不能。不要在脚下射击自己，而是使用适当的算法。

首先应用自定义加密算法时存在风险。
这是基于这样一个事实，即像 AES 这样的加密确实会泄漏有关明文长度的信息。

假设您自定义算法将单字节明文（如 0x40）“加密”为 64 个零，将两字节明文（如 0x02 0x00）“加密”为 512 个零。

当您使用 AES 对其进行加密时，攻击者仍然会通过查看 AES 加密文本的长度来知道自定义加密结果的长度。
有了这些信息，攻击者可以在没有 AES 加密密钥的情况下将其“解密”为原始明文。

总之：一个非常糟糕的自定义算法确实会损害以下 AES 加密的安全性。

评估任何类型的安全系统时要问的第一个问题是“谁是攻击者，他们能做什么？” 在低端，您对抗的攻击者只能看到您的一条消息的加密输出。在高端，你要面对一个知道数百条其他消息的明文和密文对的攻击者，他可以强迫你的计算机用相同的密钥加密其他消息，他可以监控你建筑物的电力线并测量随着加密过程的进行，功耗的微小变化以及各种类似的攻击。标准加密算法经过审查，以确保它们即使对这些强大的对手也有抵抗力。

如果您首先使用自己的加密，即使第二层是军用级加密，与仅使用标准加密相比，您也有降低安全性的风险。

例如，假设您正在加密文本。您首先使用简单的替换密码，然后使用您选择的重击算法。不幸的是，替代密码本质上依赖于从私人信息（即您的明文和您的密钥）中进行数组查找。这使得它们容易受到定时攻击：由于 CPU 缓存的工作方式，如果明文中的两个字母靠得很近，它们的加密速度可能比两个靠得更远的字母更快。这听起来不像是太多信息，但如果攻击者可以观察到足够多的加密，他们就有可能找出明文是什么，而无需破解 AES 或您在上面使用的任何东西。

如果您的自定义加密层根本不与秘密信息交互：即它与已经足够安全地加密传输并且不接触标准加密的密钥的数据一起使用，那么它可能是安全的。至少，不可能绕过标准加密。但是，仍然存在风险，因为每增加一个软件都会带来额外的风险。也许您的自定义层中的错误让远程对手在您的机器上运行任意命令；然后他们可以通过电子邮件发送明文给自己！

那么，带回家的信息是，如果您将一个有缺陷的自制程序（任何类型，加密或其他方式）放在上面，那么拥有一个经过严格审查且没有错误的优秀安全代码（如标准加密功能）仍然可能被破坏同一个系统。

简单的。不要这样做。

首先，加密算法的设计是为了让你、我和我们周围的每个人都可以看到它并尝试破解它。你可以从字面上看AES的数学。很多聪明人都花时间验证 AES。这是良好加密的原则，也是我们可以信任它的原因。

其次，默默无闻绝不是“安全”选项。它没有提供任何好处。如果您真的相信这一点，那么我建议您参考“施奈尔定律”。

任何人都可以发明一个他自己无法破解的安全系统。我经常这么说，以至于 Cory Doctorow 将其命名为“施奈尔定律”：当有人递给你一个安全系统并说，“我相信这是安全的”时，你首先要问的是，“到底是谁你？” 让我看看你破坏了什么，以证明你对系统安全性的断言是有意义的。——布鲁斯·施奈尔，2016

你所做的只是：

• 将不必要的风险引入您的应用程序
• 增加问题的调试时间
• 为一个毫无价值的功能增加了 CPU 时间

安全中最基本的主体。保持简单愚蠢（KISS）。