Mailing List Archive

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

> Paul Ashton <paul@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

Paul Ashton <paul@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

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

> That's good, but the thing that is often attacked is the PRNG. Getting

GNUPG does not use a PRNG but a cryptograhic strong RNG; if you have
the seed of a PRNG you access to all the "random bytes" it ever emits
from this seed - this is not true for a realy RNG which we (hopefully)
use in gnupg. (yes I know, that computers are deterministic systems
and so we can only code a PRNG but a lot of folks do think that the
physical world is also deterministic)

> A risk? I think so.

Yes. But "social engineering" is much more powerful, just ask your
friend you need his secret keyring to check that there are no "viruses"
in it and tell him this does not reveal the secret key because it is
encoded with a strong 128 bit state-of-the-art cipher which is keyed
with his passphrase, which you don't know. You make a copy and and
setup a dictionary attack on the passphrase - and assume this passphrase
is, as he didn't check the signature of the program, or what about a
trojan horse or, or ...

> someone is using, is legitimate or not. After I decrypt the message
> I compare the session key with MD5(message), or something.

And there are subliminal channels in the MD5 hash too :-)

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

Yep.

> True, but less bandwidth.

Doesn't matter as you have the secret key then and secret key are not
changed very often.

Hint: Use conventional encryption ("gpg -c") in cases were you know
your communication partner and you are able to do the key
distribution in a conventional way - it's much more secure than public key
encryption; but it is annoying.



Werner

Preview

wk@isil.d.shuttle.de said:
> Paul Ashton <paul@argo.demon.co.uk> writes:
> > That's good, but the thing that is often attacked is the PRNG. Getting

> GNUPG does not use a PRNG but a cryptograhic strong RNG; if you have
> the seed of a PRNG you access to all the "random bytes" it ever emits
> from this seed - this is not true for a realy RNG which we (hopefully)
> use in gnupg. (yes I know, that computers are deterministic systems
> and so we can only code a PRNG but a lot of folks do think that the
> physical world is also deterministic)

Ok, I'll rephrase my concern. One thing that is often attacked is
the RNG, perhaps due to misimplementation. With Linux it is entirely
conceivable that some kernel patch or other accidentally disables
/dev/randomness. I'm sure it won't last for very long though.

> > A risk? I think so.
>
> Yes. But "social engineering" is much more powerful, just ask your
> friend you need his secret keyring to check that there are no "viruses"
> in it and tell him this does not reveal the secret key because it is
> encoded with a strong 128 bit state-of-the-art cipher which is keyed
> with his passphrase, which you don't know. You make a copy and and
> setup a dictionary attack on the passphrase - and assume this passphrase
> is, as he didn't check the signature of the program, or what about a
> trojan horse or, or ...

The existence of one risk doesn't negate the existence of the other.

The essence of my argument is that anything that uses "random" numbers
cannot ever be validated, whereas if gnupg had a --deterministic
option that always produced the same output for the same input, then
merely a reimplementation to the same specification would be enough
to eliminate many possible concerns and weaknesses.

I understand that same output for same input is often not desirable
and many weaknesses are pointed out in Applied Cryptography and
others, but for some cases it may be sufficient.

I also think it is quite likely that encryption systems have
been developed with weak RNGs that have subject the system to
rapid attack. The nice thing for the NSA and co. who might pressure
people into doing this, is that they introduce plausible deniability
in case they are found out. "Sorry folks, we didn't realise
gettimeofday() wasn't such a good PRNG seed...".

Personally I wish that all my pgp, gpg and ssh keys purely used my
passphrase to generate the key-pairs and other systems
such as hash algorithms were used to generate session keys. If others
want to use /dev/random or whatever, then fine, we can still
communicate.

Cheers,
Paul

ps. May I thank you for your very fine work with GNUPG.