NIST对Keccak / SHA-3的更改是否有问题？

#1 楼

我确实担心，但不是出于对SHA-3的抵抗。我担心它会被接受。

从技术上讲，NIST想要做的就是声音。他们确实想以某种方式“打破”传统规则，即具有n位输出的哈希函数应抵抗强度为2n / 2的碰撞以及强度为2n的原像（第一和第二）的碰撞。相反，NIST希望将安全级别统一为2n / 2。实际上，对于大多数实际目的，对原像的128位抵抗力已绰绰有余。在SHA-3竞赛的NIST邮件列表中，John Daemen本人最近（今天上午）认为，对SHA-3的拟议修改不仅会保留针对原图的128位保护，而且甚至可以确保128位防止多目标原像，即比具有128位输出的“经典”哈希函数所提供的功能更好。

“协调”安全级别的好处在于，可以做到这一点，在Keccak的情况下，可以通过降低内部“容量”来提高性能（软件性能通常是Keccak的痛处，因为它实际上并不比SHA-2快）。

接受，完全是另外一回事。在许多情况下（不幸的是，在大多数情况下），在给定系统中使用或不使用特定算法的决定将由对密码学的掌握程度不如对密码学家那么敏锐的人来决定。大多数人没有想到碰撞和原像之间会有区别。他们脑海中所发生的不是“嗯，NIST在学术安全性和性能之间做出了取舍，而是一种被其他密码学家认可的可靠方法，这很好”。相反，它遵循“ OMG的路线，他们现在改变了算法，这全是后门！”。他们最终决定使用自定义方案，例如MD4与MurmurHash的异或，或其他任何等同的哑巴。

以我的经验，使用加密技术的系统不会因为性能之间的合理平衡而被破坏。他们之所以失败，是因为有人误用和/或有创造力，而是改用了自定义的弱方案，从而滥用或根本没有使用一种好的算法。

AES被广泛采用的原因之一是Rijndael没变。 NIST并没有改变整个算法中的任何一点。他们只是照原样进行，即由非美国发明家指定，也由所有其他非美国密码学家在比赛中进行了分析。

如果NIST想要最大可能接受SHA-3，那么他们应该使Keccak保持其“第三轮”规格不变。 “不变”是指“真的不变”。这不仅涉及内部的“容量”，而且还涉及填充和其他所有方面。

不惜一切代价接受并不一定是一个值得的目标；而是必须接受。也许NIST认为，拥有一种技术上良好且快速（或不太慢）的算法比迎合那些做出愚蠢的技术决策的信息灵通的偏执经理更为重要。但这至少是一个值得问的问题。

#2 楼

对于点1确实存在一些困惑。

困惑可能源于Keccak具有输出大小数和容量的事实。输出大小对安全强度几乎没有影响。容量才是真正决定安全性的要素。因此，当该帖子说NIST仅将两个安全级别标准化时，这是正确的（就演示文稿而言，这绝不是一成不变的，请参见下文），并且原始提案的安全级别超过了此级别。我敢打赌，很多人都读过这篇文章，但是，他们很困惑，而且只有两种输出尺寸。

凯尔西在CHES2013上的演讲的这张幻灯片说会有4种不同的输出版本（ 224、256、384和512）以及2个可变长度的输出版本。但是，只有两个容量（256和512），因此有2个安全级别。

几张幻灯片之后，我们阅读了“由哈希函数内部决定的安全级别，而不是输出大小”。我认为这对于过去总是被告知冲突可能性是输出位长度除以2（由于生日攻击）的开发人员来说非常令人困惑。相反，现在碰撞概率将取决于开发人员永远不会与之交互的内部结构。这也引发了一个问题，为什么当两个都提供相同的位强度（128位）时为何具有2个不同的输出长度（224和256）？

另一点是稍后出现的几张幻灯片“原像强度=碰撞强度”。这与开发人员所熟悉的有很大的不同。 NIST在同一张幻灯片上也承认：“但这与提交内容相比有很大的变化”。因此，SHA3-256抵御前映像攻击的安全强度将是128位，而不是像我们期望的SHA2-256那样是256位。

目前，我们通常认为，如今，大约80位的安全级别足以保证安全。因此，建议的版本现在应该还不错。在我看来，原像安全级别与过去使用的安全级别不同的事实在我看来有些令人不安，因为它在技术上比相同大小的输出SHA2函数弱。同样，考虑到当今开发人员所使用的安全性，围绕安全级别和输出长度的混淆也不是一件好事。射击，这甚至在NIST人士之间引起混乱（请参阅其他演示文稿）。关于第二点，同一演示文稿中的这张幻灯片提到了填充的变化。我对此并不十分熟悉，因此我无法真正评论它如何影响安全性。

更新

我认为应该指出的是， NIST还没有决定任何事情。我刚刚在约翰·凯尔西（John Kelsey）的SHA3竞赛邮件列表上看到一封电子邮件，其中列出了NIST可以做的以下3种可能性（暗示尚未决定）。


