# HMAC-SHA1-128 parameters

I have a question regarding what parameters should be used when generating HMAC-SHA1-128. I have fairly limited knowledge in this field.

HMAC parameters:

H = Hash = SHA1

K = Key size = 128 bits (16 bytes)

B = Data block byte length = 64 bytes

L = Output size of SHA-1 Hash = 160 bits (20 bytes)

Charset = UTF-8

Does this make sense? Anything else I should consider? I want to make it similar to the following RSA example:

Format = x.509

Charset = UTF-8

Encoding = Base-64

Endianness = Little Endian

Key size = 2048 bits

Is encoding, endianness or anything else other than the things I mentioned under HMAC parameters relevant and should be paid specific attention to?

Thank you!

Edit since last comment:

Regarding the data;

I would like to take data from 4 different columns in a database table and create a HMAC based on those - one HMAC for each row in the database table.

The data are the following:

Date(YYYY-MM-DD), Time (hh:mm:ss), String(xxxxx), Number (1000.00).

The data shall be separated by semicolon - so the full string will for example be: 2000-01-31;23:59:59;"hello";1000.00

There's not a word about the data to authenticate! Update: we are told that's data from a row in database with 4 different columns: Date(YYYY-MM-DD), Time (hh:mm:ss), String(xxxxx), Number (1000.00). It is of paramount importance to specify how this data is transformed into byte before entering HMAC. Concatenation would be dangerous for the last two fields, because in digitsfollow12 34.56 and digitsfollow123 4.56 would give the same MAC.

The hash you want to specify is usually designated SHA-1, not SHA1.

SHA-1 is obsolete, even though when combined with HMAC it remains safe and thus tolerated. A modern replacement would be SHA-256 or SHA-512, followed by truncation of the final HMAC result if a 160-bit output is desired.

The data block size B is redundant with specifying SHA-1, and will need to be kept in sync with the hash. I would suppress that.

Ipad and Opad, and their repetition count, are redundant with the specification of HMAC. I would suppress that.

"Charset = UTF-8" does not make sense to me, unless you want some encoding (like Base-64), or it applies to the data to authenticate, in which case that should be told.

It is not specified how various parameters are passed: array of chars, string, and nature of that; and if the length (e.g. of data to authenticate) is separate or some attribute of an object, and in what unit (bytes, bits), and the maximum. It is not told wether data to authenticate is passed in one block or iteratively.

Giving an example in a spec helps immensely.

• Thank you for your answer. Regarding the data, I apologize for not mentioning anything about that. I would like to take data from 4 different columns in a database table and create a HMAC based on those - one for each row in the database table. The data are the following: Date(YYYY-MM-DD), Time (hh:mm:ss), String(xxxxx), Number (1000.00). Does this help?
– Dino
Sep 15 '16 at 15:52
• Extremely late comment: For the string and number you'd need to explicitly specify the encoding. For instance, a number could be a 64 bit double floating point, or a big endian integer. Best to give your spec to multiple people and have it reviewed. Even better is a Proof-of-Concept or PoC. This is not that hard to implement, and you may find things during implementation that you might overlook otherwise. Keep an open mind while creating the PoC, and you can be almost sure to find something. Oct 15 '16 at 18:29
• Oh, and you must make sure that you can distinguish between the string and the number at the end (if your string ends with a number you may have multiple datasets generate the same HMAC value). Nov 14 '16 at 18:49