Security 使用内置函数

我正在用C语言开发一个Windows窗体应用程序。我听说人们不应该在代码中使用内置方法和函数，因为黑客对这些内置方法有着深刻的理解，并且知道如何使它们失败。相反，人们应该始终使用他/她自己的函数和方法，如果没有，则智能地调用这些内置函数新做的函数。这是真的吗

支持我观点的一个例子是，我看到开发者总是开发自己的加密算法，比如AES、DES、，RC4和哈希函数，因为它们认为内置加密算法有很多次后门。

除非您知道应用程序将使用的内置方法的特定故障模式或弱点，并且知道如何最小化或消除它们，使用语言或库设计人员提供的方法可能更好，这些方法通常比普通程序员为某个特定项目在运行过程中提出的方法更高效、更安全

---

你的例子绝对不支持你的观点：在没有领域背景的情况下开发你自己的加密算法，并由密码分析师进行审查，然后将其应用于安全关键代码中，这会导致灾难。即使开发自己的行业标准加密算法的自定义实现也可能会出现问题，如果您缺乏经验，几乎肯定会出现问题。

什么？！不，不，不！告诉你这件事的人都错了

有一种常见的谬论认为，已发布的源代码更容易受到h4ckerz的攻击，因为任何人都可以发现其中的缺陷。然而，我很高兴你提到了加密，因为这是一个领域，在这里，这条推理路线与谬论一样突出

其中一个是关于OP中的一个开发人员的，他被赋予了化名Dave，他对发布的代码有着同样的恐惧。戴夫，就像你看到的那个开发人员，正试图自制自己的加密算法。以下是该帖子中最流行的评论之一：

Dave有一个根本错误的前提，算法的安全性甚至部分依赖于它的模糊性——事实并非如此。散列算法的安全性取决于我们对数学理解的局限性，在较小程度上取决于硬件对其进行暴力攻击的能力。一旦戴夫接受了这个现实，并且它确实是现实，阅读维基百科关于散列的文章，问题就在于谁更聪明——戴夫自己，或者一大群专门研究这个非常特殊问题的专家。重点补充

事实上，就目前的情况来看，on Security.SE是“不要自己滚，也不要当戴夫”

虽然这都是关于加密的，但这通常适用于大多数开源软件。发现和修复后门的机会随着对代码的每一组新的关注而增加。这应该是一个简单且无争议的前提：人们寻找的东西越多，被发现的机会就越大。是的，这适用于寻找漏洞的恶意用户。然而，它也适用于超级用户、白帽黑客、安全研究人员、密码学家、专业开发人员和其他为善工作的人，这些人的数量通常有望超过为恶工作的人。这也隐含地依赖于一个错误的前提，即黑客需要查看源代码才能做坏事。这显然是错误的，因为大量的专有系统的源代码从未发布过。人们想到的各种Microsoft和Adobe程序多年来都被漏洞淹没。也许有读代码使黑客的工作更容易，但可能不是-更容易在源代码寻找一个攻击向量或只是使用扫描工具和脚本对编译二进制？ tl；别当戴夫博士。滚动你自己意味着你必须在每件事上都做到最好才能成功，而不是从社区提供的最好的东西中取样

心痛 在你的评论中，你反驳道：

那么，为什么openSSL中的Heartbleed错误[之前]没有被发现和纠正

因为没人看。这是可悲的事实。区别就在这里——一旦有人找到了它，会发生什么？现在，成千上万的安全研究人员、密码专家和其他人都在关注它。假设在我前面提到的一个专有产品中存在同样的漏洞，它很可能存在。一旦它被抓住了，如果它被抓住了，问问自己：

现在，负责任公司的程序员团队能否从整个全球安全专家、密码学家和其他分析师社区的帮助中获益？ 如果发现了一个如此关键的bug，那就是一个很大的If！在您的软件中，您是否准备好处理自定义实现引起的影响？

---

祝你好运重写一个操作系统

---

ystem@EdHeal哈哈哈，这真的很有趣，但你知道我说的是规模不大的项目。所以你不相信内置函数，不管它是什么-猜猜我们使用的库之一。但是请相信编译器。相信操作系统。电话线在哪里sand@a_horse_with_no_name我不确定c标记在这里是否真的相关。这有点离题了，OP正在开发一个C Windows窗体应用程序。这是一个语言不可知的问题。@khan-你希望信任什么-一个在你公司工作的程序员小组。或者是一个更多元化的团队和众多的程序员，他们甚至不知道你们公司的存在？大多数（如果不是全部的话）都有破坏加密的动机