Deterministic session keys

[Werner Koch]

Paul Ashton <paul at argo.demon.co.uk> writes:

> One way to validate another program is to write a second implementation

If a lot of people are going to review the source you can be quite
sure that there are no heavy nugs in it. 

> and compare the functionality. The problem with random session keys is
> that the use of the second program cannot determine whether the first
> did or didn't produce a bad or malicious session key. I'm sure the

This is not an issue, as it is unlikely that a user who encrypts some data 
uses a bad system for it on purpose.

> first thing that people do when they want to covertly leak the key
> in an encryption program is to tamper with the session key.

The session key is much stronger than the public key used to encrypt
the session key.  It is better to attak the public keys as you than
have the opportunity to decrypt _all_ messages.  The requirement for
the public key parameters are much more complicated tha those of a
cipher algorithm. 

> It would be nice if this could be done whilst remaining compatible
> with non-deterministic (not sure that's the right term) programs.
> So with PGP you change make_random_ideakey() to be produce an IDEA
> key that is MD5(file), say.

You don't know the interdependencies between a key generated from the
plaintext (in some way) and the ciphertext - It is not known and so it
is not a good idea to rely on such a non-reviewed mechanism. 

> There are disadvantages that need to be overcome, but I would
> like to hear peoples comments.

I do not think that there are any advantages; if I'm malicious I yould
use other mechanisms to leak out secret data - sublimal channles of
ahsh algorithms are perfect way to do this ; but because we have the
source this is not an issue.


Werner