1
votes

i have read this article in Codeproject:

Salted-Password-Hashing-Doing-it-Right.

and i understand that the best hash algorithm for asp.net webforms is PBKDF2-HMAC-SHA512. and then this github implementation:

My implementations of PBKDF2 in PHP, C#, Java, and Ruby.

it's based on PBKDF2-HMAC-SHA1.

i googled to find something that help me to make a hash based on PBKDF2-HMAC-SHA512.

and i've found this library on github:

therealmagicmike/PBKDF2.NET.

in this library i can define my hash algorithm like HMACSHA1, HMACSHA256, HMACSHA384 or HMACSHA512.

and as you know HMACSHA1 is faster than HMACSHA512. and it's not good in security reasons.

But i've found something that i don't know it's true or not! i've implemented both algorithms in same page and understand that adriancs's algorithm takes longer time than the mike's. and it's not logical as for adriancs's article.

So, i want to know which algorithm is slowest and also which is better?

any help will be appreciated.

Thanks a lot.

1
Is the work factor (iterations) the same? Comparing times from the same language? Different languages have different efficiencies.zaph
yes. both Iterations are the same. i tested both libraries with the same values: salt size 64. hash bytes 22. iterations 64000.user6311045
Diffgerent languages, what are they with test times?zaph
No, both are writed in C#. And something else, the fast one is using BufferCopy method. May it be the reason of time difference?!user6311045
In any event the concerpt is tp have a rounds value that takes about 100ms.zaph

1 Answers

1
votes

Sorry to find this so late. I'm the author of PBKDF2.NET. The speed difference is due to the equality comparison. The library by Defuse implements a slow-compare function, where I chose to leave any custom comparisons up to the consumer. My reasoning is that I didn't want to create a library with additional non-essential utility functions but rather to provide a proper implementation of the algorithm. Whether or not a particular application requires a slow compare really depends on the application so I excluded this.