Whatever parameters you pass in will affect the resulting hashes. If you compute only H(Firstname), then two users with the same first name will lead to the same hash even if they have different surnames.
P.S. Consider letting users simply have a name so that you respect the vast populations of people out there whose names do not conform to the anglophone ...
There are statistical patterns or distributions. Like gamma, beta, chi-square... etc. There is a software called Arena Input Analyzer which will show you how your data is distributed with a chi-square test and a histogram.
With that, I could randomly create data like the one you have. But the software is very expensive. I have the student version.
The concrete answer is B, as defined in RFC 2104
The authentication key K can be of any length up to B, the block
length of the hash function. (B=64 for all the above mentioned examples of hash functions)
It is difficult to determine what is meant by "the block length of the hash function", so let's go digging in another RFC for information!
From RFC ...
HMAC (and any other MAC) are totally different from Digital Signatures (RSA, DSA, ECDSA, EdDSA).
MACs require a shared secret key that both the communicating parties have. The same secret is used to create the MAC as is used to verify it. Anyone with the shared secret key can create a MAC, and anyone with the shared secret key can verify a MAC.
A simple algorithm for secure HMAC implementation
Generate random clientid, clientsecret (32-bytes), hmacKey (64-bytes)
Encrypt hmackey using AES256 with clientsecret as the key to get enc_hmacKey
Server stores clientid and enc_hmacKey
Client will be provided with clientid,clientsecret and hmacKey
HMAC will be computed ...