gpg - difference --encrypt-to and --recipient

vedaal at nym.hush.com vedaal at nym.hush.com
Thu Jan 3 01:02:39 CET 2019



On 1/2/2019 at 3:59 PM, "justina colmena via Gnupg-users"  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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190102/cafe31ad/attachment.html>


More information about the Gnupg-users mailing list