Re: Key exchange

This maybe a bit silly question but could the hashes you refer to
actually rehash/morph the original password data more then once without
adding any new data.

The nice thing with using combined permutations as hashes to work on
password is that they have states, and the permutation states can be
rolled forward to make new permutation combinations.

Is this possible with a regular hash without bringing new entropy?

What i am looking for is a way to make keyexchange
superflous/unnecessary, by using combinations of permutations as a hash
algorithm with an evolution of a big internal state, that spit out keys
that are nonereversible.

Maybe this is common practice for some ciphers, maybe it lacks in
security, maybe it is just a bad idea to rekey often from a large
internal hidden state.

I can see how it is possible to actually roll forward the communication
if you have the Masterkey/Originalkey for the permutated and xored
pseudokeys that make up the session key, but if the communcation takes
place back and forth over months. The chance you actually have the
original key pretty slim and is not that easy to bruteforce 2^256
anyway

And the session key would be useless from cryptological view as soon
the combination of internal pseudokeys make a new sessionkey.

So is it possible as i propose to actually make the computation
overhead bigger generating the actual pseudo keys for an attacker that
it would be easier for him to attack each session key.

JT


John E. Hadstate skrev:

<jt64@xxxxxxxx> wrote in message
news:1153059497.796418.323890@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx


So my idea in short why not use a oneway hash algorithm
with a larger
internal state than the output of it to create new keys
based on a
function/hash that rehash the internal state.


This pretty well describes how most cryptographic hashes are
used to create keys. See your email for PDFs and diagrams
on how to use hash functions to generate cipher keys from
passwords.

Key search terms: "Password-Based Encryption" "PBE" "PKCS5
Version 2" "RFC 2898"

JT


.

Relevant Pages