首先,这似乎应该是一个普遍的问题,因此,如果我错过了一个较旧的线程,我感到抱歉。而不是“设计AES2”之类的东西。

我当然熟悉这样的说法,即“永远不要实现自己的加密货币”,而且我最近还了解了一些原因攻击和常见错误等。但是,我从来没有真正喜欢过这个答案,因为如果没有人实施,我们将永远不会得到它。而且既然我们已经拥有了它,那么肯定没有人会听并实现它。可以用于新平台,新发布的算法等。

评论

@gowenfawr如果人们认为那是最好的话,我很乐意将其移到那里。让我知道您想要我做什么,因为我承认不太确定该放在哪里。

应用密码学已过时,并且更针对设计算法的人员。他的书《密码学工程学》是新近出版的,与加密实施者更相关。

@gowenfawr这主要与风险管理有关,与加密本身无关。因此,对于信息安全而言,它比密码术要好得多。我投票决定关闭它作为Crypto的主题。

顺便说一句,只要您愿意就可以实施加密。担心来自在需要安全性的生产环境中使用实现。

我投票结束这个题为离题,因为这是关于风险管理,而不是密码学。它是有关信息安全的主题。

#1 楼

“允许”或“禁止”不是正确的用语;如果您敢实现自己的算法,教皇将不会开除您。问题在于,执行自己的实现是否明智。

对于学习而言,执行自己的实现是一个好主意。它将教您很多有关上述算法如何工作的知识。有关如何设计密码算法(尤其是对称加密和哈希算法)的许多细节都来自实现方面的考虑-算法设计人员始终试图找到一种结构,以确保以最高效率(速度,代码大小)确保所需的安全属性。 ...在各种架构上)。

当心“生产”。设计上的加密算法旨在处理机密元素(特别是密钥,将很多秘密集中在几位中),因此,实现不泄漏信息至关重要。这比通常设想的要难得多。例如,一个非常常见且非常流行的主题是通过软件平台上的缓存行为(用于RAM访问的L1缓存和用于跳转预测的CPU内缓存)定时攻击攻击。至少从概念上讲,这种攻击可用于从正在运行的系统中提取密钥,通常是从在同一硬件上运行的另一个VM中提取密钥(这种攻击已在实验室条件下反复进行了演示,因此似乎有可能适用于此类攻击)。实践)。可以编写不受高速缓存定时攻击影响的AES或RSA实现,但需要格外小心,并且需要非常清楚地了解它们如何工作以及计算机如何工作。即使您不编写汇编代码,也必须至少考虑使用的语言的编译器如何将代码转换为汇编代码。

最重要的是,在野外部署自己的实现很少是一个好主意。有时您别无选择,因为(例如)您的目标体系结构和语言没有可用的实现,而许可证却与您想做的事情兼容。但是,这不是常见的情况。从业务的角度来看,这是一件好事。


所以您应该真正编写自己的密码库...而不要使用它。如果您可以写一个库,让两个月过去,再读一次,但没有发现任何错误或不理想的内容,那么您就没有足够的努力。

评论


$ \ begingroup $
我认为最后一段总结起来很出色。我认为经常会发现新的攻击,因此这种方法将迫使您紧紧关注这些问题。通过扩展,我想这也意味着加密实现永远不会“完成”。我希望可以将其与Mike Ounsworth关于商业/经济方面的信息结合起来,但是我将以全票通过。
$ \ endgroup $
– Leonhart231
2015年5月10日下午4:09

$ \ begingroup $
如果要出于学习目的实施密码学,您会推荐什么资源?
$ \ endgroup $
–Archit Verma
16年5月9日在18:50

#2 楼

许多软件安全供应商将仅仅因为不愿依赖外部代码而实现自己的加密库。通常出于安全原因(“我们不知道是谁编写的,或者谁被允许推送更新”)和/或出于维护原因(“每次他们推送更新,我们也必须”)注意这些公司然后在质量保证和安全保证上花费大量时间和金钱,以减轻漏洞的危害。

例如:最近在许多标准TLS实现中发现的SMACK漏洞(包括OpenSSL,Java的JSSE,Apple的安全运输等)。任何与任何这些实现​​相关联的人都是脆弱的。如果您有自己的实现,则可能会有错误,但是希望它们与其他实现是不同的错误。

最重要的是:只有在您具有测试能力和专业知识以完全满足您的库是弱点的情况下,才实施自己的加密库免费,大多数中小型公司都无法使用。

评论


$ \ begingroup $
您甚至可能需要特殊的硬件来测试定时攻击之类的东西。
$ \ endgroup $
–尼尔·史密斯汀(Neil Smithline)
15年5月8日在21:26

$ \ begingroup $
@NeilSmithline还可以进行功率分析。
$ \ endgroup $
–多项式
15年5月8日在22:25

$ \ begingroup $
人们高估了在专有加密实现中发现错误的难度。大多数人会犯非常相似的,众所周知的错误,不需要像人们认为的那样理解,检测和利用的技能。
$ \ endgroup $
–ZoFreX
2015年11月12日,0:50

#3 楼

问题实际上不是在算法的设计中。在已发表的论文中,算法描述仅需几行。然后,您完成了0%的加密工作:您必须为其安全级别找到一个可证明的下限,即O(聪明的攻击者所需的最少工作量)。这填满了一页又一页的数学论文,以及数学家和加密分析师的许多其他评论。合理的假设是,在声称的安全级别内不会发生攻击,这可能需要社区多年的审查。然后是政治,您和政府机构(除了作为纳税人)之间的任何联系都可能被视为对算法中潜在存在后门的怀疑。有了足够的可信度和说服力,您的算法最终可能会被接受为标准的候选者。从2005年的描述到2015年的第一个RFC 7479,DJB的ed25519花费了10年的时间。实际上,每周都有许多关于“经过认证的第三方”,“安全物联网”和“高效的新”的论文。然后没有人再听到他们的消息。在奉献,资源和时间方面,后续操作的成本非常高。冒着风险。但是,“默默无闻的安全性”对于专门的攻击者而言无法存活超过几个小时。在工业环境中。作者一旦离开公司,“秘密调味料”就被认为是完全不安全的(可能随时发生)。因此,没有人会以这种方式进行投资,更好的合理投资是使用具有经过验证的安全级别的现有公共算法,该算法可以保证数天,数年或数百年的数据安全。回到您的问题:重新发明轮子的经济性很差。

评论


$ \ begingroup $
尽管获得了很好的信息,但OP明确表示,他们在询问实施现有标准,而不是发明新算法。这是一个不同问题的好答案。
$ \ endgroup $
–麦克·恩斯沃思(Mike Ounsworth)
2015年5月9日14:49