默默无闻的安全性是可怕的。安全性和晦涩感好吗？

AES -> CipherText -> CustomEncryptionAlgorithm-> CipherText

CustomEncryptionAlgorithm -> CipherText -> AES -> CipherText

#1 楼

从纯加密的角度来看，不要使用自己的加密！
任何保留长度的双射函数都不会降低安全性。实际上，假设用于标准密码的密钥和您的自制密码的密钥相互独立，即使定义为f（x）= x的身份函数也不会降低安全性。降低安全性的唯一可能方法是，如果您的自制程序函数不使用其他独立密钥，并且在密文中泄漏密钥，例如，对输入x的每个单独块执行fk（x）= x⊕k，容易受到已知明文攻击的经典XOR密码。
从实用的角度来看，有些陷阱很重要。我上面提到保留长度是有充分理由的。压缩功能仍然是一种功能，有时压缩和加密可能会导致非常糟糕的结果。这部分是为什么您的第二个示例（在标准加密之前应用自定义算法）的确更糟的原因。它会通过长度泄漏有关明文的信息。您的实现中还可能存在导致其他安全漏洞的错误。从纯粹的理论角度来看，它们不在范围之内。

有人在评论中向我指出，我可能没有充分强调这是多么糟糕的想法。从理论上讲可能不错，但现实世界的工作方式却有所不同。实际上，无论您如何使用它，都必须使用自己的自制加密货币。您唯一真正应该这样做的时间是，如果您是专业密码学家。伯恩斯坦可以做到这一点。 Rivest可以做到这一点。 Rijmen可以做到这一点。你不能。不要用脚射击自己，而要使用正确的算法。

#2 楼

第一次应用自定义加密算法时会涉及风险。
这是基于这样的事实：像AES这样的加密确实会泄漏有关明文长度的信息。

假设的（不切实际的）示例，其中您自定义算法将0x40之类的单字节纯文本“加密”为64个零，将0x02 0x00之类的两字节纯文本“加密”为512个零。

使用AES加密时，攻击者仅仅通过查看AES加密文本的长度，仍然可以知道自定义加密结果的长度。
利用此信息，攻击者可以在没有AES加密密钥的情况下将其“解密”为原始明文。

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

#3 楼

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

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

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

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

带回家的消息是，如果能够保护一组优秀的安全代码，这些代码经过严格审查和像标准加密功能一样没有错误，您将错误的自家程序（各种形式，加密方式或其他方式）放到了同一系统上。

#4 楼

简单。不要这样

首先，设计加密算法，以便您，我以及我们周围的所有人都可以查看并尝试破解它。您可以从字面上看一下AES的数学运算。许多聪明的人已经花时间在验证AES上。这是良好加密的宗旨，也是我们可以信任它的原因。
其次，Obcurity绝不是“安全”选项。它没有任何好处。如果您真的相信这一点，那么我将您引为“施耐尔定律”。


任何人都可以发明自己无法破坏的安全系统。我经常这样说，以至于科里·多克托洛（Cory Doctorow）称其为“舒尼尔定律”：当有人将您交给安全系统并说：“我相信这是安全的”时，您首先要问的是：“到底是谁？您？”请告诉我您为证明系统安全性所具有的意义所做的努力。 -Bruce Schneier，2016年


您要做的就是：


将不必要的风险引入应用程序中
，增加了调试时间问题
为无用的功能增加了CPU时间

安全性中最基本的原则。保持简单愚蠢（KISS）。

评论

---

我之所以考虑这一额外的层，是为了涵盖其他威胁模型。假设我们有以下威胁模型：A）具有AES全自动解密/破解功能的不良演员。 B）具有能力A的坏演员加上手动解密完全自动化方法无法解密的资源。对于A，我认为多余的混淆完全可以克服这种威胁。根据定义，一旦人眼球和手指必须干预，我们现在就在处理威胁模型B。在威胁模型B中，由于缺乏合格的密码专家，您可能会被忽略。

–user3280964
18年5月30日在21:24

---

