3

I'm developing own protocol for secure message exchanging. Each message contains the following fields: HMAC, time, salt, and message itself. HMAC is computed over all other fields using known secret key.

Protocol should protect against reply attack. On large time interval "time" record protects against replay attack (both sides should have synchronized clocks). But for protection against replay attack on short time intervals (clocks are not too accurate) I'm planning replace "salt" field with counter increasing every time, when new message is send. Receiving party will throw away messages with counter value less or equal to the previous message counter.

What I'm doing wrong?

Initial counter value can be different (I can use party identifier as initial value), but it will be known to the attacker (party identifier transmitted in unencrypted form). (What is a good enough salt for a SaltedHash?)

But attacker can precompute rainbow tables for counter+1, counter+2, counter+3... if I will not use really random salt?

Community
  • 1
Kirill Frolov
  • 131
  • 1
  • Any globally unique value is fine as salt. A site specific constant combined with a counter is one way to get a unique value. This kind of salt and rainbow tables are only relevant to password hashing, but your post doesn't talk about passwords at all. – CodesInChaos Nov 27 '13 at 14:26
  • I can't use SSL because protocol is designed for embedded application (using PIC microcontroller) with very constrained resources. For now I have Diffie-Hellman protocol (with reduced "key size" due to very slow computations) and HMAC-MD5 algorithms -- the maximum that I can afford. Protocol is not for password hashing -- it is implementation of HMAC-based One-time Password Algorithm (http://en.wikipedia.org/wiki/HMAC-based_One-time_Password_Algorithm). – Kirill Frolov Nov 27 '13 at 14:26
  • @fk0 Normal DH only approaches security with 1024 bit keys. Elliptic curves achieve a similar security level with 160 bits and are significantly faster. HMAC-MD5 is still secure (but generally discouraged). – CodesInChaos Nov 27 '13 at 14:29
  • If resources are constrained it may be advisable to consider symmetric key encryption. – deed02392 Nov 27 '13 at 14:31
  • Duplicate of http://security.stackexchange.com/questions/8246/what-is-a-good-enough-salt-for-a-saltedhash – Gene Gotimer Nov 27 '13 at 14:46
  • Yes, you are doing stuff wrong. Stuff that you don' have the first guess about. See my duplicate answer, here: http://security.stackexchange.com/questions/45268/are-there-any-holes-in-this-security-design/45269#45269 . – atk Nov 27 '13 at 14:25
  • Don't [cross-post](http://stackoverflow.com/questions/20244452/using-counter-instead-of-salt-for-hashing) – CodesInChaos Nov 28 '13 at 08:35

1 Answers1

3

The main problem is that salts should preferably be globally unique to avoid existing rainbow tables. If you choose to use hash 1,2,3,4,5,etc, there may exist a rainbow table for them already. It's slightly less risky if you do it as increments from some random number that makes it unlikely to have an attack, however there isn't really any good reason to do this. It is far better to use a random value for each. It's not that much extra data to store.

As far as how it applies to your situation, it sounds like you are trying to exchange messages. Hashes are not used for exchanging messages since they are one way. They are only used to tell if someone else had the same value without storing the actual value. A salt is generally only needed for passwords, not for message signing, so I'm not sure that salts and hashes even apply to what you are trying to do as it is described.

AJ Henderson
  • 41,816
  • 5
  • 63
  • 110