Mailing List Archive

Problem with GPG and remailers
I'm trying to send myself a message, via mixmaster (PGP encryption turned
on), through a few remailers.

The problem is that even though the remailer seems to use my
publicly-available key, I can't decode the encrypted message.

Specifically, "gpg --dump-packet --verb" says this on the secret message:

:pubkey enc packet: version 3, algo 16, keyid F3E85400D70AAFF9
data: [1020 bits]
data: [1023 bits]
gpg: public key is D70AAFF9
:encrypted data packet:
length: 83
gpg: encrypted with ELG-E key, ID D70AAFF9
gpg: no secret key for decryption available
gpg: decryption failed: secret key not available

... while my secret key ring has these:
secring.gpg
------------------------------
sec 1024D/D70AAFF9 1998-11-20 Matthias Urlichs <smurf@noris.de>
sig D70AAFF9 1998-11-20 Matthias Urlichs <smurf@noris.de>
ssb 1504g/CAA29391 1998-11-20
sig D70AAFF9 1998-11-20 Matthias Urlichs <smurf@noris.de>

Apparently, the remailer uses the key ID of the main signature in the
pubkey enc packet instead of the key ID of the subkey that it actually
used.

Is that analysis correct? Is there anything I can do to decode these
messages?

Cc to me please; I don't know yet if my subscription to gpg-users
succeeded.

--
Matthias Urlichs | noris network GmbH | smurf@noris.de | ICQ:
20193661
The quote was selected randomly. Really. |
http://smurf.noris.de/
--
Don't plan any hasty moves.
You'll be evicted soon anyway.
Re: Problem with GPG and remailers [ In reply to ]
On Tue, 1 Aug 2000, Matthias Urlichs wrote:

> Apparently, the remailer uses the key ID of the main signature in the
> pubkey enc packet instead of the key ID of the subkey that it actually
> used.

Right. GnuPG can't find the key because the key ID is the primary key
which is a sign-only key. There is no way to change this behaviour
becuase it is possible to use a encryption capable key for the primary
key but still use a subkey for encryption.

A workaround is to set the key ID in the received message to 0 which
will force gpg to try all available secret keys in turn. If you
invent a name for an override option I can easily implement this.

In g10/pubkey.c you see this:

int
get_session_key( PKT_pubkey_enc *k, DEK *dek )
{
[....]

if( k->keyid[0] || k->keyid[1] ) {
sk = m_alloc_clear( sizeof *sk );

if you make this part evaluate to false you are done.


Werner

--
Werner Koch GnuPG key: 621CC013
OpenIT GmbH http://www.OpenIT.de
Re: Problem with GPG and remailers [ In reply to ]
Hi,

Werner Koch:
> A workaround is to set the key ID in the received message to 0 which
> will force gpg to try all available secret keys in turn. If you
> invent a name for an override option I can easily implement this.
>
Hmm, how about --try-all-keys or --try-all-secrets or
--force-anon-recipient?

> if( k->keyid[0] || k->keyid[1] ) {
> sk = m_alloc_clear( sizeof *sk );
>
> if you make this part evaluate to false you are done.

Alternately, it might be feasible (but slightly more programming work)
to always check all subkeys if the key with the keyid is a primary key
with the wrong algorithm..?

--
Matthias Urlichs | noris network GmbH | smurf@noris.de | ICQ: 20193661
The quote was selected randomly. Really. | http://smurf.noris.de/
--
Polaroid does it in one step.
Re: Problem with GPG and remailers [ In reply to ]
On Tue, 1 Aug 2000, Matthias Urlichs wrote:

> Hmm, how about --try-all-keys or --try-all-secrets or

I'll take --try-all-secrets.

--
Werner Koch GnuPG key: 621CC013
OpenIT GmbH http://www.OpenIT.de