换句话说，AES击败了手动解密工作。晦涩打败了大规模自动解密。将两者结合可以涵盖两种威胁模型。

–user3280964
18年5月30日在21:28

---

默默无闻可以使机会主义攻击者远离（一个不会攻击的人，因为他有一个目标，但他正在寻找最简单的目标）。

–rackandboneman
18年5月30日在23:56

---

@rackandboneman默默无闻并没有阻止他们。好的配置管理是。

– Shane Andrie
18年6月1日在14:09

---

取决于您所说的“晦涩”和您要防范的内容。车内的有色窗户不能保护您免受子弹的侵害，但通过看到您的鼻子，它们确实可以保护您免受随机行人的伤害。

–烧烤
18年6月1日在18:42

---

#5 楼

只要不是唯一依赖的安全层，默默无闻的安全性就是好，有时甚至是很好。但您的情况恐怕不值得。

以GPG为例。如果使用GPG通过AES加密文件，则文件头将使攻击者将其识别为使用AES加密的GPG文件。如果您随后使用自定义加密来加密GPG文件，则会得到一个可能无法识别的文件。攻击者可能会错误地认为您正在使用任何类型的加密（并且会浪费大量时间，一无所获），或者可能会假设您正在使用自定义加密，然后决定使用密码分析技术来分析文件（并在可能时进行解密）他足够好，否则您的算法就够糟了）。另一方面，如果以相反的方式进行操作（首先使用自定义算法进行加密，然后再使用AES进行加密），则情况毕竟不会发生明显变化。

那就是说，恐怕不值得，因为自定义加密反正有很大的弊端：您必须将加密软件存储在某个地方，并且您的软件是完全自定义的，这意味着如果无论丢失什么原因（备份丢失或被盗等），您都会被搞砸，并且将无法恢复任何数据。

更好的解决方案可能是使用多层加密使用已知和可用的算法。例如，GPG似乎支持双鱼，山茶等。除了AES，我没有经验知道哪种算法应该被认为是最安全的。无论如何，例如，AES-> TWOFISH-> CAMELLIA可能是比AES-> CUSTOM_ALGO更好的解决方案。当然，只要您为每个加密层使用不同的强密码即可！

#6 楼

OPSEC？...

在关键信息和对手之间设置其他障碍通常是一个好主意，只要它能有效地完成即可。

将隐密性作为一种有意义的安全措施是通过OPSEC（操作安全性）原则解决。简而言之，这需要剥夺对手任何信息，这些信息可以帮助他们通过社交或技术方法破坏您的组织。

使用良好的加密技术，只需将密钥保密就可以保护您的数据。任何其他技术层都必须根据自身的技术优点进行论证。

...或半身像

密码学是一门非常复杂的数学学科，小错误可能会带来巨大的后果。在处理密码学时，除非有一位值得信赖的专家指出，否则假定算法的值实际上为零。

在美国，NSA和NIST分别是密码算法和实现的官方评估者。如果您不知道在哪里寻求意见或想要合理的内部政策依据，请从此处开始。

实际上，包装好的加密货币毫无意义。一旦攻击者遇到了良好的加密，他们通常会绕过并攻击暴露未加密数据的端点。

这可能是用户提供信息的Web服务器，馈送到您数据库中的SCADA系统或员工分析或监视信息的工作站。如果您有一个数据泵可以从数据库中提取信息并将其转换为另一种格式以交付给供应商/客户，那将是另一个重要目标。或者，他们可以搜索您的钥匙。

天平上的

向应用程序中添加功能会导致错误并增加故障排除的几率非零。当出现问题时，这可能导致停机时间延长，或者对应用程序中的安全漏洞的响应变慢。由于这些因素，几乎没有价值的安全性功能是一种损害而不是改善。

如果您希望保护自己免受可能对AES的攻击，则应该简单地使用另一个基于审查算法的密码标准，而不是自行开发。您将以更少的努力获得更好的安全性。

#7 楼

安全性和模糊性模式存在两个主要问题。


