HMACSHA1.ComputeHash() thread-safety question

views:

461

answers:

HMACSHA1.ComputeHash() thread-safety question

hello,

i am asking myself if it would be dangerous on a asp.net page´s codebehind to use an static (Shared) variable which holds an HMACSHA1-instance. the problem is that the same HMACSHA1-instance would be used by all the asp.net worker-process´ threads when processing multiple simultaneous requests on the same asp.net-page. all (HMACSHA1)instance- and ComputeHash()-method variables which are used/modified by ComputeHash() would be shared (= could be modified) by all the threads?! is that assumption correct? as a result the return value of ComputeHash would not be guaranteed to be correct?!?! thus i am not allowed to use an static/Shared HMACSHA1-instance over all the asp.net-threads..

i am just wondering what you think about this problem.

the only solution to this would be sth like an critical path etc in the ComputeHash()-method. but that is "out of our reach"..

regards, kris

+1 A:

Hashing algorithms are deterministic, they must return the same hash for a given input every time.

As long as you use the same key each time then there's no need to make them static. However if you're constructing the HMACSHA1 instance with the parameterless constructor then it generates a random key. You should be taking the random value from the KeyValue property and storing it with the hash.

It is definitely dangerous to use a static instance. If Thread1 sets the value to be calculated, and then Thread2 sets the value before Thread1 calls ComputerHash() then Thread1 is going to get the hash of Thread2's value. The same will happen if either thread is setting the key.

blowdart 2009-02-20 14:22:02

Hashing algorithms indeed have to be deterministic.. but problem is multithreading :)How do you mean: "..no need to make them static"?The key is remaining the same all the thime and will be periodically (monthly) changed.I am creating the instance like this:HMAC hmac = HMAC.Create("HMACSHA1");

2009-02-20 14:42:27

The reason why i would make the HMAC-variable static to the asp.net-codebehind-class is performance.. but, otherwise, ComputeHash() should have nearly about 100% of it´s content in between an critical section to guarantee thread-safety..

2009-02-20 14:44:44

..so my idea to hold the hmac instance as static would be good to save memory maybe, but each page-request would take longer than with non-static hmac-Instances, because of the locking-mechanism.

2009-02-20 14:47:09

Well, benchmark it, but my guess is that in a typical ASP.NET page request, the overhead of one more CSP operation might not be too important.

MichaelGG 2009-02-20 15:18:46

It sounds like premature optimisation here to me, and the lock issues would mean if your machine is heavily hit every page requesting an HMAC is going to be waiting. Horrible!

blowdart 2009-02-20 15:49:35

Thank you guys for the conversation on this.. i think, it is worth every consideration when it´s about optimisation and it´s also good to understand .NET a little better :)Locking would not be good.. thats right. Like MichaelGG said, only benchmarking would let us know more. Keep your good work!

2009-02-20 16:57:49

Now i´m asking myself, if all the static methods, which are qualified as thread-safe by the MSDN have critical sections implemented? Because, static lonely doesn´t guarantee this. What do you think? Or, did anyone a research on this?

2009-02-23 17:22:40

MSDN often documents methods with "this method is/isnot thread safe." In some cases, eg collections, the doc is considerably more detailed as it describes what operations can be done concurrently.

Cheeso 2009-07-27 03:10:10

ansaurus

tags:

views:

answers:

HMACSHA1.ComputeHash() thread-safety question

related questions