Hi, since MDC checks got introduced we encounter sporadic problems when encrypting mails to collegues with really really (~2001) old GPG keys that include UIDs that according to --edit-key -> showprefs are not MDC-enabled by default (too old hashes like CAST5).
The respective gpg key has multiple UID, some private email addresses and some addresses used within our company. The email addresses are often identical except for upper/lower cases. I guess the UIDs were created over the years because some names contain German umlauts, others do not (probably all Latin1, UTF-8 encoding history is in this key ;-)) As far as I understand gpg will an symmetric encryption suitable for all recipients looking at the public keys of all. For some reason when encrypting emails to multiple recipients (including this collegue) it sometimes (not always) happens that an non-MDC hash is used. Then non recipient, not even the sender, can read the mail with an MDC-hardend Thunderbird/Enigmail solution. I guess gpg randomly picks a UID that matches the email address and sometimes the old CAST5-style UID number (4) and everything breaks appart :-( When as a sender I delete UID (4) from my keyring the problem disappears. However I'm not sure, if that's safe to do for the private-key owner to do so and re-publish the key. Won't that break something for him? We also don't know why some UIDs have different algos. What solution is possible for this? * Is it possible to change the UIDs preferences somehow? Can one use setpref for that and republish? * shall we ask all senders to use --force-mdc in their gpg.conf? * should one set --cipher-algo aes256 (or any other using MDC by default?), but Enigmail FAQ says that's not a good idea... * can one safely delete an UID as private-key owner and republish? * will Enigmail instead of blocking non-MDC emails probably display a "are you sure warning?" dialog that one could skip? (because actually there are probably old non-MDC encrypted emails, that one could never read again with current Enigmail versions) Most ideas require action on the sender part just for having one recipient with an obstructing UID... Compare (UID 4 seems to be the one forcing all into non-MDC, when also on the mail recipient list): gpg> showpref [ unbekannt ] (1). NAME1 <[email protected]> Verschlü.: AES256, AES192, AES, CAST5, 3DES Digest: SHA1, SHA256, RIPEMD160 Komprimierung: ZLIB, BZIP2, ZIP, nicht komprimiert Eigenschaften: MDC, Keyserver no-modify [ unbekannt ] (2) NAME2 <[email protected]> Verschlü.: CAST5, 3DES, IDEA Digest: SHA1 Komprimierung: ZIP, nicht komprimiert [ unbekannt ] (3) NAME3 <[email protected]> Verschlü.: AES256, AES192, AES, CAST5, 3DES Digest: SHA1, SHA256, RIPEMD160 Komprimierung: ZLIB, BZIP2, ZIP, nicht komprimiert Eigenschaften: MDC, Keyserver no-modify [ unbekannt ] (4) NAME4 <[email protected]> Verschlü.: CAST5, 3DES, IDEA Digest: SHA1 Komprimierung: ZIP, nicht komprimiert [ unbekannt ] (5) NAME5 <[email protected]> Verschlü.: AES256, AES192, AES, CAST5, 3DES Digest: SHA1, SHA256, RIPEMD160 Komprimierung: ZLIB, BZIP2, ZIP, nicht komprimiert Eigenschaften: MDC, Keyserver no-modify [ unbekannt ] (6) NAME6 <[email protected]> Verschlü.: AES256, AES192, AES, CAST5, 3DES Digest: SHA1, SHA256, RIPEMD160 Komprimierung: ZLIB, BZIP2, ZIP, nicht komprimiert Eigenschaften: MDC, Keyserver no-modify Best regards, Michael -- TNG Technology Consulting GmbH, Betastr. 13a, 85774 Unterföhring Geschäftsführer: Henrik Klagges, Dr. Robert Dahlke, Gerhard Müller Sitz: Unterföhring * Amtsgericht München * HRB 135082 _______________________________________________ enigmail-users mailing list [email protected] To unsubscribe or make changes to your subscription click here: https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
