How to take SHA-1 safely for my particular case?

Let me ask about my toy passwords generator program X5 which I want to improve. X5 uses a secret key and a public key to generate a password.Where any public key is supposed to be known to hackers in the worst case.

pwd = sK + pk


To describe details, let me define some expressions.

1. each of K and k denotes a seed key but k corresponds to just one password generation, whereas you use K for all password generations;
2. K(n) means a seed key of n length;
3. pwd(n) means a password of n length;
4. sha1( s, n ) returns the first n characters of sha1(s), where sha1 means recursively applying sha1 algorithm on the input string for a constant many many times.

Using the new expressions, my algorithm can be written as follows.

pwd(n) = sha1(
sha1( sK(5) + pK(3 or longer) , 5 )
, n);


I want to X5 prepares for the following context of a user .

1. The algorithm of X5 is in public.
2. HackerA knows just one generated password pwd_X ;
3. HackerA knows all public keys, of past and of future .
4. HackerA even knows that pK_X was used to generate pwd_X.
5. HackerA tests all possible patterns to know sK.
6. HackerA knows all pairs of account names and servers.
7. HackerA tests all passwords possibly generated by X5 against all servers.

Let me ask , if the following algorithm differs much than the previous one.

pwd(n) = sha1(
sha1( sK(5) + sha1( pK(3 or longer) ,3 ) , 5 )
, n);


And which one is more secure?

-

migrated from math.stackexchange.comMar 6 '12 at 0:03

This question came from our site for people studying math at any level and professionals in related fields.

It's laudable that you want to get the crypto right. However, keep in mind that other attacks are much more likely than the kind you're imagining. E.g., it's extremely common that companies' databases of users get leaked to black-hat hackers, and the companies don't even disclose that. This happened to me with Ameritrade, for example. –  Ben Crowell Mar 5 '12 at 21:52

The main difference between your two algorithms is that the second one takes longer because of your additional hashing of the "public key". Also, by the truncation of this hash to 3 characters (are this bytes, hex digits, base64 digits?) could lead to collisions of different public keys to the same hash, which is much more unlikely to occur if you use the full hash.

The same kind of collision is possible after your "main" hash, don't do any truncation before the final one, please.

The general problem with such password hashing schemes is that, given the output and the "public key" (this is usually called "salt"), it is possible to brute-force the "secret key", if there are not many possible values for it. A five-character password is not enough by any measure.

But even with a "good" password, good practice is to not use a fast hash function like SHA-1 (or some small number of iterations of it), but a slow one. (Using some repetitions is a good start, but you normally want to input the secret again in each iteration, to avoid collisions of different secrets.)

Have a look at What makes a hash function good for password hashing? for details and some example functions.

-