Deterministic session keys

[Paul Ashton]

wk at isil.d.shuttle.de said:
[ great. discussion!]

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

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

That's good, but the thing that is often attacked is the PRNG. Getting
rid of randomness removes this large mechanism of attack, plus removes
a mechanism to leak keys, including the private key.

> > 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.

My argument is that people don't take a lot of care in selecting
their encryption program, or certainly not as much as we'd like.
Just suppose I give GPG to a friend of mine, tell him it's the
best thing since sliced bread, and he can keep his PGP keys. However,
I've modified his GPG to leak his private key to me, slowly,
as a function of the session key. We communicate for a few
messages and then finally I have his full private key.

If he communicates with other people as well as me, they don't
see any problem, he looks over the source and doesn't see the
subtle interaction between the session key and his private key
and is none the better off.

A risk? I think so.

With a deterministic session key, I can tell whether the program
someone is using, is legitimate or not. After I decrypt the message
I compare the session key with MD5(message), or something.

> > 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. 

I'm not talking about leaking the session key, I mean the private key.

> > 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. 

Absolutely, my proposal is very naive and would require a lot of
thought.

> > 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.

True, but less bandwidth.

Cheers,
Paul