6

Something about encryption and hashing has always bothered me.

Given a cryptographically secure hash function $H$, I can produce an arbitrarily long key from any seed $s$ by recursively applying $H$ to the seed $(s, H(s), H(H(s)), ...)$. Then I can XOR the resulting array with any plaintext $x$ to produce my ciphertext.

Similarly, given an encryption function $E$, I can produce a hash of any input $x$ by simply encrypting each block of $x$ with itself, and then XORing the results together.

So why, then, do we use different functions for hashing and crypto (say, SHA-256 vs. AES)? If one of them is secure, shouldn't it work for the other purpose too?

otus
  • 32,462
  • 5
  • 75
  • 167
user541686
  • 1,409
  • 1
  • 11
  • 24

2 Answers2

9

You are correct: The 'workhorses' or primitives of cryptography, hash functions and block ciphers, can be used in such a way that they accomplish each others tasks: A hash function can be used to generate a key stream just as a stream cipher or block cipher in CTR mode (see e.g. Salsa20). And a block cipher can be transformed into a hash function (e.g. a Davies–Meyer compression function inside the Merkle–Damgård construction).

So why use different functions? Well, hash functions are not as versatile as block ciphers for the purpose of encryption - you can't do CBC mode with a hash function, for example. And block ciphers are generally not as well suited to the task of hashing as a purpose built compression function - they tend to have smaller blocks and relatively slow key schedules (or key schedules which are not secure when the attacker can control all the inputs). For efficiency's sake, it is easier to design a really strong and fast block cipher and a separate really strong and fast hash function than it is to design a single function which is really strong and fast in both capacities.

P.S. The hash function constructed from a block cipher you describe in your question is not cryptographically secure - you can find a collision merely by re-ordering the blocks of the message.

J.D.
  • 4,455
  • 18
  • 22
4

J.D.'s answer explains why you might want a block cipher in addition to a hash function. TL;DR: versatility.

Stream ciphers, however, are not very versatile – at least synchronous stream ciphers are not. Yet they have not been replaced by hash functions. Why?

Partly because they have been replaced by block ciphers instead (AES CTR, specifically), but also because of their speed. Hashes have been designed to quickly process input and to produce a constant width output. They like long inputs, which let them amortize padding and other overhead. Encryption requires a long output as well and most hash functions are not very fast for that.

Similarly, given an encryption function $E$, I can produce a hash of any input $x$ by simply encrypting each block of $x$ with itself, and then XORing the results together.

This is not secure. A XOR allows you to change order, producing collisions and second preimages for anything longer than one block.

(It is also more like a MAC than a hash, since you need a key.)

Community
  • 1
otus
  • 32,462
  • 5
  • 75
  • 167