Re: Derivation of AES keys from Hash function

Hi Unruh, Joe and all contributers to my topic.
Thank you very much.
Your advice seems to fit in my solution. Now, would you please
recommend any known references(reports, RFCs, publications,e.t.c.),
where I could read more about the advice you(Joe) have given?
I will highly appreciate that.
Ngaga.

Unruh wrote:
"tum1995@xxxxxxxxx" <tum1995@xxxxxxxxx> writes:

I'm trying to use the hash function to derive AES symmetric keys, e.g.
keys of 128 bits length. These keys must be random/unpredictable as
required by the rules of cryptography.
That is, the user enters some value, and the same key is always
generated for a given input data.
I was going to use a One Way Hash (SHA-256) and AES-256 to ensure that
the input value always generates the same key length.

This is no stronger than the plaintext input of the user. Since the hash is
known all it does is transform one input into a cryptographically
equivalent input.


But I'm faced with the problem that can be encountered in paractical
situations. For example:
1) SHA-256 outputs a 256 bit digest, while my Symmetric Keys have to be
128 bits.
If I simply truncate the 256 bits to 128bits, will I run into lots of
collisions between different input values? Is there a better way to

The same number as if you had taken a 128 bit hash in the first place. Ie,
this is a perfectly acceptable but slow 128 bit hash.



reduce the SHA output to a 128 bits value that will not significantly
lower the entropy so that it is actually less than 128 bits? Are there

The entropy is not greater than the entropy in the input key anyway, which
is almost certainly less than 128 bits.

things I absolutely should not do? Is thjere a general scientific
approach where this problem has been addressed?
2) The hash function size is smaller than the AES size. (AES-192 and
SHA-1). Assume that the SHA-1 current security flaw has been solved,
then we have enhanced SHA-1.
Here, padding is not a solution because the output looses its
unpredictability property.

The output is just as unpredictable as the input already. Your users will
NOT input 128 or 256 bits of randomness.

Has this problem been addressed or solved in any known scentific work?

hash(key)+hash(hash(key)) ( where + is concatenation) as long as the input
randomness is less than the size of hash(key). If it is, then
hash(key1)+hash(key2) where key=key1+key2 ( again +is contatenation).
would be fine. The only purpose of doing the hash rather than using the key
directly is to make sure that the distribution of 1 and 0 in the final key
is about equal just in case the cypher has an unknown weakness if there are
more 0 than 1. Or in case the size of the input key is larger than the AES
key size (doubtful).

.

Relevant Pages

  • Re: Creative Live Pro webcam
    ... Hash: SHA1 ... Can anyone offer advice on what to do to get this camera working? ...
    (Ubuntu)
  • Re: Probability of hash collisions
    ... >> I'm asking for advice about using a hack which can easily be done ... >> with the LDAP implementation which we are using and will continue ... Hash functions rather than hash tables. ...
    (comp.programming)
  • Re: IIS Directory traversal vulnerability
    ... Hash: SHA1 ... thank you all for your advice. ... I have spent the last day or so pulling my system and it's logs apart, ...
    (Incidents)
  • Re: [SLE] cups - strange error message (SUSE 9.1)
    ... pelibali wrote: ... >Any advice please, what I'm missing, or what is wrong? ... making sure the hash is on the first line. ...
    (SuSE)
  • Re: SHA-1 and the "birthday paradox"
    ... risk of collision when using SHA-1 as a digest, or hash key, for ... identical SHA-1 digest referring to two distinct blocks rather than a ... If you find a collision on SHA-1 then you may publish it and become ... (Cost is here expressed in number of hash function computations which ...
    (comp.lang.forth)