unsubscibe

steven schmidt stevenschmidt909 at gmail.com
Fri Jan 4 19:22:58 CET 2019


On Thu, Jan 3, 2019 at 10:10 PM <gnupg-users-request at gnupg.org> wrote:

> Send Gnupg-users mailing list submissions to
>         gnupg-users at 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-request at gnupg.org
>
> You can reach the person managing the list at
>         gnupg-users-owner at 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
>       (vedaal at 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 <justina at colmena.biz>
> To: MFPA <2017-r3sgs86x8e-lists-groups at riseup.net>, justina colmena via
> Gnupg-users on GnuPG-Users <gnupg-users at gnupg.org>
> Cc: justina colmena via Gnupg-users <gnupg-users at 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-groups at riseup.net> wrote:
> >Hi
> >
> >
> >On Monday 31 December 2018 at 9:06:39 PM, in
> ><mid:6A39FC9C-3105-451B-BB5E-6D6757337600 at 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-groups at 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 <sac at 300baud.de>
> To: gnupg-users at 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-groups at 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: vedaal at nym.hush.com
> To: justina colmena <justina at colmena.biz>, gnupg-users at 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 at 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 <hreba at t-online.de>
> To: gnupg-users at 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-groups at riseup.net>
> To: vedaal via Gnupg-users on GnuPG-Users <gnupg-users at gnupg.org>
> Cc: vedaal via Gnupg-users <gnupg-users at 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.08304C0157 at 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-groups at 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 at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190104/a99027f3/attachment-0001.html>


More information about the Gnupg-users mailing list