2
$\begingroup$

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 ?

$\endgroup$
  • $\begingroup$ As others have already pointed out, the abbreviation OTP is misleading, beause most of the time it means one-time pad and not one-time password. I suggest changing the title and pointing this out when using the abbreviation for the first time. $\endgroup$ – tylo Oct 6 '17 at 11:44
1
$\begingroup$

(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.

$\endgroup$
  • $\begingroup$ what about TOTP specifically ? See my comment to @gusto2's answer. $\endgroup$ – Jake Oct 6 '17 at 11:26
1
$\begingroup$

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)

$\endgroup$
  • $\begingroup$ what if the receiving end point keeps a record of whether a time slot has been used ? that way if replay is done within the time slot, the receiving end point will know. $\endgroup$ – Jake Oct 6 '17 at 11:20
  • $\begingroup$ @Jake are you assuming only a single message for a timeslot? $\endgroup$ – gusto2 Oct 6 '17 at 11:41
  • $\begingroup$ Let's see .. if two messages are sent within the same slot .. TC would be same .. but TOTP will be different if messages are different .. that's a good point .. if I have to send two same messages within the same time slot then it would be an issue $\endgroup$ – Jake Oct 6 '17 at 11:46
  • $\begingroup$ What if I did the following: when calculating TOTP, I append another value (0-50) to TC .. in a way meaning there can be 50 messages within the same time slot. $\endgroup$ – Jake Oct 6 '17 at 12:02
  • $\begingroup$ In your answer, you mention: "you'd need to have kind of counter or cache/validate the nonces (message id) during the validity period" .. can you please elaborate on that ? I didn't completely follow .. are you trying to add counter to the TOTP nonce ? $\endgroup$ – Jake Oct 6 '17 at 12:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.