[PATCH] Re: bad encrypted session key (bug report?)

[Remi Guyomarch]

On Fri, Apr 16, 1999 at 12:58:50AM +0200, Remi Guyomarch wrote:
> On Thu, Apr 15, 1999 at 03:23:43AM -0500, Mike Ashley wrote:
> > Hi,
> > 
> > I have a keypair generated using GPG but am having trouble communicating
> > with a PGP 6.0 user.  I'm able to duplicate the problem at will.
> > 
> > Assuming I am Bob and am communicating with Alice, here is the scenario.
> > I encrypt a message to Alice and myself.  While I can decrypt the result,
> > Alice cannot.  The error she gets from PGP 6.0 is "encrypted session
> > key is bad".

Mike, I think you can solve the problem by adding "--cipher-algo 3DES" 
or "--cipher-algo CAST5" to the gpg command line when you encrypt
something with Alice's key.

> I'm confirming. This behaviour depends on arguments order :
> 
> Example :

Err, in my example Alice hasn't any preferences at all in her
pubkey. Bob has BLOWDISH + CAST5, so the table becomes :

> 	user    cipher pref       key generator
>         ------------------------------------
> 	Alice   (none)            PGP 6.x (?)
> 	Bob     Blowfish, Cast5   GnuPG

From select_algo_from_prefs() in g10/pkclist.c :

	if( preftype == PREFTYPE_SYM )
	    mask[0] |= (1<<2); /* 3DES is implicitly there */

This ensure that a common symmetric algo will be found with any set of 
keys. Later the code selects the fist algo which is in both the
intersection of prefs and in the prefs of the last key (ie it favors
the last key).
But there is a bug in this code. Here's a patch :

diff -u -r1.48 pkclist.c
--- pkclist.c   1999/03/17 12:13:03     1.48
+++ pkclist.c   1999/04/16 05:14:31
@@ -756,9 +790,9 @@
     if( pref ) {
        for(j=0; j+1 < npref; j+=2 ) {
            if( pref[j] == preftype ) {
-               any = 1;
                if( (bits[pref[j+1]/32] & (1<<(pref[j+1]%32))) ) {
                    if( algo_available( preftype, pref[j+1] ) ) {
+                       any = 1;
                        i = pref[j+1];
                        break;
		    }
		}
	    }
	}
    }
    if( !pref || !any ) {
	for(j=0; j < 256; j++ )
	    if( (bits[j/32] & (1<<(j%32))) ) {
...

If the last key has no prefs, then the code will later select the
first algo which is in the intersection of all prefs.


In my example, the intersection of Bob's and Alice's prefs is
3DES (since 3DES is added implicitly). But 3DES is not in Bob's
prefs, and Alice has no prefs at all.

If the last key is Alice's one, the code will skip the first loop
because ALice key has no prefs and will select 3DES in the second
loop.
Without this patch, if the last key is Bob's one, the second loop
will be skipped. The caller then will receive -1 and will select the
(compile time) default symmetric algo - Blowfish currently.

-- 
Rémi        <rguyom at mail.dotcom.fr> | Don't waste your computer's time :
    PGP-encrypt anything important: | http://www.distributed.net/
   www.gnupg.org - KeyID:0x85BD8B1B | http://www.distributed.net/source/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 240 bytes
Desc: not available
Url : /pipermail/attachments/19990416/9523c652/attachment.bin