Re: Key exchange

jt64@xxxxxxxx wrote:

What i actually meant by autokeying was surely/probably not "correct"
in the orgininal sense of the word when used in cryptografi.

I meant is there any ciphers out there that use an oneway
algorithm/function that works upon pseudokeys-> that are generated from
the "original password".
And then downmix this generated states of pseudokeys, to a "session?"
key


Why would you want to? I can't see what you are getting at.



Generating keys from a passphrase is common practice. This means you enter a
passphrase or password and a key is generated from that. The key is always
the same if the password is the same. I'll call this the master key for the
rest of this email, but it isn't usually called that.



Sometimes a oneway function, usually a simple hash, is used as follows:
generate a random number the same length as the key and share it with anyone
who needs to encrypt/decrypt, then XOR it with the master key. Use the XOR
as the session key, and store a hash of it in place of the random number,
deleting the random number.

This is sometimes used to provide a kind of forward secrecy (if the session
key generation process is truly one-way then you can't recover old session
keys even if tortured. The use of a stored random number and hash means that
you still need the passphrase as well as the stored secret to be able to
encryt/decrypt, but the other party can also generate a new key as
appropriate).



There is also a method of doing much the same thing based on discrete logs
problem or rsa or something which has a proof of onewayness (can't remember
details, it's in AC2 near the Blum Blum Shub reference iirc and works much
the same way, you do something like square the password modulo some big
number and use the last 256 bits), but the proof isn't very useful either
and is likely to fall to quantum computers if they are developed. However as
the security of hashes is a bit rolematic these days ...


Again, there is a zero-knowledge version where Alice and Bob have different
stored secret values and passphrases, but end up with the same session key.
Alice can't find out Bob's passphrase or the master key it generates, and
vice versa, even if she has access to Bob's stored secret data. That way Bob
can use the same passphrase and derived master key for different channels
even if he doesn't trust Alice. However this fails (partly, the FS property
doesn't fail) against a GAK demand for Bob's passphrase.



--
Peter Fairbrother

.