每个人都说自制加密不是一个好主意，因为有一天攻击者会知道该算法，这听起来很合理。所以这似乎是主要问题，另一方面，已知算法是每个人都知道的，并且最有可能安全使用。对于一些偏执的开发人员来说，创建一个像 AES(HomeBrew(openText)) 这样的方案是否有意义，其中 HomeBrew 将提供加密或某种其他类型的转换，以使攻击者更难，因为他们甚至不得不猜测这些事情如果他们设法以某种方式破坏 AES（前提是他们没有算法）。那么在这种情况下，我们不会充分利用这两种方法吗？
一个密码系统应该是安全的，即使系统的所有内容，除了密钥，都是公共知识。
因此，如果 AES 被破坏，您的自制算法可能会更容易并且已经被破坏。
我意识到您最初的问题的一部分是：
provided they do not have the algorithm
然而，由于这违反了 Kerckhoffs 的原则，您的自制方法本身就有缺陷且不安全。
这是一个问题的主要原因是它为您的系统增加了多少安全性是无法量化的。我在这里向您推荐 Thomas Pornin对类似问题的回答：
另一个转折是算法晦涩难懂会损害安全性。我在上面解释的是，在安全性方面不能信任模糊性：它可能会增加安全性，但不会增加太多（而且你无法真正知道“多少”）。事实证明，它也会降低安全性。问题如下：制定安全的密码算法非常困难。唯一已知的方法是发布该算法，并等待世界各地密码学家的集体智慧来啃它并得出一个结论，该结论可以表示为“可以那样破解”或“显然很健壮”。一个算法只有在至少三四年内抵抗了数十或数百名有能力的密码学家的猛烈攻击时，才被宣布为“好”。
因此，如果您担心 AES 可能很快会被破坏（或者根本不使用 AES），那么您应该使用另一种算法。我假设您系统的其余部分不是 100% 安全的 - 因此，与其浪费时间、精力、精力和资源来创建自制算法，不如将这项工作花在其他地方，在那里可以量化它实际上正在增加安全。所有代码都有成本，而不仅仅是初级开发人员的薪水在创建它。每个人都需要维护和理解它——每个额外的人学习它是如何工作的都是算法被泄露的额外途径。不要浪费你的时间。
它可以工作，并且将是深度安全而不是默默无闻的安全，但是有几种方法可以灾难性地搞砸这个：
使用HomeBrew容易受到侧信道攻击的算法。例如，现在攻击者可以进行简单的时序或缓存分析，并AES完全绕过该部分。你的实施安全吗？
在算法之间重用材料。例如AES(HomeBrew(openText, "secret"), "secret")，如果您重用密钥和随机数，它可能容易受到密码分析的影响。这是一个遥远的威胁，但如果您想保持相同的安全标准只是AES(openText).
使用脆弱的HomeBrew实现。如果文本包含空值、大于某个大小、小于某个大小、看起来像这样、包含有效的 unicode 或包含无效的编码等时它可能会中断。这是一个编程问题，但会打开你的从拒绝服务到不正确的身份验证或更糟的任何事情。
总而言之，我觉得这是一个有趣的想法，但不是一个实用的想法。也许使用不是自制的东西会更好；有更安全的方法来增加您的安全性。
就其本身而言，您的自制算法是一种通过默默无闻的安全形式。但是，当与已知的良好加密结合使用时，您的自制算法可能会被视为深度防御策略。直接引用维基百科，
系统可以通过隐蔽性来使用安全性作为纵深防御 措施；虽然所有已知的安全漏洞都将通过其他措施得到缓解，但公开披露正在使用的产品和版本使它们成为这些产品和版本中新发现的漏洞的早期目标。攻击者的第一步通常是信息收集；这一步可能会因隐匿而被安全延迟。
如果今天公开披露 AES 中的漏洞，攻击者仍然需要一些时间才能弄清楚如何破解您的自制算法，让您有时间切换到另一种算法。俗话说，“不要把所有的鸡蛋都放在一个篮子里”。
对于真正偏执的人，您可以采用两层不同的标准加密，例如 AES+DES。但是，拥有多层不同的加密并不是免费的。权衡是您的密文变得更粗。
Dieter Vandenbroeck写了一篇关于何时通过默默无闻的安全有意义的文章：
通常，通过默默无闻的安全原则是完全错误的。该原则背后的想法是在您的解决方案中将模糊性作为主要的安全手段。当然，这不是真正安全性的有效替代品：一旦您的模糊模式被破坏，您的安全性就会被破坏。它可能会形成对自动化脚本的防御，但有足够决心的攻击者将始终能够通过这种防御进行战斗。
在您的情况下，您将没有自动脚本，并且当 AES 可以以自动方式破解时，自制软件可能会存在更多缺陷并且更容易破解。所以不，与普通的 AES 相比，我认为自制软件不会给您带来额外的安全优势。