On Thu, Jan 3, 2019 at 10:10 PM <gnupg-users-requ...@gnupg.org> wrote:
> Send Gnupg-users mailing list submissions to > gnupg-users@gnupg.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.gnupg.org/mailman/listinfo/gnupg-users > or, via email, send a message with subject or body 'help' to > gnupg-users-requ...@gnupg.org > > You can reach the person managing the list at > gnupg-users-ow...@gnupg.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Gnupg-users digest..." > Today's Topics: > > 1. Re: gpg - difference --encrypt-to and --recipient > (justina colmena) > 2. Re: gpg - difference --encrypt-to and --recipient (Stefan Claas) > 3. Re: gpg - difference --encrypt-to and --recipient > (ved...@nym.hush.com) > 4. decryption failed: Bad session key (Frank Hrebabetzky) > 5. Re: gpg - difference --encrypt-to and --recipient (MFPA) > > > > ---------- Forwarded message ---------- > From: justina colmena <just...@colmena.biz> > To: MFPA <2017-r3sgs86x8e-lists-gro...@riseup.net>, justina colmena via > Gnupg-users on GnuPG-Users <gnupg-users@gnupg.org> > Cc: justina colmena via Gnupg-users <gnupg-users@gnupg.org> > Bcc: > Date: Wed, 02 Jan 2019 11:56:27 -0900 > Subject: Re: gpg - difference --encrypt-to and --recipient > On January 1, 2019 4:13:43 PM AKST, MFPA < > 2017-r3sgs86x8e-lists-gro...@riseup.net> wrote: > >Hi > > > > > >On Monday 31 December 2018 at 9:06:39 PM, in > ><mid:6a39fc9c-3105-451b-bb5e-6d6757337...@colmena.biz>, justina > >colmena via Gnupg-users wrote:- > > > > > >> Shouldn't an email message (for example) be encrypted > >> separately to > >> each BCC recipient, > > > >My opinion is that should be the case. However, most MUAs I've used > >include the BCC recipients' keys in the encryption along with the To > >and CC recipients' keys, so any email addresses in the user-IDs of > >these keys are visible to all recipients. > > > >As an exception, one MAU I used with an OpenPGP add-on would instead > >send an individual copy of the message to each BCC recipient, > >encrypted only to their key. > > 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. > > >> or is this an intended all-in-one > >> multiple-recipient encryption which cannot conceal > >> from the > >> cryptanalyst the fact that the same message, > >> encrypted only once, is > >> being sent to more than one receiving party? > > > >With hidden-recipient or hidden-encrypt-to or throw-keyids, it is > >clear how many keys were encrypted to, but the key IDs and user-IDs > >are not present. > 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. > > > >-- > >Best regards > > > >MFPA <mailto:2017-r3sgs86x8e-lists-gro...@riseup.net> > > > >Never trust a dog with orange eyebrows > > > -- > 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. > > https://www.colmena.biz/~justina/ > > > ---------- Forwarded message ---------- > From: Stefan Claas <s...@300baud.de> > To: gnupg-users@gnupg.org > Cc: > Bcc: > Date: Wed, 2 Jan 2019 22:28:51 +0100 > Subject: Re: gpg - difference --encrypt-to and --recipient > On Wed, 02 Jan 2019 11:56:27 -0900, justina colmena via Gnupg-users wrote: > > On January 1, 2019 4:13:43 PM AKST, MFPA < > 2017-r3sgs86x8e-lists-gro...@riseup.net> wrote: > > > >With hidden-recipient or hidden-encrypt-to or throw-keyids, it is > > >clear how many keys were encrypted to, but the key IDs and user-IDs > > >are not present. > > 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. > > When you receive a message which is also encrypted to hidden recipients > you will see that > in GnuPG, when decrypting the message. It shows additional info of how > many keys the > message was encrypted to, with key ids showing in the form of ID > 0000000000000000. > > So nothing to worry! This very good feature was probably implemented many > moons ago > for users of Mixmaster. > > Regards > Stefan > > > > > > ---------- Forwarded message ---------- > From: ved...@nym.hush.com > To: justina colmena <just...@colmena.biz>, gnupg-users@gnupg.org > Cc: > Bcc: > Date: Wed, 02 Jan 2019 19:02:39 -0500 > Subject: Re: gpg - difference --encrypt-to and --recipient > > > On 1/2/2019 at 3:59 PM, "justina colmena via Gnupg-users" < > gnupg-users@gnupg.org> wrote: > > > >My opinion is that should be the case. However, most MUAs I've used > >include the BCC recipients' keys in the encryption along with the To > >and CC recipients' keys, so any email addresses in the user-IDs of > >these keys are visible to all recipients. > > >As an exception, one MAU I used with an OpenPGP add-on would instead > >send an individual copy of the message to each BCC recipient, > >encrypted only to their key. > > >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. > > > >With hidden-recipient or hidden-encrypt-to or throw-keyids, it is > >clear how many keys were encrypted to, but the key IDs and user-IDs > >are not present. > 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. > > ===== > you have 3 tedious options, 1 more tedious than the other 8^) : > > [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 > (this is very common). > > [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. > > [3] only for the overly paranoid who revel in tedious work-arounds 8^) > : > > (a) Encrypt to both yourself and the recipient > (b) Remove your own id packet from the ciphertext, > (c) Re-calculate the crc of the ciphertext > (d) Send the 'hacked' ciphertext along to the original recipient > (e) Store the first ciphertext from (a) along with the one from (d), in > your sent folder > (f) now you will always be able to decrypt and retrieve the original > plaintext > > btw, > > I don't recommend this, > 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, > (while you are encrypting only to one recipient), > and then you can encrypt that session key to your key, and store it, > > or > > a (also not yet done, but not terribly complicated either) patch, > to allow gnupg to use a session key supplied by the user as an entry in > the command line > > (i.e. --use-session-key (64 character string from step (a) above) > > That session key is as random as any done by gnupg, and isn't really being > 're-used', > 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) > > 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, > (extremely tedious, and afaik , has not been implemented by any open-pgp > variant program out there 8^) ) > > > vedaal > > > > > > > ---------- Forwarded message ---------- > From: Frank Hrebabetzky <hr...@t-online.de> > To: gnupg-users@gnupg.org > Cc: > Bcc: > Date: Thu, 3 Jan 2019 15:25:04 +0100 > Subject: decryption failed: Bad session key > Hi all, > > I have 2 encrypted files on my PC, let's call them A and B. Every now > and then, they are decrypted, edited and encrypted again with the -c > option. This has been working very well for decades, surviving several > changes of PCs and Linux flavours. The problem arose after my update > from Linux Mint 17 (Ubuntu 14) > to Linux Mint 19 (Ubuntu 18) > > Since then, A wasn't re-encrypted, and I can decrypt it as before. B > however was re-encrypted, and now I cannot decrypt it anymore. Each > attempt is responded with > > gpg: AES256 encrypted data > gpg: encrypted with 1 passphrase > gpg: decryption failed: Bad session key > > Regards, > -- > Frank Hrebabetzky +49 / 9261 / 950 0565 > > > > > > > ---------- Forwarded message ---------- > From: MFPA <2017-r3sgs86x8e-lists-gro...@riseup.net> > To: vedaal via Gnupg-users on GnuPG-Users <gnupg-users@gnupg.org> > Cc: vedaal via Gnupg-users <gnupg-users@gnupg.org> > Bcc: > Date: Fri, 4 Jan 2019 03:09:53 +0000 > Subject: Re: gpg - difference --encrypt-to and --recipient > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > Hi > > > On Thursday 3 January 2019 at 12:02:39 AM, in > <mid:20190103000240.08304c0...@smtp.hushmail.com>, vedaal via > Gnupg-users wrote:- > > > > [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. > > I guess if you had an MUA that encrypted separately to BCC recipients, > you could achieve this by BCC-ing yourself. > > > > > [3] only for the overly paranoid who revel in tedious > > work-arounds 8^) : > > > (a) Encrypt to both yourself and the recipient > > (b) Remove your own id packet from the ciphertext, > > (c) Re-calculate the crc of the ciphertext > > (d) Send the 'hacked' ciphertext along to the > > original recipient > > (e) Store the first ciphertext from (a) along with > > the one from (d), in your sent folder > > (f) now you will always be able to decrypt and > > retrieve the original plaintext > > Would the ciphertext at (d) be much different than encrypting to the > recipient and hidden-encrypt-to your own key? > > > - -- > Best regards > > MFPA <mailto:2017-r3sgs86x8e-lists-gro...@riseup.net> > > He's an environmentalist - his arguments are 100% recycled > -----BEGIN PGP SIGNATURE----- > > iNUEARYKAH0WIQSWDIYo1ZL/jN6LsL/g4t7h1sju+gUCXC7OkV8UgAAAAAAuAChp > c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0OTYw > Qzg2MjhENTkyRkY4Q0RFOEJCMEJGRTBFMkRFRTFENkM4RUVGQQAKCRDg4t7h1sju > +oXLAP9VS4KkIcC46uXVbRrxMMnMb3uU3DnyWlQAN3BnerHiXQD+Mew6XBCf1Vsy > arODK2wCXESbLQGsX+zXveX+bNpzegyJApMEAQEKAH0WIQRSX6konxd5jbM7JygT > DfUWES/A/wUCXC7Okl8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu > cGdwLmZpZnRoaG9yc2VtYW4ubmV0NTI1RkE5Mjg5RjE3Nzk4REIzM0IyNzI4MTMw > REY1MTYxMTJGQzBGRgAKCRATDfUWES/A/139EACpg6S+lm2f56sqJzF4pWkosYFm > XzkgfMSIFgL241vmewDNAb54RsDtQ7sxZvy9jhIYVA0BFsRhmYmWNHjUWqEvb+iO > Q59yngpjJJkueCfVW6WiC1iCIURVZQ+wrSaQqks1/UyIk8JfwNPMntcjHbMPJt+M > hXxsxpBzy3wgbFfIxjNEx9XdcMOkt6wZHt1SmJQIhP2nw8QydqQAphcKEyBp7T/k > vRKOxExv6PgCWs93dCVWHhO/ek2BDBm5oDMZ0aFz/ZehhtRQapdQYZ5upWXBFcQc > DZgr/G+gDFtEmHjVyYugnBMT9sITau9WYZ+NedhIndwFNHmbd5EfI+i7KNd67kN0 > zn0YT21Lh37IMBeki87XcDMiTvNfmejs3ogUgiNwbsr8SGcHpwojKStWJdzlw381 > leN5VpLC921BojCgna+2k+xrx+z1+s6b5SZx3FV4118KuXoixRtfWTB52CB9KnzX > MRzfTy4IpjKjdpjqoLrQg7H+VlwVgHzU4p52OA0fWJHxDaYDZpl0mWA2ffL1qn4w > G2cMJKvOQacu2Me241z/tQ7FvLpZ6oKmeaFNM8wzN0vK2bYlh1PTrEE5hEDbWgIm > /J8Qmlg94QqPy7S/lB6BqaWb1lqe48AkdfjFiFwQYcw+3ibsnmhDmQyPe0OkWgqC > 1fjyulUQXjXBkJ19bg== > =yhZM > -----END PGP SIGNATURE----- > > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users@gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users >
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