可能性＃ 1：它们都具有512位的容量，因此保证提供256位的安全性。由于256位安全性是NIST所关注的最高级别，因此这是有道理的，但是由于它不是所提交的版本，因此实际上仍然存在过程方面的顾虑，即使仅以竞争性的理论方式，它也较弱。 （也就是说，如果您担心需要超过2 ^ {256}个工作的攻击，它会更弱。）如果您以某种方式认为n位固定长度哈希函数必须具有n位的不可微范围，那么它也不起作用。 ，尽管我不明白为什么该要求特别有意义，并且，如果我们选择了其他不支持该要求的候选人之一，我认为现在不会有人提出这一要求。

可能性2：SHA3-224和SHA3-256获得512位容量，SHA3-384和SHA3-512获得1024位容量。这并不比所提交的要弱，并且保留了n位散列函数的原像电阻和n位的不可区分性。但是对384位和512位散列大小的性能影响相当可观，并且由此带来的实际安全益处为零。

情况3：SHA3-224获得448位，SHA3-256获得512位，依此类推，直到1024位的容量。这只是功能更独特的＃2，但这恰好是提交给SHA3的内容，它对于SHA384的性能也有所提高。


因此，当第1点显示“ SHA -3标准将仅提供128位和256位版本。”目前尚不完全正确，因为SHA-3标准尚未确定下来，并且仍在讨论更改。因此，我们不知道该标准将提供什么。

#3 楼

阅读约翰·凯尔西（John Kelsey）撰写的CHES'13演讲确实使事情变得更清楚。

基本上，整个事情（包括输出长度和容量）似乎可以归结为以下事实：NIST希望将两个版本的NIST标准化基础海绵函数SHAKE256和SHAKE512（分别具有256和512位的容量），然后将实际的SHA3哈希函数定义为具有固定输出长度和参数的海绵函数的特定应用。

到目前为止随着海绵功能标准化的发展，我认为这是个好主意。使用海绵功能可以做很多事情，而使用传统的哈希函数则不能（那么容易）做这些事情，而拥有标准化的海绵功能将使人们充满信心，因为他们可以建立在标准的基础上以及经过充分测试的原语。最终，甚至有可能每个人都将习惯于直接使用SHAKE256 / 512函数，而实际的SHA3函数只不过是历史上的好奇心而已。

我什至可以看到将标准限制为仅两个容量值的意义，因为显然它简化了实现。但是，问题在于所选的容量值，特别是具有C位容量的海绵功能仅提供C / 2位安全性来抵御碰撞和原像攻击的事实。
因此，如果最大海绵容量是512位，那么您永远不会获得超过256位的原像电阻。

与SHA-512进行对比，SHA-512应该提供完整的512位的原像电阻（以及256位的碰撞电阻），而SHA3突然看起来不太好。
当然，有人可能会说256位安全性足以满足任何需求，因此没有任何针对性。就是说，Kelsey描述的提案的一个相当明显的特征是，在该提案下，每个SHA3变体在抵抗强力原像攻击方面都比相应长度的SHA2变体严格更弱：甚至SHA-256也提供256位原像抵抗力，而正如Kelsey所述，SHA3-256仅具有128位安全性。

最终，我认为这里的基本哲学问题是人们是否认为碰撞或原像抵抗是最重要的加密哈希函数的安全性属性。如果主要涉及需要抗碰撞性的应用程序（例如数字签名），那么Kelsey的建议很有意义：从n位哈希中获得的碰撞抗性不能超过n / 2位，因此再也没有尝试的意义了。另一方面，如果您担心原像抵抗（例如，密码哈希），那么拥有少于全部n位的安全性似乎是在浪费空间，更不用说可能引起误解了。

最终，我认为NIST应该做的（不是让他们有任何理由在乎我的想法）是：


如果要将SHA3定义为drop -SHA2的替代品，应该是即插即用的替代品，即应确保对碰撞和原像攻击具有相同的抵抗力。
是的，这意味着您将需要1024位海绵适用于SHA3-512。处理它。
是的，这也意味着SHA3-256会慢一些，因为它需要512位海绵而不是256位海绵。您可以定义海绵数量减少的变体（例如“ SHA3-256 / 2”和“ SHA3-512 / 2”），但是说实话，我不确定是否真正需要它们。您可以建议那些想要进行优化的用户直接使用SHAKE256和/或SHAKE512。
对于224位和384位版本，谁在乎呢？我知道您必须定义它们，因为SHA2拥有它们，但是老实说，到底谁使用它们？就像Kelsey所建议的那样，只需调整并截断256位和512位版本，就像SHA2一样。

Ps。您可能会注意到，我在这里没有对内部调整进行任何说明。那是因为我对他们一无所知，即使我知道，也可能不了解任何有意义的事情。对不起。