choosing an encryption target from a User ID

[Ingo Klöcker]

On Thursday 24 September 2009, Daniel Kahn Gillmor wrote:
> On 09/23/2009 06:04 PM, Ingo Klöcker wrote:
> > I'm pretty sure that this will break horribly as soon as the user
> > ID contains non-ASCII characters (as does my user ID). For exactly
> > this reason I made KMail use the key ID instead of the user ID
> > about 7 years ago.
>
> What makes you think that non-ASCII characters would break a match?
> Presumably, all the tools are passing UTF-8 strings to each other,
> and GPG can easily find a match based on such a string.

Does it also work with keys like 0xCB0D4CAF or 0xAB1BC4E6 created with 
PGP 6 (or earlier) where the user ID is not UTF-8 encoded? KMail 
applies some heuristics to guess the correct encoding if UTF-8 doesn't 
seem to work, but even if KMail guesses wrong and is not able to decode 
the user ID properly it's still possible to use such a key for 
encryption.

Moreover, user IDs are not unique while key IDs (usually) are. So if you 
want to be sure that the correct key is used you cannot use the user 
ID.


> For example, it certainly works fine from the shell:
>
> 0 dkg at pip:~$ echo test | \
>
> > gpg --encrypt --trust-model always -r 'Ingo Klöcker' | \
> > gpg --list-packets
> >
> :pubkey enc packet: version 3, algo 16, keyid 30CFDDC732319538
>
> 	data: [2047 bits]
> 	data: [2048 bits]
>
> :encrypted data packet:
>
> 	length: 64
> 	mdc_method: 2
> gpg: encrypted with 2048-bit ELG-E key, ID 32319538, created
> 2000-10-16 "Ingo Klöcker <kloecker at kde.org>"
> gpg: decryption failed: secret key not available
> 2 dkg at pip:~$

Good to see that it works nowadays for UTF-8 encoded user IDs on systems 
using a UTF-8 locale.


> > Is enigmail really still using the user ID?
>
> I haven't dug into it deeply, but what i observed from my tests was
> that if i switched the order of keys in my gpg keyring, enigmail
> selected a different key for a recipient who had two keys with
> matching User IDs.
>
> So i suspect that Enigmail is indeed passing the e-mail address at
> least (if not the name) to gpg to select a reasonable key for
> encryption.

Yeah, not very clever if you ask me. But, of course, I'm biased. :-)


Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20090924/d8352672/attachment.pgp>