Pseudorandom function library

Question

I'm wondering if there is any library supporting pseudo-random function, so I can specify the key length and output domain.

Is it correct that I need to use a block cipher for this purpose?

Any help with this would be much appreciated.

Answer 1

Quite a few message authentication codes are actually PRFs with arbitrary input domains. For example:

• HMAC, instantiated with a hash function satisfying the appropriate security properties (basically, for Merkle–Damgård hash functions like the SHA-2 family, that the internal compression function is itself a PRF), is provably a PRF.

• CMAC, instantiated with a secure block cipher (i.e. a PRP), is provably a PRF.

In both cases, the security proofs are conditional on certain assumptions about the underlying primitives (hash function / block cipher) that cannot themselves be proven (at least not for any practical crypto primitives currently in use) without further assumptions. Thus, the best we can do is choose a standard and well studied hash or cipher, like SHA-2 or AES, and hope that the fact that they've been studied by many skilled cryptanalysts, without any published successful attacks, is proof enough that they cannot be broken with current state of the art.

In general, these PRFs take an arbitrary string as an input, but produce a fixed-length bitstring as their output. If a longer output is desired, one simple way to extend it is to re-run the PRF on the same input, but with a different (ideally, independent) key. (There are other, potentially more efficient ways to extend the output length, but they require more involved security proofs; see e.g. Maurer & Sjödin (2007).)

As for the key length, this depends on the scheme in question; for example, the CMAC key size depends on the block cipher used, while HMAC technically accepts keys of any length, but keys longer than one hash input block are processed by hashing them first (which implies that the effective maximum key size, measured as resistance to brute force attacks, is limited by the hash block size).

Thus, the arbitrary key length of HMAC should be regarded as a convenience; it does not imply arbitrarily high cryptographic strength, but it does mean that, if you happen to have a long but low-entropy key, like a user-entered passphrase, you can feed it to HMAC without having to reduce it to a fixed length first. This is a convenient feature for key-derivation functions, many of which are based on (or commonly instantiated with) HMAC.

(As for increasing the key length in the hopes of increasing cryptographic strength, it's worth noting that a brute-force attack on a 256-bit key is far beyond any existing or conceivable computational power, even if quantum computing turns out to be practical. Thus, for all practical purposes, 256 key bits is more than long enough. Also, if you still, for some reason, want higher brute force attack resistance, you'll need to pay close attention to the actual security bounds claimed for the primitives you're using, and the tightness of the security proofs, since even attacks usually seen as being only of theoretical relevance may become practical for hypothetical attackers wielding such implausibly high levels of computing power.)