Does displaying HMAC hashes of user inputs compromise the HMAC validation?

Question

Here is the scenario:

• "SECRET" is a secret key that is kept private and only used in this one application.
• The application allows users to enter in any "VALUE" (within various open-ended limits such as numeric > 50, max length 20, etc... depending on the field)
• The application creates an HMAC-SHA2-256 "HASH" from VALUE and its field name using SECRET as the key
• HASH is displayed to the user

"CONTROL" (comparison) scenario:

• Only a certain number of field VALUEs and their corresponding HASHes are shown to users
• Users cannot input additional VALUEs to see the corresponding HASHes

Other information:

• The HASHes are used to prevent the VALUEs from being changed while being sent to a third party application.
• If a user tries a HASH with a corresponding field name and VALUE, either it works or an error message comes up.
• There are no limits or precautions against automated testing other than network speed.

Real-life application (not necessary for the question):

• The hashes are used as an easy (==low cost) alternative to IPN validation for products sent to FoxyCart, a Javascript-powered secure checkout.
• The hashes prevent a user from spoofing exact values but cannot handle complex conditions such as minimum and maximum values of a user-chosen option. For such situations, FoxyCart provides a special hash value that disables validation of that field.
• The easy solution would be to validate the user input on the server and hash it before forwarding it to FoxyCart.

Questions:

• Does allowing users to test VALUEs increase the likelihood that SECRET will be broken or illegal hashed values generated, relative to the CONTROL scenario?
• By how much?
• How is this calculated or proved?

Answer 1

Does allowing users to test VALUEs increase the likelihood that SECRET will be broken or illegal hashed values generated, relative to the CONTROL scenario?

By definition a cryptographic Message Authentication Code such as HMAC is secure only if resists existential forgery under chosen-plaintext attacks. i.e. if allowing users to test VALUEs increases the likelihood of discovering the SECRET or generating illegal hashes, then HMAC would not be a secure MAC (and the current state of our knowledge is that it is strong when used with a half decent hash function).

In your particular usage though, unless the HASH value is tied to a particular cart/session it might be possible to replay HASH values obtained from previous interactions.

By how much? How is this calculated or proved?

The 2006 security proof for HMAC by Mihir Bellare provides a proof and tightness bounds on that proof, but for your purposes you could probably treat the difference as negligible.