3

After reading this topic:

How do I construct a 256-bit hash function from 128-bit AES?

It looks like it can be done. If we have 128-bit into 128-bit secure mapping, indistinguishable from random (but vulnerable for birthday attack itself, because of its size), can we construct secure 256-bit hash function (especially in case of birthday attack), just by concatenation of two 128-bit outputs?

It looks like until our 128-bit hash is not keyed, it may be problematic. Because - how to feed our 128-bit hash functions, while we have only one input, and functions are the same. But if they are keyed, we can use just two different keys. Am I right? Does this method have any drawbacks that I am not aware of?

PS For me it looks like we can break half of the output with complexity $2^{64}$. Isn't it a problem? Do standard 256-bit hash functions have the same vulnerability?

Tom
  • 1,221
  • 6
  • 16
  • 2004 -Joux is the first one the concatenation. 256-bit hash functions have the same problem? Why! – kelalaka Sep 26 '22 at 10:42
  • @kelalaka in this paper they claim that concatenating the result of several hash functions is not secure. So how 256-hash functions may have the same problem? What do you mean? I didn't go deep into that paper, but it looks like they didn't consider keyed hash function. In one example they wrote: two instances of SHA-1 with different constans (and I assume constans are known to all). So this is something different than keyed hash functions, which are in fact two different hash functions, but you don't know how they differ, opposite to the case of known constans. – Tom Sep 26 '22 at 19:57
  • Your title and body are a bit confusing. A keyed hash function like HMAC can be used to create a MAC or a PRF. So basically what you might be asking is the collision of the instance of two HMAC. Why do we need this? as you see on your linked Q, the OP has a platform and want to use AES engine out of box. – kelalaka Sep 26 '22 at 20:18
  • @kelalaka by the way D.W. wrote there's no really good, well-vetted way to build a 256-bit cryptographic hash function out of AES. But in ECHO hash they do concatenation of AES outputs, from what I understand from "ASIC Evaluation of ECHO Hash Function". I'm thinking about this only for theoretic purposes. Also it may be the way to use good, efficient 64-bit or 128-bit arithmetic primitives, to build hash function, which we can't use in 256-arithemic in efficient way, because 256-bit arithemic computations are much, much slower, than for example 64-bit. – Tom Sep 26 '22 at 20:43
  • I mean for example multiplication in GF(2^256) in some hash function design. We can't use it efficiently, because CLMUL instruction set does not allow for GF(2^256) multiplication and implementing it by your own would be slow. We have only good, efficient instructions for at most GF(2^128). So if I want to build some hash function based on multiplication in GF, it would be not efficient to use GF(2^256), but I can use efficiently GF(2^128), but such result would be to small. Then maybe solution would be concatenation. – Tom Sep 26 '22 at 20:51
  • Not sure what your definition is of "well vetted", but it would be easy to build a $128n$ bit Feistel network using AES as the round function and then take it from there by XORing streams. Not efficient, but what's the rush? – Paul Uszak Sep 26 '22 at 21:44
  • @PaulUszak I was quoting D.W., he wrote this in https://crypto.stackexchange.com/questions/661/how-do-i-construct-a-256-bit-hash-function-from-128-bit-aes. – Tom Sep 26 '22 at 21:52
  • You could probably use https://en.wikipedia.org/wiki/One-way_compression_function#Davies%E2%80%93Meyer to create a compression function, then a (truncated) MD-style hash. Then, turn the hash into a XOF with some kind of iterated hashing. But I don't really see the need to do this. First, the construction will be extremely slow, and the security guarantees and bounds will probably restrict the domain of this hash. – Marc Ilunga Sep 27 '22 at 08:47
  • @MarcIlunga I want to build hash function based on multiplications. They can't be done efficiently for 256-bit numbers, so I have to use at most 128-bits arithmetic, but 64-bit would be the best. However such small functions are vulnerable for collisions, even if they would be secure from any other standpoint. So easy way to fix this is concatenation, but this seems to make a difference only under assumption these hash functions are keyed. Designs with hash functions that differ only by some known constans are broken according to https://link.springer.com/chapter/10.1007/978-3-540-28628-8_19 – Tom Sep 27 '22 at 12:56

0 Answers0