1-way hash

[ChipAuger]

Hello Group,

Thank you in advance to the group for all responses and help. I'm
looking for a 1-way hash for storing passwords on an older embedded
system that would be computationally stressed using SHA1. Does anyone
have any suggestions?

Thanks again,
Chip Auger

[red floyd]

ChipAuger wrote:

Hello Group,

Thank you in advance to the group for all responses and help. I'm
looking for a 1-way hash for storing passwords on an older embedded
system that would be computationally stressed using SHA1. Does anyone
have any suggestions?

Try comp.algorithms or sci.crypt

[Brian Szmyd]

On Tue, 23 Oct 2007 16:41:27 +0000, ChipAuger wrote:

Hello Group,

Thank you in advance to the group for all responses and help. I'm
looking for a 1-way hash for storing passwords on an older embedded
system that would be computationally stressed using SHA1. Does anyone
have any suggestions?

Thanks again,
Chip Auger

All hashes are one way by definition. If they weren't then there would be
no computational advantage to using them as an index into a collection
class for random access.

Might I suggest MD5 which has about half the computational cost of SHA-1.

[James Kanze]

On Oct 24, 7:11 am, Brian Szmyd <[e-mail]:

On Tue, 23 Oct 2007 16:41:27 +0000, ChipAuger wrote:

Thank you in advance to the group for all responses and help. I'm
looking for a 1-way hash for storing passwords on an older embedded
system that would be computationally stressed using SHA1. Does anyone
have any suggestions?

All hashes are one way by definition. If they weren't then
there would be no computational advantage to using them as an
index into a collection class for random access.

Hashes are normally one way in the sense that they loose
information: you convert a string of arbitrary length (8*n bits)
to an unsigned integral type (32 or 64 bits). It's impossible
to reliably recover the original string.

What he's really asking for is a cryptographically secure hash;
one in which, given a hashed value, it is computationally
difficult to generate a string which would generate the same
hash value---whether it is the original string or not.

(For example, java.lang.String or g++'s hashing for a string in
their hashmap use the formula h[i] = 31*h[i-1] + c[i], h[0]=0,
which is adequat for most hash table use. But given a hashed
value, it is relatively trivial to apply the formula in reverse,
and generate a string which will have that hash value; it's also
relatively simple to generate arbitrary strings with the
targetted hash value. In sum, it isn't cryptographically
secure.)

Might I suggest MD5 which has about half the computational cost of SHA-1.

And is less cryptographically secure.

I'm not sure I really understand his problem, either. One of
the requirements for a password hash is that it require
significant time to compute, so that a brute force approach
isn't feasable. In this case, faster is worse.

In addition to MD5 and the SHA family, of course, most Unix
implementations use a modified DES; for both Linux and OpenBSD,
the sources are available, and I think you can even use the
OpenBSD sources in your own application without risk of
"infection". I doubt that the algorithm is as secure as SHA-1,
however.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[James Kanze]

On Oct 24, 7:11 am, Brian Szmyd <[e-mail]:

On Tue, 23 Oct 2007 16:41:27 +0000, ChipAuger wrote:

Thank you in advance to the group for all responses and help. I'm
looking for a 1-way hash for storing passwords on an older embedded
system that would be computationally stressed using SHA1. Does anyone
have any suggestions?

All hashes are one way by definition. If they weren't then
there would be no computational advantage to using them as an
index into a collection class for random access.

Hashes are normally one way in the sense that they loose
information: you convert a string of arbitrary length (8*n bits)
to an unsigned integral type (32 or 64 bits). It's impossible
to reliably recover the original string.

What he's really asking for is a cryptographically secure hash;
one in which, given a hashed value, it is computationally
difficult to generate a string which would generate the same
hash value---whether it is the original string or not.

(For example, java.lang.String or g++'s hashing for a string in
their hashmap use the formula h[i] = 31*h[i-1] + c[i], h[0]=0,
which is adequat for most hash table use. But given a hashed
value, it is relatively trivial to apply the formula in reverse,
and generate a string which will have that hash value; it's also
relatively simple to generate arbitrary strings with the
targetted hash value. In sum, it isn't cryptographically
secure.)

Might I suggest MD5 which has about half the computational cost of SHA-1.

And is less cryptographically secure.

I'm not sure I really understand his problem, either. One of
the requirements for a password hash is that it require
significant time to compute, so that a brute force approach
isn't feasable. In this case, faster is worse.

In addition to MD5 and the SHA family, of course, most Unix
implementations use a modified DES; for both Linux and OpenBSD,
the sources are available, and I think you can even use the
OpenBSD sources in your own application without risk of
"infection". I doubt that the algorithm is as secure as SHA-1,
however.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]