Can One-time-password be used as nonce in HMAC to prevent replay?

Question

Note: In the following post OTP = one-time-password

I am working on a project wherein I need send one way messages between two end points. There is already a shared secret via a side channel between the two end points. No user is not involved at either of the end points. Due to some constraints I don't have control whether or not encryption will be used when the message is actually send, so I have to assume the message is going over plain text. The reader can assume the messages as some sort of "action".

The packet carrying the message also contains HMAC of the message calculated using the shared key. I need to prevent replay attack. From wikipedia, I see the options being: OTP, nonce and time stamp.

I can only assume that the clocks between two end points are roughly synchronized (both end points have some reliable time source). I'm thinking of adding some kind of nonce when computing the HMAC. I want to ask whether the option I selected below would be correct for nonce. I want to use some standard technique. I do understand that nonce cannot be repeated.

My first question is that whether certain OTP values can be considered as nonce (the wikipedia categories make them appear distinct).

I found the TOTP algorithm which can calculate a one time password using a shared key and timestamp. I want to ask whether TOTP can be used as nonce.

TC = floor((unixtime(now) − unixtime(T0)) / TS),
TOTP = HOTP(SecretKey, TC),
TOTP-Value = TOTP mod 10d, where d is the desired number of digits of the one-time password.

TC will be stored in an unsigned 64 bit variable. Since HOTP is a hash function (assume SHA-256), TOTP won't repeat (until the unsigned 64 bit TC reaches its max value and wraps around). My second question is whether TOTP can be used as nonce when calculating HMAC ?

Answer 1

(Note: I think, In general OTP is usually understood as One-Time Pad. Here it means One-Time Password.)

Using an OTP as a nonce does not seem possible in general. An OTP doesn't necessarily always have to be distinct. Since there is some kind of synchronization between the communicating parties the OTP might repeat.

Specifically, say your OTP consists of randomish 64 bits. Then whenever you need a password it is fine if both parties derive 64 random bits independently of previous values.

If you need a nonce, however this gives you a decent collision probability after about a billion repetitions. (Due to the birthday bound.)

However, practically, most hash functions have good PRF properties and can be used to generate nonces.

Answer 2

I assume you mean using time-based OTP. At the end - the client and server need to have another (?) common shared secret to compute the OTP and the server needs to validate the OTP based on the time.

My first question is that whether certain OTP values can be considered as nonce

well - not really. The TOTP is not guaranteed to be unique and it is guaranteed to be the same during the timeslot.

My second question is whether TOTP can be used as nonce when calculating HMAC

as stated - it will be the same during the timeslot

Suggestions:

• You could just send a timestamp along the data (and include the timestamp in the the HMAC)

• How commonly are the replay attacks prevented - you'd need to have kind of counter or cache/validate the nonces (message id) during the validity period (regardless it's TOTP or timestamp with allowed skew time)