模糊性会干扰安全性。如果您使用自己的加密货币，则很有可能存在缺陷。尽管领先的专家已经对它们进行了数十年的研究，但即使是最好的系统也存在缺陷。您能够比安全社区做得更好的机会很低。
很少有事情是真正模糊的。加密技术没有很多新想法，您所做的任何事情都可能是对以前完成的事情的一种变体，因此实际上并不是那么晦涩。微小的变化是攻击者用来处理的事情。

#8 楼

不难发现，第一个变体（最后一个是自定义算法）不会损害众所周知的加密的安全性，因为如果可以的话，它将是一种破解众所周知的加密的方法。毕竟，如果攻击者可以帮助他们破解，那么他们也可以在仅使用众所周知的加密技术加密的密文上运行自定义算法。

另一个方向（首先是自定义算法）确实可能损害安全性。通过将冗余引入到众所周知的加密的纯文本输入中，可以潜在地削弱该算法。例如，请采用以下完全有缺陷的自定义“加密”方案：输入两次纯文本以产生“密文”。这导致第二种算法的输入中极度增加了冗余，这可能会削弱某些实际的加密。 （是否削弱AES是一个不同的问题。）Enigma确实发生了这种情况，其中操作员在其明文中重复了三个字母的序列，这使得其密文易受某​​些攻击。摘录自Wikipedia维基百科页面的密码分析：


第二个问题是
指示符中消息密钥的重复，这是一个严重的安全漏洞。消息设置
进行了两次编码，导致第一个和第四个字符，
第二个和第五个字符以及第三个和第六个字符之间的关系。此安全问题
使波兰密码局最早可以在1932年闯入战前的Enigma
系统。1940年5月1日，德国人更改了
程序，仅对消息密钥进行一次加密。

#9 楼

如果您使用相同的密钥来加密AES和CustomEncryptionAlgorithm，则解决方案1可能会降低安全性。

CustomEncryptionAlgorithm可能会允许推导密钥，因此也会损害AES。

如果您为CustomEncryptionAlgorithm创建一个唯一密钥，您应该会再好的一次。

类似KEY = SHA-2（AES-CipherText）

#10 楼

问题是您的自定义加密功能可能存在错误，并以某种方式降低了安全性。确保您的CustomEncryptionAlgorithm不会降低安全性的唯一方法是让比您，我和您团队其他成员更聪明的研究人员倾注并检查您的工作。但这根本不是什么晦涩难懂的例子。

举个极端的例子：

public string CustomEncryptionAlgorithm(string plaintext) {
    var ciphertext = plaintext.shuffle();
    return "password";
    return ciphertext; // ya ya. I know. You'd never make a bug that obvious.
                       // tell it to the guy who did the 'goto bug' at apple
}

你会得到这样的东西结果是，如果您使用以下方案：



AES-> CipherText-> CustomEncryptionAlgorithm-> CipherText
：

'abcABC123!@#' -> 'password'
'correct_horse_staple_battery' -> 'password'
'password' -> 'password'

另一方面，如果您使用了其他方案：



CustomEncryptionAlgorithm-> CipherText-> AES-> CipherText

'abcABC123!@#' -> '8ZnO44trPK48kqr3rDxkdQ=='
'correct_horse_staple_battery' -> '8ZnO44trPK48kqr3rDxkdQ=='
'password' -> '8ZnO44trPK48kqr3rDxkdQ=='

可能稍微好一点。但丝毫没有任何好处。

#11 楼

就像已经说过的：谁是攻击者？

这真的是您必须首先发现并定义的内容！

电视遥控器出现问题的是您的高科技恐惧症奶奶吗？控制？你的小妹妹（也很爱管闲事）？您的父亲实际上是对计算机进行编程和管理的，并且知道如何卸下硬盘驱动器？当地的学校恶霸是谁为您工作？有组织犯罪？一家公司可能会花费数百万美元租用云计算机进行破解攻击？第三世界独裁者？您所在国家/地区的FBI，NSA或同等机构？

