<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Jan 3, 2019 at 10:10 PM <<a href="mailto:gnupg-users-request@gnupg.org">gnupg-users-request@gnupg.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Send Gnupg-users mailing list submissions to<br>
<a href="mailto:gnupg-users@gnupg.org" target="_blank">gnupg-users@gnupg.org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="http://lists.gnupg.org/mailman/listinfo/gnupg-users" rel="noreferrer" target="_blank">http://lists.gnupg.org/mailman/listinfo/gnupg-users</a><br>
or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:gnupg-users-request@gnupg.org" target="_blank">gnupg-users-request@gnupg.org</a><br>
<br>
You can reach the person managing the list at<br>
<a href="mailto:gnupg-users-owner@gnupg.org" target="_blank">gnupg-users-owner@gnupg.org</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of Gnupg-users digest..."<br>
Today's Topics:<br>
<br>
1. Re: gpg - difference --encrypt-to and --recipient<br>
(justina colmena)<br>
2. Re: gpg - difference --encrypt-to and --recipient (Stefan Claas)<br>
3. Re: gpg - difference --encrypt-to and --recipient<br>
(<a href="mailto:vedaal@nym.hush.com" target="_blank">vedaal@nym.hush.com</a>)<br>
4. decryption failed: Bad session key (Frank Hrebabetzky)<br>
5. Re: gpg - difference --encrypt-to and --recipient (MFPA)<br>
<br><br><br>---------- Forwarded message ----------<br>From: justina colmena <<a href="mailto:justina@colmena.biz" target="_blank">justina@colmena.biz</a>><br>To: MFPA <<a href="mailto:2017-r3sgs86x8e-lists-groups@riseup.net" target="_blank">2017-r3sgs86x8e-lists-groups@riseup.net</a>>, justina colmena via Gnupg-users on GnuPG-Users <<a href="mailto:gnupg-users@gnupg.org" target="_blank">gnupg-users@gnupg.org</a>><br>Cc: justina colmena via Gnupg-users <<a href="mailto:gnupg-users@gnupg.org" target="_blank">gnupg-users@gnupg.org</a>><br>Bcc: <br>Date: Wed, 02 Jan 2019 11:56:27 -0900<br>Subject: Re: gpg - difference --encrypt-to and --recipient<br>On January 1, 2019 4:13:43 PM AKST, MFPA <<a href="mailto:2017-r3sgs86x8e-lists-groups@riseup.net" target="_blank">2017-r3sgs86x8e-lists-groups@riseup.net</a>> wrote:<br>
>Hi<br>
><br>
><br>
>On Monday 31 December 2018 at 9:06:39 PM, in<br>
><<a href="mailto:mid%3A6A39FC9C-3105-451B-BB5E-6D6757337600@colmena.biz" target="_blank">mid:6A39FC9C-3105-451B-BB5E-6D6757337600@colmena.biz</a>>, justina<br>
>colmena via Gnupg-users wrote:-<br>
><br>
><br>
>> Shouldn't an email message (for example) be encrypted<br>
>> separately to<br>
>> each BCC recipient,<br>
><br>
>My opinion is that should be the case. However, most MUAs I've used<br>
>include the BCC recipients' keys in the encryption along with the To<br>
>and CC recipients' keys, so any email addresses in the user-IDs of<br>
>these keys are visible to all recipients.<br>
><br>
>As an exception, one MAU I used with an OpenPGP add-on would instead<br>
>send an individual copy of the message to each BCC recipient,<br>
>encrypted only to their key.<br>
<br>
This seems like better practice. Also I would want to encrypt the transmitted email message only to the intended recipient, and the copy stored in my "Sent" folder only to myself.<br>
<br>
>> or is this an intended all-in-one<br>
>> multiple-recipient encryption which cannot conceal<br>
>> from the<br>
>> cryptanalyst the fact that the same message,<br>
>> encrypted only once, is<br>
>> being sent to more than one receiving party?<br>
><br>
>With hidden-recipient or hidden-encrypt-to or throw-keyids, it is<br>
>clear how many keys were encrypted to, but the key IDs and user-IDs<br>
>are not present.<br>
I am not terribly comfortable with this situation. It almost seems rather creepy to me to receive an encrypted message that is also encrypted for the benefit or verification of one or more unknown and unidentified third parties. I start suspecting things like a foreign government mandated key escrow or secret government backdoor on behalf of some foreign spy or law enforcement agency.<br>
><br>
>--<br>
>Best regards<br>
><br>
>MFPA <mailto:<a href="mailto:2017-r3sgs86x8e-lists-groups@riseup.net" target="_blank">2017-r3sgs86x8e-lists-groups@riseup.net</a>><br>
><br>
>Never trust a dog with orange eyebrows<br>
<br>
<br>
-- <br>
A well regulated Militia, being necessary to the security of a free State, the right of the people to keep and bear Arms, shall not be infringed.<br>
<br>
<a href="https://www.colmena.biz/~justina/" rel="noreferrer" target="_blank">https://www.colmena.biz/~justina/</a><br><br><br>---------- Forwarded message ----------<br>From: Stefan Claas <<a href="mailto:sac@300baud.de" target="_blank">sac@300baud.de</a>><br>To: <a href="mailto:gnupg-users@gnupg.org" target="_blank">gnupg-users@gnupg.org</a><br>Cc: <br>Bcc: <br>Date: Wed, 2 Jan 2019 22:28:51 +0100<br>Subject: Re: gpg - difference --encrypt-to and --recipient<br>On Wed, 02 Jan 2019 11:56:27 -0900, justina colmena via Gnupg-users wrote:<br>
> On January 1, 2019 4:13:43 PM AKST, MFPA <<a href="mailto:2017-r3sgs86x8e-lists-groups@riseup.net" target="_blank">2017-r3sgs86x8e-lists-groups@riseup.net</a>> wrote:<br>
<br>
> >With hidden-recipient or hidden-encrypt-to or throw-keyids, it is<br>
> >clear how many keys were encrypted to, but the key IDs and user-IDs<br>
> >are not present. <br>
> I am not terribly comfortable with this situation. It almost seems rather creepy to me to receive an encrypted<br>
> message that is also encrypted for the benefit or verification of one or more unknown and unidentified third parties.<br>
> I start suspecting things like a foreign government mandated key escrow or secret government backdoor on behalf of<br>
> some foreign spy or law enforcement agency.<br>
<br>
When you receive a message which is also encrypted to hidden recipients you will see that<br>
in GnuPG, when decrypting the message. It shows additional info of how many keys the<br>
message was encrypted to, with key ids showing in the form of ID 0000000000000000.<br>
<br>
So nothing to worry! This very good feature was probably implemented many moons ago<br>
for users of Mixmaster.<br>
<br>
Regards<br>
Stefan<br>
<br>
<br>
<br><br><br>---------- Forwarded message ----------<br>From: <a href="mailto:vedaal@nym.hush.com" target="_blank">vedaal@nym.hush.com</a><br>To: justina colmena <<a href="mailto:justina@colmena.biz" target="_blank">justina@colmena.biz</a>>, <a href="mailto:gnupg-users@gnupg.org" target="_blank">gnupg-users@gnupg.org</a><br>Cc: <br>Bcc: <br>Date: Wed, 02 Jan 2019 19:02:39 -0500<br>Subject: Re: gpg - difference --encrypt-to and --recipient<br><span style="font-family:Arial;font-size:14px;line-height:150%"><br><br>On 1/2/2019 at 3:59 PM, "justina colmena via Gnupg-users" <<a href="mailto:gnupg-users@gnupg.org" target="_blank">gnupg-users@gnupg.org</a>> wrote:<blockquote style="border-left:1px solid rgb(204,204,204);margin-left:10px;padding-left:10px"><br>>My opinion is that should be the case. However, most MUAs I've used<br>>include the BCC recipients' keys in the encryption along with the To<br>>and CC recipients' keys, so any email addresses in the user-IDs of<br>>these keys are visible to all recipients.<br><br>>As an exception, one MAU I used with an OpenPGP add-on would instead<br>>send an individual copy of the message to each BCC recipient,<br>>encrypted only to their key.<br><br>>This seems like better practice. Also I would want to encrypt the transmitted email message only to the intended recipient, >and the copy stored in my "Sent" folder only to myself.<br><br><br>>With hidden-recipient or hidden-encrypt-to or throw-keyids, it is<br>>clear how many keys were encrypted to, but the key IDs and user-IDs<br>>are not present.<br>I am not terribly comfortable with this situation. It almost seems rather creepy to me to receive an encrypted message that is also encrypted for the benefit or verification of one or more unknown and unidentified third parties. I start suspecting things like a foreign government mandated key escrow or secret government backdoor on behalf of some foreign spy or law enforcement agency.<br><br>=====<br> you have 3 tedious options, 1 more tedious than the other 8^) :<br><br>[1] use default-recipient-self, and explain in an n.b. in your plaintext that you want to have a record of what you sent, but don't want to leave it in plaintext, and you will have an encrypted copy in your sent box openable by you <br>(this is very common).<br><br>[2] encrypt only to the sender, but also encrypt the plaintext only to you, and store the encrypted file in your sent or other convenient folder, with the date and the recipient.<br><br>[3] only for the overly paranoid who revel in tedious work-arounds 8^) :<br><br>(a) Encrypt to both yourself and the recipient<br>(b) Remove your own id packet from the ciphertext, <br>(c) Re-calculate the crc of the ciphertext<br>(d) Send the 'hacked' ciphertext along to the original recipient<br>(e) Store the first ciphertext from (a) along with the one from (d), in your sent folder<br>(f) now you will always be able to decrypt and retrieve the original plaintext<br><br>btw,<br><br>I don't recommend this, <br>but it is *possible* to add a (not yet done, but not terribly complicated either) patch to gnupg to 'display' the session key in the terminal window, <br>(while you are encrypting only to one recipient),<br>and then you can encrypt that session key to your key, and store it,<br><br>or<br><br>a (also not yet done, but not terribly complicated either) patch,<br> to allow gnupg to use a session key supplied by the user as an entry in the command line</blockquote><blockquote style="border-left:1px solid rgb(204,204,204);margin-left:10px;padding-left:10px">(i.e. --use-session-key (64 character string from step (a) above)<br><br>That session key is as random as any done by gnupg, and isn't really being 're-used', <br>it's just being stored in the encrypted file from step (a) and is being sent with the same message encrypted to the same recipient as in step (a)<br><br>This is just to point out, that if someone wants to think paranoidly about 'who else knows' what is encrypted in your encrypted e-mail that was encrypted only to you, it 'can' be done,<br>(extremely tedious, and afaik , has not been implemented by any open-pgp variant program out there 8^) )<br><br><br>vedaal<br><br><br><br></blockquote></span><br><br><br>---------- Forwarded message ----------<br>From: Frank Hrebabetzky <<a href="mailto:hreba@t-online.de" target="_blank">hreba@t-online.de</a>><br>To: <a href="mailto:gnupg-users@gnupg.org" target="_blank">gnupg-users@gnupg.org</a><br>Cc: <br>Bcc: <br>Date: Thu, 3 Jan 2019 15:25:04 +0100<br>Subject: decryption failed: Bad session key<br>Hi all,<br>
<br>
I have 2 encrypted files on my PC, let's call them A and B. Every now <br>
and then, they are decrypted, edited and encrypted again with the -c <br>
option. This has been working very well for decades, surviving several <br>
changes of PCs and Linux flavours. The problem arose after my update <br>
from Linux Mint 17 (Ubuntu 14)<br>
to Linux Mint 19 (Ubuntu 18)<br>
<br>
Since then, A wasn't re-encrypted, and I can decrypt it as before. B <br>
however was re-encrypted, and now I cannot decrypt it anymore. Each <br>
attempt is responded with<br>
<br>
gpg: AES256 encrypted data<br>
gpg: encrypted with 1 passphrase<br>
gpg: decryption failed: Bad session key<br>
<br>
Regards,<br>
-- <br>
Frank Hrebabetzky +49 / 9261 / 950 0565<br>
<br>
<br>
<br>
<br><br><br>---------- Forwarded message ----------<br>From: MFPA <<a href="mailto:2017-r3sgs86x8e-lists-groups@riseup.net" target="_blank">2017-r3sgs86x8e-lists-groups@riseup.net</a>><br>To: vedaal via Gnupg-users on GnuPG-Users <<a href="mailto:gnupg-users@gnupg.org" target="_blank">gnupg-users@gnupg.org</a>><br>Cc: vedaal via Gnupg-users <<a href="mailto:gnupg-users@gnupg.org" target="_blank">gnupg-users@gnupg.org</a>><br>Bcc: <br>Date: Fri, 4 Jan 2019 03:09:53 +0000<br>Subject: Re: gpg - difference --encrypt-to and --recipient<br>-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA512<br>
<br>
Hi<br>
<br>
<br>
On Thursday 3 January 2019 at 12:02:39 AM, in<br>
<<a href="mailto:mid%3A20190103000240.08304C0157@smtp.hushmail.com" target="_blank">mid:20190103000240.08304C0157@smtp.hushmail.com</a>>, vedaal via<br>
Gnupg-users wrote:-<br>
<br>
<br>
> [2] encrypt only to the sender, but also encrypt the<br>
> plaintext only<br>
> to you, and store the encrypted file in your sent or<br>
> other<br>
> convenient folder, with the date and the recipient.<br>
<br>
I guess if you had an MUA that encrypted separately to BCC recipients,<br>
you could achieve this by BCC-ing yourself.<br>
<br>
<br>
<br>
> [3] only for the overly paranoid who revel in tedious<br>
> work-arounds 8^) :<br>
<br>
> (a) Encrypt to both yourself and the recipient<br>
> (b) Remove your own id packet from the ciphertext,<br>
> (c) Re-calculate the crc of the ciphertext<br>
> (d) Send the 'hacked' ciphertext along to the<br>
> original recipient<br>
> (e) Store the first ciphertext from (a) along with<br>
> the one from (d), in your sent folder<br>
> (f) now you will always be able to decrypt and<br>
> retrieve the original plaintext<br>
<br>
Would the ciphertext at (d) be much different than encrypting to the<br>
recipient and hidden-encrypt-to your own key?<br>
<br>
<br>
- --<br>
Best regards<br>
<br>
MFPA <mailto:<a href="mailto:2017-r3sgs86x8e-lists-groups@riseup.net" target="_blank">2017-r3sgs86x8e-lists-groups@riseup.net</a>><br>
<br>
He's an environmentalist - his arguments are 100% recycled<br>
-----BEGIN PGP SIGNATURE-----<br>
<br>
iNUEARYKAH0WIQSWDIYo1ZL/jN6LsL/g4t7h1sju+gUCXC7OkV8UgAAAAAAuAChp<br>
c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0OTYw<br>
Qzg2MjhENTkyRkY4Q0RFOEJCMEJGRTBFMkRFRTFENkM4RUVGQQAKCRDg4t7h1sju<br>
+oXLAP9VS4KkIcC46uXVbRrxMMnMb3uU3DnyWlQAN3BnerHiXQD+Mew6XBCf1Vsy<br>
arODK2wCXESbLQGsX+zXveX+bNpzegyJApMEAQEKAH0WIQRSX6konxd5jbM7JygT<br>
DfUWES/A/wUCXC7Okl8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu<br>
cGdwLmZpZnRoaG9yc2VtYW4ubmV0NTI1RkE5Mjg5RjE3Nzk4REIzM0IyNzI4MTMw<br>
REY1MTYxMTJGQzBGRgAKCRATDfUWES/A/139EACpg6S+lm2f56sqJzF4pWkosYFm<br>
XzkgfMSIFgL241vmewDNAb54RsDtQ7sxZvy9jhIYVA0BFsRhmYmWNHjUWqEvb+iO<br>
Q59yngpjJJkueCfVW6WiC1iCIURVZQ+wrSaQqks1/UyIk8JfwNPMntcjHbMPJt+M<br>
hXxsxpBzy3wgbFfIxjNEx9XdcMOkt6wZHt1SmJQIhP2nw8QydqQAphcKEyBp7T/k<br>
vRKOxExv6PgCWs93dCVWHhO/ek2BDBm5oDMZ0aFz/ZehhtRQapdQYZ5upWXBFcQc<br>
DZgr/G+gDFtEmHjVyYugnBMT9sITau9WYZ+NedhIndwFNHmbd5EfI+i7KNd67kN0<br>
zn0YT21Lh37IMBeki87XcDMiTvNfmejs3ogUgiNwbsr8SGcHpwojKStWJdzlw381<br>
leN5VpLC921BojCgna+2k+xrx+z1+s6b5SZx3FV4118KuXoixRtfWTB52CB9KnzX<br>
MRzfTy4IpjKjdpjqoLrQg7H+VlwVgHzU4p52OA0fWJHxDaYDZpl0mWA2ffL1qn4w<br>
G2cMJKvOQacu2Me241z/tQ7FvLpZ6oKmeaFNM8wzN0vK2bYlh1PTrEE5hEDbWgIm<br>
/J8Qmlg94QqPy7S/lB6BqaWb1lqe48AkdfjFiFwQYcw+3ibsnmhDmQyPe0OkWgqC<br>
1fjyulUQXjXBkJ19bg==<br>
=yhZM<br>
-----END PGP SIGNATURE-----<br>
<br>
<br>
<br>
_______________________________________________<br>
Gnupg-users mailing list<br>
<a href="mailto:Gnupg-users@gnupg.org" target="_blank">Gnupg-users@gnupg.org</a><br>
<a href="http://lists.gnupg.org/mailman/listinfo/gnupg-users" rel="noreferrer" target="_blank">http://lists.gnupg.org/mailman/listinfo/gnupg-users</a><br>
</blockquote></div></div>