3

When Argon2, Balloon, scrypt, bcrypt¹, PBKDF2… are used for a password, we can call them password hash (for password storage) or password-based key derivation function (for use in encryption).

But that might not be understood when the context involves no passwords. Purposely-slowed hash is more descriptive, but awkward, and I have seldom seen it.

Are there established alternatives? If not, what do you propose?

Addition: I wish the term would be usable for strengthening the $b$-bit hash of a $3b$-bit Schnorr signature against brute force preimage attack. In this usage, there's nothing secret involved.

¹ As rightly pointed in comment, bcrypt can only produce 192 bits of output, which makes is passable for password hashing or short keys, but not a general Key Derivation Function.

fgrieu
  • 140,762
  • 12
  • 307
  • 587
  • 1
    Have come across *inherently-sequential hash function" being used (e.g., here), not sure it's in exactly the same context though. – ckamath May 23 '20 at 15:10
  • I was going to say "iterated hash function" if it wasn't already about hash function construction. Even then, not all password hashes are strictly iterative. Out of curiosity, what applications do you have in mind other than password hashing? – Marc May 23 '20 at 16:09
  • 3
    Memory-hard function? At least that is the explicit design goal of argon, scrypt (I'm not so familiar with the others). – Mikero May 23 '20 at 20:08
  • 1
    It's important to note that bcrypt is not a key-derivation function. It cannot generate a key of arbitrary length (e.g. 256 bits). bcrypt is a password hashing function; its "stretched" output is always 24-bytes (i.e. 192-bits). That is because its output is the result of encrypting 64 times the text OrpheanBeholderScryDoubt. That text is 24-chacacters (192-bits) long, so that's what you get: 192-bits. The others are "key-derivation" functions that get repurposed as a password-hashing algorithm. – Ian Boyd Jun 01 '20 at 13:20
  • @Mikero: I like "Memory-hard function", or "Memory-Hard hash", but the one issue is that it does not work when one wants to include PBKDF2 and the like. OTOH there is seldom a reason to consider PBKDF2 nowadays... – fgrieu Jun 01 '20 at 15:00
  • A term often used to describe the intended slowness of key-derivation or password-hashing function is "work factor". This does not designate the function itself, though, only its property. – Erwan Legrand Jun 04 '20 at 18:26

2 Answers2

3

1) I don't know any established alternatives.

2) It is not correct to say that such algorithms are purposely-slowed. They not only can be slowed, but also can use much memory. A single word for this would be resources. And I would stress even not resources, but rather the price, because the whole idea is to make the price prohibiting for attackers. I would suggest following terms:

  • Expensive hashing
  • Resource intensive
  • Resource demanding
  • Resource hard
  • Resource greedy
  • Resource hungry

I will put these terms each as a separate comment below my answer. Feel free to vote :) In a couple of weeks we'll see the result.

mentallurg
  • 2,611
  • 1
  • 16
  • 22
2

The term you're looking for may be key stretching. It refers specifically to the use of a deliberately slow component (typically a KDF) to increase the resistance of a cryptosystem to brute force key enumeration when the key material (such as a user-supplied password) may have only a limited amount of entropy.

The term comes from the fact that a key-stretching KDF can be thought of as taking a short (or just low-entropy) input key and "stretching" it into a longer key that behaves, in terms of its resistance to brute force attacks, as if it had more entropy than the original input key.

(Of course, the actual entropy of the key doesn't increase, but the slowness of the KDF slows down brute force guessing attacks just like additional entropy would. In effect, an attacker has two choices when trying to guess a stretched key: they can either try to guess the input key, which forces them to compute the slow KDF for each guess, or they can try to directly guess the output key, which is pseudorandomly chosen from a large key space.)

Ilmari Karonen
  • 46,120
  • 5
  • 105
  • 181
  • 1
    Thanks for the suggestion. I have now added a use case "strengthening the $b$-bit hash of a $3b$-bit Schnorr signature against brute force preimage attack". In this usage the hash does not manipulate anything secret, making me somewhat reluctant to "key". – fgrieu May 25 '20 at 20:38
  • The OP says But that might not be understood when the context involves no passwords. In the context without passwords the word stretching means merely increasing the size. Where as the real goal is making it difficult for an attacker to produce a big number of such hashes in a short time. If you have a key of 10-12 bytes and hash it with SHA-512, you get a hash of 64 bytes. Thus we can say it was stretched. But SHA-512 is designed to be as fast as possible. Thus this would be not a good choice for protection against brute-forcing. That's why stretsching is a misleading word for OP. – mentallurg May 25 '20 at 20:43