第二：您的“加密” 1能为攻击者提供什么额外的真实安全保护？除非您能很好地说明为什么需要再次加密密文[2]或非常有用，否则您不应该这样做。更高的复杂性并不意味着更高的安全性，而是意味着更多的错误以及更多无法正常工作的机会？

为什么攻击者不会不闯入或潜入您的房屋并放置一些间谍软件或键盘记录器在你的电脑？您确定加密会对橡胶软管加密分析有任何帮助吗？[3]，或者如果没有机会，谁有能力破坏AES但又无法联系到您或您最亲近的亲戚？




让我们说，您获得强大而安全的加密的机会与我在月球上行走的机会一样高；使用
加密，不仅所有内容都必须使用正确的密钥，而且
没有它，任何东西都无法工作...

我不知道由外部人员构建的任何密码系统
没有经过专家检查的领域，并且有多少由最好的专家发明的强大的
加密系统被破坏了？

第二次世界大战中的交流就是一个例子从德国到
潜艇。一些非常秘密的交流是“仅限军官”，这是
预先加密了元信息，然后用常规密钥
将两者都加密并发送了。接收到无线电/谜操作员后，将
解密消息并将元信息和仍加密的
块传递给警官。 （例如，请参见此处）
”，其中，将橡胶软管频繁地强行应用到脚底
，直到发现密码系统的钥匙
，此过程可能需要出奇的短时间
，并且在计算上非常便宜。”

#12 楼

简短的答案：可以，但不能在您的示例中使用。

长的答案：其他答案已充分涵盖了您的示例为何没有那么有用并可能会受到伤害的原因。话虽如此，晦涩难懂可能会很有帮助。恰当的例子：不要将SSH放在端口22上。如果从22更改为2222，将只有极少的暴力尝试。如果更改为端口10000+ rand(1,55535)，它们可能会完全消失。另一个例子是端口爆震。基本上，模糊性在连接过程中最有用，而不是加密或密码。

#13 楼

您将第二种算法称为模糊性，因此您似乎假定它不会增加任何安全性。

如果实际上没有增加安全性，为什么要使用它？除第一个密码外，还使用第二个密码进行aes加密。两倍长的密码比两个密码安全得多（例如：2^2+2^2 = 4与2^4 = 16），尤其是在第二种算法仍然不安全的情况下。

#14 楼

如果操作正确：请确保。问题是您怎么知道这是正确的？您当然可以编写一些内容，使其通过各个层次泄漏信息。最明显的是长度和重复。也使用相同的密钥可能会出现问题。

很难说出什么是正确的，什么是不正确的。当然，您可能会争辩说，在AES之前使用ROT13会使它有点安全，而我的直觉会说……好吧，至少不会造成伤害，但我实际上并不知道。

我的直觉是，如果您应用一种算法，该算法在不改变长度的情况下产生与随机性没有区别的输出，然后再应用AES，那么它至少不应降低AES的安全性。

#15 楼

模糊性是安全性（一般）的一部分，并且与安全性（在您的情况下为AES加密）正交。默默无闻可以抵御与加密不同的威胁。以密码为例-需要使用加密散列来防止明文从服务器泄漏，TLS防止窃听网络流量，而晦涩的[*******]密码形式则防止随机观看者窥视明文。因此，您不能（仅）凭一己之力来实现安全性，但是通常要采用含糊不清的安全性。在现实世界中，模糊性意味着隐藏元数据，例如使用密件抄送而不是抄送/收件人邮寄或阻止第三方Cookie。

#16 楼

不好，不好，不好。

有一些远东移动协议的轶事，用于SIM初始化或类似的事情，它结合使用RSA（好的，安全的和强大的）和自制的东西。

决定性的弱点不仅在于自制的“附加”加密。但问题在于，实际上，在特殊情况下，其他方法与RSA关联，会导致部分密钥泄漏。我不记得详细信息，因为很多年前我曾作为讲课讲到这些细节。

但问题的关键是：在不安全的协议中添加了不适当的自制软件，您可能会使该协议比其原始版本。所以，这是一个重大的难题。